Relaying your way to a domain-admin certificate (AD CS ESC8)
If your AD CS web enrollment accepts NTLM, an attacker can coerce a domain controller to authenticate, relay it, and walk away with a certificate that is the DC. Here is ESC8, and how to stop it.
A certificate outlives a password reset. That is exactly why this path is so hard to evict.
What it is
AD CS certificate enrollment over HTTP (the web enrollment and CES endpoints) often accepts NTLM authentication with no channel binding or signing. In ESC8, an attacker coerces a privileged machine, usually a domain controller, to authenticate to a host they control, relays that NTLM authentication to the AD CS web endpoint, and enrolls a certificate in the victim’s name. A certificate for a domain controller, plus PKINIT, yields the DC’s hash and full domain compromise. This is T1557 (relay) into T1649 (steal or forge certificates).
Why it works
The certificate authority trusts the relayed authentication, the issued certificate is long-lived, and resetting passwords does not revoke a certificate an attacker already holds.
How to detect it
Watch for coercion patterns (a domain controller authenticating to an odd host), certificate requests for machine accounts from unusual sources, and enrollment over plain HTTP. Events 4886 and 4887 on the CA record requests and issuance.
The fix that holds
Disable NTLM on the AD CS web endpoints, enforce HTTPS with Extended Protection for Authentication (channel binding) and require signing, or remove the web enrollment roles if they are unused. Patch coercion vectors and monitor certificate enrollment for anomalies.
Practice it
We built an AD CS ESC8 scenario in GraphLattice Range so teams work the relay, the detection, and the enrollment lockdown end to end.