AD CS Vulnerabilities (ESC1–ESC8): How to Secure Your Microsoft PKI
Active Directory Certificate Services (AD CS) is often the forgotten link in Active Directory security. Deployed years ago and rarely audited, a Microsoft PKI can still issue certificates that open the doors to the entire domain.
In June 2021, researchers Will Schroeder and Lee Christensen (SpecterOps) published Certified Pre-Owned. The research describes eight misconfigurations, named ESC1 to ESC8, that allow a standard user to become a domain administrator. This article explains these AD CS vulnerabilities, how to detect them and how to protect against them.
Why AD CS is a prime target
- A certificate is as good as a password. Active Directory accepts certificates to authenticate users and machines (Kerberos PKINIT, Schannel).
- It survives a password change. A stolen certificate remains usable until it expires or is revoked, often a year or more.
- The CA is a critical but poorly protected asset. An enterprise certification authority is as sensitive as a domain controller, yet it is rarely managed with the same rigour.
ESC1 to ESC8 at a glance
| Code | Where the problem lies | Risk | Main fix |
|---|---|---|---|
| ESC1 | Certificate template: the requester supplies the subject name, the certificate allows authentication and enrollment is open to everyone | Obtain a certificate as an administrator | Disable “Supply in the request” or require certificate manager approval |
| ESC2 | Template with the “Any Purpose” EKU or no EKU at all | Certificate usable for any purpose, including authentication | Limit EKUs to what is strictly needed and restrict enrollment |
| ESC3 | “Enrollment Agent” template open to too many users | Request certificates on behalf of other people | Restrict the template to designated agents and configure enrollment agent restrictions on the CA |
| ESC4 | Excessive rights on a template (write, full control) | Reconfigure the template to make it vulnerable | Restrict template changes to PKI administrators |
| ESC5 | Excessive rights on PKI objects: CA server, PKI containers in Active Directory | Compromise of the entire PKI | Treat these objects as Tier 0 assets and audit their permissions |
| ESC6 | EDITF_ATTRIBUTESUBJECTALTNAME2 flag enabled on the CA | Any requester adds the identity of their choice to the certificate | Disable the flag and apply the KB5014754 updates |
| ESC7 | “Manage CA” or “Manage Certificates” roles granted too widely | Enable ESC6 or approve one’s own requests | Limit these roles to a small group of administrators |
| ESC8 | HTTP web enrollment (certsrv, CES) accepting NTLM authentication | NTLM relay to obtain a domain controller certificate | Enforce HTTPS with EPA, disable NTLM or remove unused web enrollment |
Certificate templates: ESC1 to ESC4
Most weaknesses are found in certificate templates. ESC1 is the most common: a template created for a legitimate purpose, such as a web server certificate, lets the requester choose the identity written in the certificate.
If that template also allows client authentication and every domain user can enroll, anyone can request a certificate as an administrator. ESC2 and ESC3 follow the same logic with overly broad usages. ESC4 makes it possible to create these situations by modifying a healthy template.
The CA and its infrastructure: ESC5 to ESC7
These vulnerabilities affect the certification authority itself. Excessive rights on the CA server, on its Active Directory objects or on its administrative roles give control of the whole PKI.
For ESC6, Microsoft strengthened the mapping between certificates and accounts with update KB5014754. Full Enforcement mode became the default in February 2025, and compatibility mode was removed in September 2025. The EDITF_ATTRIBUTESUBJECTALTNAME2 flag should still remain disabled.
NTLM relay: ESC8
The AD CS web enrollment interface accepts NTLM authentication over HTTP by default. An attacker can force a server, such as a domain controller, to authenticate to them and relay that authentication to the CA. They then obtain a certificate in that server’s name.
The PetitPotam technique, published in 2021, made this scenario widely known. If web enrollment is not used, the simplest fix is to uninstall it.
Auditing your PKI: where to start
- Take inventory. List your certification authorities and the templates published on each, for example with
certutil -CATemplates. Every published template should have a known purpose and an owner. - Use an audit tool. PSPKIAudit, released by SpecterOps with the research, and Locksmith, an open-source tool, automatically detect most ESC misconfigurations.
- Check the ESC6 flag. The command
certutil -getreg policy\EditFlagsshows whether EDITF_ATTRIBUTESUBJECTALTNAME2 is enabled. - Enable CA auditing. Monitor events 4886 and 4887 (certificate requests and issuance), and 4899 and 4900 (changes to a template and its permissions).
Essential protection measures
- Treat the CA as a Tier 0 asset, on a par with a domain controller, with an offline Root CA.
- Unpublish every unused certificate template.
- Allow “Supply in the request” only when essential, combined with manual approval.
- Limit each template’s usages (EKUs) to what is strictly needed.
- Restrict enrollment and modification rights on templates and PKI objects.
- Assign CA administration roles to a small, dedicated group.
- Disable the ESC6 flag with
certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2, then restart the certificate service. - Protect web enrollment with HTTPS and EPA, or remove it.
- Keep domain controllers up to date with security updates.
Beyond ESC8
Since 2021, the list has grown: new techniques, numbered ESC9 and beyond, have been published by the security community. A one-off audit is therefore not enough: the PKI must be reassessed regularly, like the rest of Active Directory.
Secure your PKI from day one
Our 4-day PKI training on AD CS teaches you how to design, deploy and manage a secure Microsoft PKI: offline Root CA, controlled certificate templates, revocation and auto-enrollment.
