AD CS ESC1: how a certificate template becomes domain admin

Active Directory Certificate Services is part of your identity trust, and a single template misconfiguration (the one tracked as ESC1) can let an ordinary user mint a certificate that authenticates as a Domain Admin.

The misconfiguration

ESC1 exists when a certificate template combines four things: low-privileged users can enroll, the template allows the enrollee to supply the subject (the ENROLLEE_SUPPLIES_SUBJECT flag), the certificate is valid for client authentication, and manager approval is not required. With those in place, an attacker requests a certificate and sets the Subject Alternative Name to a privileged account, for example a Domain Admin user principal name. The CA issues it. The attacker then authenticates with that certificate over Kerberos PKINIT and is now that admin. Tools like Certipy automate the whole chain. In ATT&CK terms this is T1649, Steal or Forge Authentication Certificates.

How to detect it

Watch the CA security log for Event 4886 and 4887 (certificate requested and issued) where the requester and the subject do not match, especially a low-privileged requester naming a privileged SAN. Auditing certificate templates for the ENROLLEE_SUPPLIES_SUBJECT flag plus a client-auth EKU finds the exposure before it is used.

How to fix it

Remove the ENROLLEE_SUPPLIES_SUBJECT flag from templates that do not genuinely need it, require manager approval for sensitive templates, and restrict who can enroll. Apply Microsoft’s strong certificate mapping enforcement (the KB5014754 changes) so a SAN cannot silently impersonate an account. Then inventory every template, because ESC1 is one of several AD CS escalation paths and the others deserve the same review.

Practice it

We built an AD CS ESC1 scenario in GraphLattice Range so administrators can find the bad template, exploit it once, and lock it down.