The AD Certificate Services attack surface has been mapped out in the open since SpecterOps published the original ESC1 through ESC8 patterns in 2021. The community filled in ESC9 and ESC10 soon after. ESC11, relayed NTLM authentication to the CA's RPC enrollment interface, was documented publicly by security researchers as an extension of the same relay family. In environments that have patched the earlier CVEs but never hardened NTLM on the CA, it can be one of the shortest single paths from Authenticated Users to Domain Admin.

This explainer walks through how the technique works, an enumeration query that surfaces it in your own environment, and the handful of settings that close it.

1. Why ESC11 matters

Most enterprise CAs still accept NTLM authentication on the RPC interface used by certreq. If an attacker can coerce any machine account into authenticating to their relay, they can request a certificate as that machine. Pair this with a constrained-delegation path and the result is a forge-able Tier-0 identity.

The dangerous part is not the technique itself but the defensive blind spot: many patched environments assume they have closed ESC1-8 and stop checking. They have not deployed the EPA + LDAP-channel-binding combination that actually closes ESC11.

2. How the attack chain works

The chain is short and leans on individually "supported" behaviours that add up to privilege escalation. Walking it through generically:

  • Coerce a machine account into authenticating to an attacker-controlled host, for example with a spooler or EFSRPC coercion such as PetitPotam.
  • Relay that NTLM authentication to the CA's RPC enrollment interface (ICertPassage / ICertRequestD).
  • Request a certificate in the context of the coerced machine account.
  • Use the issued certificate to authenticate as that account, and, where the account is a domain controller, pivot to DCSync.

No new CVE is required; each step is a documented behaviour that only becomes dangerous in combination.

3. The enumeration query

The relationship is easy to surface in BloodHound. A Cypher query that flags users with a path to a CA that has not enabled extended protection:

MATCH (u:User)-[:MemberOf*1..]->(g:Group)
MATCH (ca:GPO {name:'CertificateAuthority'})
WHERE NOT ca.epa_enabled = true
RETURN u.name, ca.dnshostname

Run it against your own collection. If you get rows back, you likely have an ESC11 path worth investigating.

4. The fix

  • Enable Extended Protection for Authentication on the CA web enrollment endpoints.
  • Disable NTLM on the CA's certificate enrollment service.
  • Enforce LDAP channel binding on all DCs.
  • Have someone test your AD CS infrastructure if it has not been assessed recently.