Active Directory Certificate Services

Active Directory Certificate Services (AD CS) is Microsoft’s PKI role for Active Directory: one or more Enterprise CAs issue certificates that back everything from EFS disk encryption to smart-card logon and, critically for attackers, Kerberos authentication via PKINIT. AD CS is not installed by default, but SpecterOps found it deployed in most enterprise environments they audited — and nearly every deployment they examined had at least one domain-escalation misconfiguration. Their June 2021 whitepaper Certified Pre-Owned (Will Schroeder & Lee Christensen) cataloged these as ESC1–ESC8.

Certificate templates

Enterprise CAs don’t hand-review each CSR. Instead they publish certificate templates — AD objects bundling a subject policy, extended key usages (EKUs), enrollment permissions (a security descriptor), and issuance requirements. When a CSR arrives, the CA checks whether a published template matches and whether the requester is allowed to enroll, then issues automatically. This automation is the attack surface: a template whose settings and ACL are too permissive lets any low-privilege user mint a certificate they should never have.

Enumerating templates

From a domain-joined, domain-authenticated context, the built-in certutil dumps every published template with its full configuration:

certutil -v -template

The verbose output includes, per template: the security descriptor (who has Allow Enroll / Allow Full Control), EKUs, issuance requirements (manager approval, authorized signatures), and the subject-name flags. Modern tooling automates the analysis — Certify (SpecterOps C#) find /vulnerable and Certipy (Python, Linux-friendly) find -vulnerable both flag ESC-class misconfigurations directly — but certutil -v -template works with nothing but built-ins, which is why it remains the baseline enumeration primitive.

ESC1 — the template to hunt for

The highest-value find is a template vulnerable to ESC1 (domain escalation via misconfigured template). All of the following must hold:

  1. Enrollment rights for low-privileged users — the template’s ACL grants Allow Enroll (or Allow Full Control) to a group you control (often Domain Users), and the Enterprise CA itself permits low-privileged enrollment.
  2. Manager approval disabled — no certificate-manager sign-off required.
  3. No authorized signatures required on the CSR.
  4. EKU enables client authentication — Client Authentication (1.3.6.1.5.5.7.3.2), PKINIT Client Authentication, Smart Card Logon, Any Purpose, or no EKU (SubCA).
  5. The requester can supply the subjectAltName (SAN) — the template’s mspki-certificate-name-flag property includes CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT (surfaced as “Supply in request” on the Subject Name tab of certtmpl.msc).

With all five, an attacker requests a certificate in the name of any other principal — e.g. a Domain Admin — by setting the SAN to that user’s UPN. The resulting certificate authenticates to Kerberos via PKINIT: present it (with Rubeus asktgt /certificate: or Certipy auth) and the KDC issues a TGT as the victim, plus their NT hash via the Kerberos PAC credentials extension. The certificate is also a durable credential — valid until it expires, independent of password resets.

Closely related classes: ESC2 (Any Purpose / SubCA EKU templates — request as yourself, use for anything), ESC3 (enrollment-agent templates chained for on-behalf-of requests), ESC4 (write access to a template’s ACL lets you push an ESC1-style misconfiguration onto an otherwise-safe template), and ESC8 (NTLM relay to AD CS HTTP enrollment endpoints — see ntlm-relay-attacks).

Defense

  • Audit every published template for the ESC1 five-condition combination; remove CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT unless a business process genuinely needs it.
  • Enforce manager approval / authorized signatures on sensitive templates, and tighten template ACLs so enrollment rights aren’t granted to broad groups.
  • Monitor CA-issued certificate events for SANs that don’t match the requester, and alert on enrollment by unexpected principals.
  • Microsoft’s May 2022+ hardening (KB5014754) changes certificate-to-account mapping and disrupts some classic abuse — but does not fix over-permissive templates, which remain the root cause.

Related: kerberos, rubeus, kerberoasting, ntlm-relay-attacks.

Sources