ADCS + PetitPotam NTLM Relay: Obtaining krbtgt Hash with Domain Controller Machine Certificate

This is a quick lab to familiarize with an Active Directory Certificate Services (ADCS) + PetitPotam + NLTM Relay technique that allows attackers, given ADCS is misconfigured (which it is by default), to effectively escalate privileges from a low privileged domain user to Domain Admin.

The ADCS vulnerabilities were researched by Will Schroeder and Lee Christensen in Certified Pre-Owned, PetitPotam was researched by Gilles Lionel @topotam77, ADCS attack implemented in impacket by ExAndroidDev.

Conditions

Below are some of the conditions making an AD environment vulnerable to ADCS + NTLM relay attack:

  • ADCS is configured to allow NTLM authentication;

  • NTLM authentication is not protected by EPA or SMB signing;

  • ADCS is running either of these services:

    • Certificate Authority Web Enrollment

    • Certificate Enrollment Web Service

Overview

Below provides a high level overview of how the attack works:

  1. Get a foothold in an AD network with a misconfigured ADCS instance;

  2. Setup an NTLM relay listener on a box you control, so that incoming authentications are relayed to the misconfigured ADCS;

  3. Force the target DC to authenticate (using PetitPotam or PrintSpooler trick) to the box running your NTLM relay;

  4. Target DC attempts to authenticate to your NTLM relay;

  5. NTLM relay receives the DC$ machine account authentication and relays it to the ADCS;

  6. ADCS provides a certificate for the target DC$ computer account;

  7. Use the target DC's computer account certificate to request its Kerberos TGT;

  8. Use target DC's computer account TGT to perform DCSync and pull the NTLM hash of krbtgt;

  9. Use krbtgt NTLM hash to create Golden Tickets that allow you to impersonate any domain user, including Domain Admin.

Below graphic visualizes the concept:

PetitPotam: NTLM Relay to AD CS flow diagram

Domain Takeover

Lab Setup

This part of the lab is setup with the following computers and servers:

  • 10.0.0.5 - Kali box with NTLM relay;

  • 10.0.0.6 - target Domain Controller DC01. This is the target DC that we will coerce to authenticate to our NTLM relay on 10.0.0.5;

  • 10.0.0.10 - Certificate Authority (CA01). This is where our NTLM relay 10.0.0.5 will forward DC01 authentication to;

  • 10.0.0.7 - Windows worksation (WS01). This is the initial foothold in the network and this is the machine that will force the DC01 to authenticate to our NTLM relay on 10.0.0.5;

Installing Tools

Let's pull the version of impacket that has ADCS attack implemented and checkout the right branch:

Installing impacket and switching to the adcs attack branch

Configuring Virtual Environment

Prepare a python virtual environment for impacket. Start by installing the virtual environment package:

Installing python3 virtual environment

Create and activate a new virtual python environment called impacket:

Initiating and activating the impacket virtual environment

Let's install all impacket dependencies:

Installing impacket dependencies

Finding Certificate Authority

On WS01, we can use a Windows LOLBIN certutil.exe, to find ADCS servers in the domain:

CA01 is a Certificate Authority

We confirm that in our domain, CA01 is our Certificate Authority that we will be relaying DC01$ authentication to.

Setting up NTLM Relay

On Kali box at 10.0.0.5, let's setup our NTLM relay to forward incoming authentications from DC01$ to the CA01, or more specifically to one of its HTTP endpoints for certificate enrollment http://ca01/certsrv/certfnsh.asp like so:

NTLM relay is ready and waiting for incoming authentications

Forcing DC01 to Authenticate to NTLM Relay

From WS01, let's force the DC01 to authenticate to our NTLM relay at 10.0.0.5 by executing PetitPotam:

DC01 is coerced to authenticate to 10.0.0.5. DC01$ certificate is retrieved from CA01

Above shows how:

  • DC01 was forced to authenticate to 10.0.0.5;

  • 10.0.0.5 relayed the DC01$ authentication to CA01;

  • CA01 issued a certificate for the DC01$ computer account.

Requesting DC01$ TGT

On WS01, we can now use rubeus to request a Kerberos TGT for the DC01$ computer account like so:

Use runas /netonly /user:fake powershell to create a new/sacrificial logon session into which the DC01$ TGT will be injected to prevent messing up TGTs/TGSs for your existing logon session.

TGT for DC01$ retrieved and injected into the current logon session

klist confirms we now have a TGT for DC01$ in the current logon session:

TGT for DC01$ in memory

We can now perform DCSync and pull the NTLM hash for the user offsense\krbtgt:

DCSync: Dump Password Hashes from Domain Controller
DCSync pulls NTLM hash of krbtgt

Having the NTLM hash for krbtgt allows us to create Kerberos Golden Tickets.

Kerberos: Golden Tickets

Remember

It's worth remembering that in some AD environments there will be highly privileged accounts connecting to workstations to perform some administrative tasks and if you have local administrator rights on a compromised Windows box, you can perform ADCS + NTLM relay attack to request a certificate for that service account.

To do so, you'd need the following:

Reminder Consider your OPSEC.

  • Stop the SMB service on the compromised box. This requires local admin privileges on the box and a reboot to stop the machine from listening on TCP 445;

  • Spin up the NTLM relay on TCP 445;

  • Wait for the service account to connect to your machine;

  • Incoming service account authentication is relayed to the ADCS, which spits out the service account certificate;

  • Use service account's certificate to request its Kerberos TGT;

  • You've now gained administrative privileges on machines the compromised service account can access.

RBCD: Remote Computer Takeover

It's also possible to gain administrative privileges over any remote computer given we have network access to that computer, as pointed out by Lee Christensen:

Lab Setup

This part of the lab is setup with the following computers and servers:

  • 10.0.0.5 - Kali box with NTLM relay;

  • 10.0.0.7 - Windows worksation (WS01). This is the box we will coerce to authenticate our Kali box, which will relay the authentication to DC01 and setup the computer WS01 for a remote takeover;

  • 10.0.0.6 - Domain Controller DC01;

  • 10.0.0.10 - Certificate Authority (CA01). This is the box from which we will coerce WS01 to authenticate to DC01;

Setting up NTLM Relay

Let's set up our NTLM relay on the Kali box to relay authentications to DC01 via LDAP and specify the --delegate-access flag, which will automate the Resource Based Constrained Delegation (RBCD) attack steps:

Notes about RBCD takeover:

Kerberos Resource-based Constrained Delegation: Computer Object Takeover

Forcing WS01 to Authenticate to NTLM Relay

On computer CA01, let's invoke PetitPotam and coerce WS01 (10.0.0.7) to authenticate to our Kali box (10.0.0.5) where our NTLM relay is setup:

On our Kali box, we can see the the incoming authentication from WS01$ was relayed to ldaps://dc01 and that a new computer quaiivve$ account (that WS01 now trusts and allows to impersonate any domain user), was created:

LDAP relay succeeds, delegation rights setup

Below screenshot shows that the QUAIIVEE computer account has been indeed created and WS01$ has some privileges to it:

Computer AD object created as part of RBCD attack

Additionally, we can see that the attribute msDS-AllowedToActOnBehalfOfOtherIdentity on computer object WS01 contains some binary value, which is empty by default on computer objects:

WS01 has been configured for RBCD attack

From Kerberos Resource-based Constrained Delegation: Computer Object Takeover, we know that the msDS-AllowedToActOnBehalfOfOtherIdentity attribute, after we've successfully performed the LDAP relay attack, effectively encodes the following: computer WS01 trusts the computer account QUAIIVVE$ and allows it to impersonate any domain user, including Domain Admins and grant them administrative access to WS01.

Calculating Hash

On computer CA01, let's calculate the RC4 hash for the newly created computer account's QUAIIVVE$: password:

Rubeus calculates the RC4 hash - 3F55290748348504327CDA267FCCA190

Impersonating Domain Admin on WS01

Time to impersonate a Domain Admin.

While on CA01, we can use rubeus s4u command, which will:

  1. Retrieve a TGT for offense.local\QUAIIVVE$;

  2. Perform S4U2Self, which is a Kerberos extension that allows a service to obtain a TGS to itself on another user's behalf. So in our case, the CA01 will request a TGS for [email protected] as [email protected];

  3. Perform S4U2Proxy, which is a Kerberos extension that enables services to request TGS tickets to other services on behalf of a given user. In this instance, a TGS will be requested for cifs/ws01.offense.local, which will allow CA01 to access WS01 computer's file system (i.e., c$ share) on behalf of the Domain Admin [email protected]:

s4u successfully retrieves appropriate TGT and TGS

We can now try to access WS01 c$ share from CA01 to confirm if we've gained administrative access over WS01:

C$ share being listed on WS01 from CA01

WebClient Service

For the above attack to work, the target system WS01 has to have the WebClient service running:

WebClient service running on WS01

WebClient service is not running on computers by default and normally you'd need admin rights to start it, however it's possible to force the service to start using the below code:

Below shows WebClient service is not running on WS01 and we cannot start it, however, executing the above code (webclient.cpp compiled as webclient.exe) kicks off the WebClient service for us:

Forcing the WebClient service to run

RBCD: Local Computer TakeOver / Local Privilege Escalation

It's also possible to leverage the ADCS NTLM relay + Resource Based Constrained Delegation (RBCD) to escalate privileges on a local computer, if regular domain users can create new machine/computer accounts in AD, which they are by default, as specified in the domain root object's attribute ms-DS-MachineAccountQuota: 10, as seen below:

Regular users can add up to 10 machine accounts in the domain by default

Ability to create machine accounts applies when talking about remote computer takeover too.

Lab Setup

This part of the lab is setup with the following computers and servers:

  • 10.0.0.5 - Kali box with NTLM relay;

  • 10.0.0.7 - Windows worksation WS01. This is the box we will coerce to authenticate our Kali box, which will relay the authentication to DC01 and setup the computer WS01 for RBCD attack;

  • 10.0.0.6 - Domain Controller DC01;

Calculating Hash

Building on the previous successful NTLM relay, where we forced the WS01$ to authenticate to our Kali box (where our NTLM relay was listening), we got a new machine account QUAIIVVE$ created with a password K_-Jzsb&uK!`TIH. Let's re-calculate the password's hash:

Password hash calculations

Impersonating Domain Admin on WS01

We can now perform the S4U against WS01, where we currently have low privileged access, but want to elevate to administrator:

Above and below shows how a TGS for [email protected] is granted access to cifs/ws01.offense.local:

TGS for [email protected] issued to access cifs/ws01.offense.local

Decoding TGS to .kirbi

On a Kali box, let's base64 decode the TGS we got for [email protected] to cifs/ws01.offense.local and save it as admin.kirbi:

TGS base64 decoded and saved to a kirbi file

Converting .kirbi Ticket to .ccache

Use impacket's tool ticketConverter to convert the .kirbi file to .ccache file like so:

Converting .kirbi to .ccache

Exporting KRB5CCNAME

Now we need to export the KRB5CCNAME variable and point it to our admin.ccache file:

KRB5CCNAME variable exported

Executing Code as Domain Admin on WS01

We can now use impacket's wmiexec to execute commands on WS01 as administrator:

Code execution on WS01 as offense\administrator

Privileged code execution on WS01 can also be achieved using impacket's psexec:

psexec executes code on ws01 from 10.0.0.5 with SYSTEM privileges

Note

RBCD for local privilege escalation could also be performed:

  • by leveraging a compromised user with SPN set, assuming you have WRITE privilege over the computer's you want to compromise, AD object as described here.

  • via socks proxy and remote port forwarding as described here, which reduces the need to have a Linux box inside the compromised network with an NTLM relay listener set up.

Note to self: what a beautiful attack vector this is.

PetitPotam blocked?

You can now also use:

LogoGitHub - Wh04m1001/DFSCoerceGitHub

References

LogoCertified Pre-Owned - SpecterOpsSpecterOps
LogoKB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS) - Microsoft Supportsupport.microsoft.com
The worst of both worlds: Combining NTLM Relaying and Kerberos delegationdirkjanm.io
The worst of both worlds: Combining NTLM Relaying and Kerberos delegationdirkjanm.io
LogoRed Team Privilege Escalation - RBCD Based Privilege Escalation - Part 2Praetorian
LogoResearch in Cybersecurityorangecyberdefense.com
PreviousActive Directory Lab with Hyper-V and PowerShellNextFrom Misconfigured Certificate Template to Domain Admin

Last updated