AD CS: reading ESC1 to ESC8 without being a PKI expert
A misconfigured Active Directory certificate authority lets an ordinary user obtain a certificate as a domain administrator. The ESC scenarios describe how; you only need to know how to read them to close them.
A forgotten PKI, a shortcut to the domain
Active Directory Certificate Services are often installed once, for Wi-Fi or VPN, then forgotten. Yet a certificate that allows client authentication is as good as a password: whoever obtains a certificate in a domain admin's name can authenticate as them. Research published in 2021 under the title "Certified Pre-Owned" classified these abuses into numbered scenarios, ESC1, ESC2 and so on. Here is how to read them without being a specialist.
ESC1: the requester chooses the identity
The most common scenario. A certificate template combines four conditions: it allows client authentication, domain users can enroll, no approval is required, and the requester can supply the subject name themselves (the "Supply in the request" option). Any user can then request a certificate as the administrator of their choice.
ESC2 and ESC3: usages that are too broad
ESC2 covers templates allowing "any purpose", or with no usage restriction at all: the certificate can then be used to authenticate. ESC3 covers enrollment agent templates, which allow requesting certificates on behalf of other users. Open to too many people, they lead to the same result as ESC1.
ESC4 and ESC7: rights over the PKI itself
ESC4: a non-privileged group has write rights on a certificate template. It can reconfigure it to be vulnerable to ESC1, use it, then restore it. ESC7: management rights on the certificate authority itself ("Manage CA", "Manage Certificates") allow approving pending requests or changing its configuration.
ESC6 and ESC8: the authority's configuration
ESC6: the EDITF_ATTRIBUTESUBJECTALTNAME2 flag enabled on the CA lets anyone add an alternative name to any request, turning every authentication template into ESC1. ESC8: the CA's HTTP web enrollment accepts NTLM authentication; an attacker who coerces a domain controller into authenticating to them can relay that authentication and obtain a certificate as the domain controller.
Why it matters. A certificate stays valid after a password change. Until it is revoked or expires, the access persists.
Audit and fix
- Inventory the published templates and, for each: usage, enrollment rights, approval, source of the subject name.
- Remove "Supply in the request" from authentication templates, or require certificate manager approval.
- Restrict write rights on templates and management rights on the CA to Tier 0.
- Disable the
EDITF_ATTRIBUTESUBJECTALTNAME2flag if present. - Protect web enrollment: HTTPS with Extended Protection for Authentication, or disable it if unused.
- Apply strong certificate mapping, now enforced by Microsoft on up-to-date domain controllers.
Free tools such as Locksmith or Certify produce this inventory in minutes. The certificate authority itself must be treated for what it is: a Tier 0 asset.