AD CS Certificate Template Abuse: The ESC1-ESC8 Escalation Paths and How to Audit Them

Active Directory Certificate Services (AD CS) is one of the most under-audited components of a Windows domain. It has usually been running since the environment was built, nobody remembers who configured the templates, and the people who administer it think of it as "the thing that issues Wi-Fi and VPN certs." Then a red team runs Certify or certipy find, and within minutes they have a certificate that authenticates as Domain Admin. The 2021 SpecterOps research that named the ESC1–ESC8 escalation paths turned AD CS from a quiet PKI service into one of the fastest routes to domain compromise — and most of the paths are pure misconfiguration, not a patchable bug.

Why certificates are a privilege-escalation goldmine

A certificate that supports client authentication is a durable credential. Unlike a password, it survives resets, it does not appear in most credential-hygiene tooling, and if it embeds a Subject Alternative Name (SAN) the CA will happily authenticate the holder as whoever that SAN says they are. Because AD CS is trusted domain-wide, a single template that lets a low-privileged user request a cert with an arbitrary SAN is effectively a "become anyone" button. Certificates are also long-lived, so a stolen or forged one can be a persistence mechanism that outlasts every password rotation.

The escalation paths at a glance

The ESC catalog splits into template misconfigurations, CA misconfigurations, and relay/coercion paths:

• ESC1 — A template allows low-privileged enrollment, permits the requester to supply a SAN (ENROLLEE_SUPPLIES_SUBJECT), and has a client-auth EKU. Request a cert as "Administrator" and log in as them.
• ESC2 — A template with the "Any Purpose" (or no) EKU, usable for anything including client auth.
• ESC3 — An Enrollment Agent template that lets an attacker request certs on behalf of other users.
• ESC4 — Weak access control on the template object itself: if you can write to the template, you can turn it into an ESC1 template.
• ESC5 — Weak ACLs on the broader AD CS PKI objects (CA object, NTAuthCertificates, the CA host).
• ESC6 — The CA has EDITF_ATTRIBUTESUBJECTALTNAME2 set, so every template effectively honors an attacker-supplied SAN.
• ESC7 — Dangerous CA permissions like ManageCA / ManageCertificates held by non-admins.
• ESC8 — The CA exposes HTTP web enrollment without Extended Protection, making it a relay target for coerced machine authentication.

ESC1 and ESC8 do the most damage in the wild: ESC1 because one sloppy template hands out domain admin, ESC8 because it pairs perfectly with coercion to forge a domain controller's certificate.

What ESC1 looks like in practice

The attacker enumerates templates, finds one that is enabled, allows domain-user enrollment, has an authentication EKU, and lets the enrollee supply the subject. They then request a certificate naming a privileged user, and authenticate with it via PKINIT to obtain that user's Kerberos ticket:

certipy find -u alice@corp.local -p ... -dc-ip 10.0.0.1 -vulnerable
certipy req -u alice@corp.local -p ... -ca CORP-CA \
   -template VulnTemplate -upn administrator@corp.local
certipy auth -pfx administrator.pfx -dc-ip 10.0.0.1

No exploit, no CVE — just a template that trusts the requester too much. That is exactly why this class of issue slips past patch-focused vulnerability scanners.

Hardening AD CS

1. Kill ESC1/ESC6 SAN abuse: remove ENROLLEE_SUPPLIES_SUBJECT from any client-auth template, and clear EDITF_ATTRIBUTESUBJECTALTNAME2 on the CA (certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2).
2. Require manager approval and authorized signatures on sensitive templates so requests are not auto-issued.
3. Tighten enrollment ACLs: restrict who can enroll, and lock down write access to template and CA objects to close ESC4/ESC5/ESC7.
4. Fix ESC8: disable HTTP web enrollment or enforce HTTPS with Extended Protection for Authentication, and require SMB/LDAP signing to break the relay leg.
5. Enable strong certificate mapping (KB5014754) so a certificate's SAN can no longer silently impersonate an account.

Where WinSentinel fits

The problem with AD CS is not that these settings are hard to fix — it is that nobody looks at them. The dangerous flags live in template definitions and CA registry keys that a human reviews maybe once a year. WinSentinel audits the machine-local ingredients of this attack surface directly: CA registry policy flags such as the SAN edit flag, web-enrollment exposure, the state of certificate-mapping enforcement, and the host's SMB/LDAP signing posture that determines whether an ESC8 relay can even land. All 33 modules run in full on a single machine for free with no limits, so an admin can validate a CA host or a suspect member server without a license.

Across a fleet, the risk is that one team hardens a template today and another clones a permissive one next quarter. WinSentinel Pro adds central orchestration for organizations: the node manages agents across every endpoint, rolls certificate-services findings into a single posture view, and fires drift alerts when a CA's SAN flag flips back on or web enrollment reappears months after you closed it. For deeper coverage of the relay side, pair this with our post on PetitPotam and NTLM coercion.

AD CS earns its trust from the whole domain, which is precisely why a single loose template is worth a domain to an attacker. Audit the templates and CA settings on purpose — because the one team that never checks is the one issuing certificates to everyone.