Resetting the Password Won't Help: Why AD CS Relay (ESC8) Is the AD Attack That Survives Your Incident Response

Run this thought experiment. Your SOC catches an intrusion, scopes it to a compromised domain controller, and does everything right: isolates the host, resets the machine account password twice, rotates the krbtgt key, forces a domain-wide credential reset. Textbook containment. Three weeks later the same actor is back in as a domain admin, and nothing you reset slowed them down.

This is what AD Certificate Services abuse does to incident response, and ESC8 is the sharpest version of it. The attacker never stole a password, so resetting passwords accomplishes nothing. What they stole was a certificate, and a certificate keeps working until it expires or is explicitly revoked, regardless of how many times you change the underlying account's password.

Most AD security guidance treats credentials as something you can rotate your way out of. Certificates break that assumption. A defender who doesn't know it will run a clean-looking incident response and leave the back door wide open.

AD CS is the most under-examined attack surface in a mature Active Directory, precisely because it sits to one side of the kit most teams audit. You hardened your Kerberos, you watch for Kerberoasting, you alert on DCSync. Meanwhile a certificate authority installed years ago for device enrollment is quietly exposing an HTTP endpoint that will mint a credential for any machine that authenticates to it. Let's walk the chain, look at what it actually leaves behind, and then close it.

NTLM proves who, not to whom

The flaw ESC8 abuses isn't in AD CS. It's in NTLM, and AD CS is just the most rewarding place to spend it.

When a machine authenticates over NTLM, it proves it knows a secret without sending the secret. It answers a challenge. The problem is that the answer isn't bound to the service the authentication was meant for.

An attacker positioned in the middle can take that answer and present it to a different service. As long as that service accepts NTLM and doesn't verify the authentication was intended for it, the service treats the attacker as the authenticating machine. That's a relay. NTLM proves who you are; it never proves who you meant to talk to, so the proof can be spent somewhere else.

Two properties make this dangerous rather than merely interesting.

First, relay is live. The forwarded authentication is only valid for the brief window the challenge-response is good for, so the attacker lines up the relay target before the authentication fires and the whole thing completes in seconds. You cannot catch it afterward by hunting for a reused credential, because nothing reusable was ever captured.

Second, it defeats the defense everyone reaches for with machine accounts. A domain controller's machine account password is long, random, and rotated automatically, so you can't crack it. With relay you don't need to. You need it to authenticate to you once, and then you spend that single authentication before it expires.

Which raises the obvious question: how do you make a domain controller authenticate to you on demand? You coerce it.

Coercion supplies the "once"

Coercion is a family of techniques that force a Windows machine to authenticate to an arbitrary target. PetitPotam abuses the Encrypting File System remote protocol; the printer bug abuses the print spooler's notification mechanism. The mechanics differ, but the outcome is identical: you send a machine a request that says "go authenticate over there," and it does, as itself.

Point that at a domain controller and you've manufactured the one thing relay needs. The DC authenticates, as a domain controller, to a target you chose. Coercion guarantees the once; relay spends it.

# Coercion in the wild leaves a request to an unexpected endpoint.
# A DC's machine account ($) authenticating outbound to a non-DC host
# over SMB is the shape worth alerting on. (Pseudocode for the pattern,
# not a copy-paste rule, validate fields against your own telemetry.)

source_account ENDS WITH '$'            # a machine account
AND source_host IS a domain controller
AND destination_host IS NOT a domain controller
AND auth_protocol = 'NTLM'

The relay itself crosses the wire and leaves very little behind. That's the trap: the loudest part of the attack is the quietest in your logs. The coercion request may be visible if you're watching the right protocols, but the relay that follows is just a forwarded packet. So you don't hunt the relay. You hunt its result.

ESC8: relay into the certificate authority

AD CS can expose an enrollment interface over HTTP, the web enrollment endpoint. In its default configuration that endpoint accepts NTLM and does not require the protections that would bind the authentication to it. That combination is ESC8.

The chain reads cleanly once you've seen the pieces. The attacker coerces a domain controller, relays its NTLM authentication to the web enrollment endpoint, and requests a certificate on a template the domain controller is allowed to enroll for. The CA, seeing a valid domain-controller authentication, issues a certificate to that domain controller.

The attacker now holds a certificate for a DC. Through PKINIT, that certificate becomes a Kerberos ticket for the DC. With a domain controller's ticket, they replicate the directory and walk away with every credential in the domain. No password cracked, no template misconfigured, no user phished. A printer notification and a web request did the whole thing.

The certificate is the part that ruins your incident response. It was issued legitimately, by your own CA, to your own DC, and it will keep authenticating until it expires (which might be a year out) or until someone explicitly revokes that specific certificate. Your machine account password resets don't touch it. Your krbtgt rotation doesn't touch it. The actor can sit quiet for a month and come back with a credential your containment never addressed.

What it actually leaves behind

Because the relay is quiet, your evidence is the issuance and the use. Both are loggable, and both are the thing to build detections around.

On the certificate authority, certificate request and issuance generate events 4886 and 4887. The signal that matters is a certificate issued to a domain controller's machine account through the web enrollment path, especially when nobody scheduled a DC certificate enrollment. A DC getting a fresh certificate it didn't ask for, at a time no one was doing CA maintenance, is the residue of the mint step.

// Sentinel / Defender XDR: certificates issued to machine accounts via AD CS
// Pivot point: a DC machine account ($) receiving a freshly issued cert.
// 4887 = certificate issued. Verify the channel and field names against
// your own forwarded Security log before relying on this.
SecurityEvent
| where EventID in (4886, 4887)
| where Requester endswith "$"            // machine account requested
| extend Account = tostring(Requester)
| summarize Requests = count(), Templates = make_set(CertificateTemplate)
    by Account, bin(TimeGenerated, 1h)
| where Account has_any (dynamic(["DC01$","DC02$","NE-DC01$","NE-DC02$"]))  // your DCs
| sort by TimeGenerated desc

Then the use. A certificate spent through PKINIT produces a TGT, and the Kerberos authentication that results carries the marks of certificate-based pre-authentication. Event 4768 on a domain controller, issued for a machine account, where the pre-authentication type indicates PKINIT rather than a password, is the spend step. The same logic expressed for Splunk:

index=wineventlog (EventCode=4886 OR EventCode=4887)
  Requester="*$"
| stats count values(CertificateTemplate) as templates by Requester, _time
| search Requester IN ("DC01$","DC02$","NE-DC01$","NE-DC02$")

The detections are simple. The hard part is that almost nobody is looking at the CA's Security log at all. Certificate authorities get installed, configured, and forgotten, and their logs often aren't even forwarded to the SIEM. If you take one thing from this: confirm your issuing CA's security events are being collected before you worry about the query. A perfect detection over telemetry you don't ingest is a silent rule.

Closing it

The detections tell you it happened. The fix is to make the relay impossible, and because relay defenses are per-protocol, this is a layered job, not a single switch.

• Require Extended Protection for Authentication (EPA) on the AD CS web enrollment endpoint. EPA binds the authentication to the TLS channel it arrived on, which is exactly the "to whom" that NTLM omits, and it's the control that specifically breaks ESC8.
• Enforce HTTPS on web enrollment and, where you can, disable NTLM on that endpoint entirely. The relay rides NTLM over HTTP; remove the conditions and the chain has nowhere to land.
• Cut coercion off at the source: patch and restrict the EFS-RPC and spooler vectors, and block unnecessary outbound authentication from domain controllers. Coercion is the match; without it the attacker can't light the relay.
• Audit whether the HTTP web enrollment role is even installed. Many environments enabled it once for a migration and never turned it off. If you don't need it, removing it deletes the ESC8 surface outright.

There's a broader point here about how AD CS reshapes incident response. When the credential is a certificate, containment has to include enumerating and revoking issued certificates, not only resetting accounts. If you respond to an AD CS incident the way you'd respond to a stolen password, you will declare the incident closed while the attacker still holds a valid cert. The reset that feels like the finish line isn't one.

What to do this week

You can establish your ESC8 exposure in an afternoon, without any attack tooling.

• Find every issuing certificate authority in the domain and check whether the Certificate Authority Web Enrollment role is installed. That role is the ESC8 surface; if it's present and you don't have a reason for it, that's your first finding.
• For any CA that does run web enrollment, confirm whether EPA is required and whether the endpoint is HTTPS-only. If EPA isn't enforced, you are exposed today.
• Confirm your issuing CA forwards its Security log (4886 and 4887 in particular) to your SIEM. If it doesn't, fix that before anything else, because right now a relayed certificate issuance is invisible to you.
• Run a one-off query for certificates issued to domain-controller machine accounts in the last 90 days and confirm each one corresponds to a change you can explain.
• Add the on-prem domain controllers' outbound authentication to your monitoring, so a coerced DC reaching a host it has no business authenticating to becomes something you see.

ESC8 is dangerous because it's quiet, it's default-on in too many environments, and it produces a credential that laughs at your incident-response playbook. None of the fixes are exotic. The reason it keeps working is that the certificate authority is the box nobody looks at. Look at it this week.