ESC8 is still the most common AD CS finding we see

Across reports submitted to the Netwrix PingCastle public statistics site through the "compare with statistics" button, A-CertEnrollHttp had been flagged 6,487 times as of November 2026. That's more than any other Active Directory Certificate Services (AD CS) escalation path we track.

Together with A-CertEnrollChannelBinding, it covers ESC8. ESC8 is well documented, and it's still this common because it starts with an insecure default.

What is ESC8?

ESC8 is an NTLM relay attack against the AD CS web enrollment interface. When the Certification Authority Web Enrollment role is installed and its HTTP endpoint (certsrv) accepts NTLM authentication without protections like Extended Protection for Authentication (EPA) or channel binding, an attacker can relay a captured NTLM authentication attempt to that endpoint and request a certificate on behalf of someone else.

If an attacker coerces a domain controller into authenticating to them, using a technique like PetitPotam, they can relay that authentication to the web enrollment endpoint and receive a certificate that authenticates as that domain controller. From there it's a short hop to DCSync and full domain compromise.

MITRE tracks this under T1557 (Adversary-in-the-Middle) for the coercion-and-relay mechanism, and T1649 (Steal or Forge Authentication Certificates) for what happens once the attacker has that certificate in hand.

Why is ESC8 so common?

Installing the Web Enrollment role enables HTTP and NTLM authentication out of the box, and HTTPS with EPA enforced takes additional configuration. Teams that don't know that configuration is needed stay exposed by default.

Nobody decides to leave certificate enrollment open to NTLM relay. Someone stands up a CA and enables Web Enrollment, and six months later nobody remembers the role is running, let alone that it needs EPA enabled.

The finding turns up even in hardened environments, though less often now that awareness of ESC8 has spread.

What can an attacker do with an ESC8 certificate?

ESC8 is high severity because of what the attacker holds once the relay succeeds. An NTLM session ends quickly, but the issued certificate stays valid until it expires or someone revokes it, which is often a year or more.

The certificate also works across protocols. The attacker can authenticate with Kerberos or Schannel (certificate-based TLS logon), which bypasses any NTLM restrictions in the environment.

Combined with a coercion technique, the chain needs only network access to a vulnerable web enrollment endpoint and a machine the attacker can force to authenticate. That's a low bar for a path that ends in Domain Admin-equivalent access.

How does PingCastle detect ESC8?

PingCastle probes each certificate authority and enrollment server it finds on the network. For each one, it sends a request to two endpoints: the web enrollment page (certsrv/certrqxt.asp) and the Certificate Enrollment Service (CES) endpoint. If either answers successfully over plain HTTP, PingCastle flags the domain, because an attacker on the network can relay NTLM authentication to an unencrypted enrollment endpoint.

A-CertEnrollChannelBinding covers the HTTPS side. It flags enrollment endpoints that accept HTTPS but don't enforce channel binding, since a relayed NTLM session can still get through over HTTPS.

How do you fix ESC8 without breaking enrollment?

Do you need Web Enrollment at all? If nobody in your environment relies on the certsrv interface for certificate requests, remove the role. It's the simplest remediation and the one to check first.

If you do need it, HTTPS alone doesn't close ESC8. The enrollment endpoint also needs EPA or channel binding enforced, because a relayed NTLM session can still be forwarded over an HTTPS connection. Microsoft's guidance on mitigating NTLM relay attacks against AD CS (KB5005413) walks through the configuration.

Other mitigations: restrict network access to the CA's web interface, disable NTLM where Kerberos is sufficient, and patch against known coercion techniques. For the rest of your CA's exposure, review the risky AD CS settings that show up alongside ESC8.

My recommendation

I recommend checking whether you need Web Enrollment before hardening it. If you do need it, require HTTPS and EPA, and follow KB5005413.

To check whether you're exposed, run a free PingCastle scan. It flags ESC8 directly, along with the rest of your AD CS risk surface. Search the report for "The certificate enrollment interface is accessible by unencrypted HTTP" and "Channel Binding is not enforced for the HTTPS Certificate Enrollment Interface," the two findings that indicate ESC8 risk.