In June 2021, Will Schroeder and Lee Christensen from SpecterOps published Certified Pre-Owned. The paper systematically documented how Active Directory Certificate Services could be abused for privilege escalation and domain persistence. They classified these attack paths as ESC1 through ESC8.
Since then, the list has grown. ESC9 through ESC14 have been documented by the security community. Each new finding confirms the same fundamental problem: ADCS was designed for convenience, not for adversarial conditions.
This article provides a technical overview of every known ESC class. Not as a penetration testing guide, but as an architectural analysis of why these vulnerabilities exist and what they reveal about the ADCS security model.
ESC1: Misconfigured Certificate Templates
The most exploited ESC class. A certificate template allows the requester to supply a Subject Alternative Name (SAN). If low-privileged users can enroll, they can request a certificate for any user, including Domain Admins.
Three conditions must be met simultaneously: the template allows SAN specification, enrollment is permitted for unprivileged users, and the Extended Key Usage includes Client Authentication or Smart Card Logon.
The root cause is not a bug. It is a design choice. ADCS allows flexible SAN configuration to support legitimate scenarios. But the default permissions rarely restrict who can use that flexibility.
ESC2: Misconfigured Certificate Templates (Any Purpose)
Similar to ESC1, but the template's EKU is set to "Any Purpose" or contains no EKU at all. A certificate with no EKU restriction can be used for client authentication, code signing, or any other purpose.
The result is the same: a low-privileged user obtains a certificate that grants domain-wide access.
ESC3: Enrollment Agent Abuse
ADCS supports a delegation model where Enrollment Agents can request certificates on behalf of other users. If the Enrollment Agent template is available to unprivileged users, an attacker enrolls as an agent, then requests certificates for privileged accounts.
This is a two-step attack that exploits a legitimate delegation mechanism. The permissions model makes it difficult to restrict without breaking existing workflows.
ESC4: Vulnerable Certificate Template ACLs
The certificate template object itself has an Access Control List in Active Directory. If a low-privileged user has write access to the template (WriteProperty, WriteDacl, or WriteOwner), they can modify the template to enable ESC1 conditions, request the certificate, then revert the changes.
The attack window can be seconds. Auditing template modifications is not enabled by default.
ESC5: Vulnerable PKI Object ACLs
Extends ESC4 beyond templates. Any PKI-related object in Active Directory with weak ACLs becomes a target: the CA object itself, the NTAuthCertificates object, the PKI container, or the Enrollment Services container.
Control over these objects can lead to adding rogue CAs to the NTAuth store, which means the domain trusts certificates issued by the attacker.
ESC6: EDITF_ATTRIBUTESUBJECTALTNAME2
A flag on the CA configuration itself. When this flag is enabled, the CA allows the requester to specify a SAN in any certificate request, regardless of what the template says.
This effectively turns every template into an ESC1-vulnerable template. The flag was historically enabled by many administrators because Microsoft documentation suggested it for certain use cases. A single registry value compromises the entire CA.
ESC7: Vulnerable CA ACLs
If a user has ManageCA or ManageCertificates permissions on the Certificate Authority, they can modify the CA configuration (enabling EDITF_ATTRIBUTESUBJECTALTNAME2), approve pending requests, or issue certificates directly.
Combined with ESC6, ManageCA access provides a direct path to domain compromise.
ESC8: NTLM Relay to AD CS HTTP Endpoints
ADCS exposes HTTP enrollment endpoints (Certificate Enrollment Web Service, Certificate Enrollment Policy Web Service). These endpoints often accept NTLM authentication without Extended Protection for Authentication (EPA).
An attacker who can coerce NTLM authentication from a domain controller (using PetitPotam, PrinterBug, or similar techniques) relays the authentication to the ADCS HTTP endpoint and obtains a certificate for the domain controller. This certificate grants full domain compromise.
ESC8 is particularly devastating because it combines two widespread weaknesses: NTLM relay and ADCS HTTP endpoints. It requires no prior privileges on the ADCS infrastructure.
ESC9: No Security Extension on Certificates
Introduced in research following the original paper. When the szOID_NTDS_CA_SECURITY_EXT extension is not enforced, the mapping between a certificate and an Active Directory account relies solely on the SAN or Subject fields. An attacker with write access to another user's userPrincipalName can obtain a certificate, then change the UPN back.
The certificate remains valid and maps to the target account.
ESC10: Weak Certificate Mappings
Related to ESC9. If the domain controller uses weak mapping for certificate authentication (registry key StrongCertificateBindingEnforcement set to 0 or 1), an attacker can exploit the mapping logic to authenticate as another user.
Microsoft addressed this progressively through KB5014754, but many environments delay enforcement due to compatibility concerns.
ESC11: NTLM Relay to ICPR (RPC)
Similar to ESC8, but targeting the RPC-based enrollment interface (ICertPassage Remote Protocol) instead of HTTP. If the CA does not enforce Packet Privacy on the RPC interface, NTLM relay attacks are possible.
This variant is less widely known than ESC8 but affects environments that disabled the HTTP endpoints thinking they were safe from relay attacks.
ESC12: CA Stored on ESA Shell Access
When the CA's private key is stored in a way accessible to administrators with shell access on the CA server, the key material can be extracted. This is not strictly an ADCS protocol vulnerability, but an operational risk inherent to how many organizations deploy their CAs.
A compromised CA private key means every certificate ever issued by that CA must be considered untrusted.
ESC13: OID Group Link Abuse
Documented in 2024. ADCS allows linking an issuance policy OID to a security group. If a user can obtain a certificate with that issuance policy, the certificate effectively grants the permissions of the linked group.
An attacker who can enroll in a template with a linked OID policy gains the group membership without being a direct member. This bypasses traditional group-based access controls.
The Pattern: Design, Not Bugs
Every ESC class shares common characteristics.
They exploit features that work as designed. Templates, enrollment agents, ACLs, CA flags, NTLM authentication are all legitimate ADCS mechanisms.
They are difficult to detect. Most attacks leave minimal traces in default audit configurations. Template modifications can be reverted. Certificates are valid for their entire lifetime.
They are difficult to prevent without reducing functionality. Restricting template permissions, disabling NTLM, enforcing strong certificate mapping, all require significant operational effort and can break existing workflows.
Patching addresses specific attack vectors but does not change the architecture. ESC1 existed from the day ADCS was released. ESC13 was documented over twenty years later. The discovery curve is not flattening.
What This Means for PKI Strategy
The ESC series demonstrates that ADCS security is fundamentally limited by its architecture. Deep integration with Active Directory means every AD permission misconfiguration is potentially a PKI vulnerability. Default configurations prioritize usability over security. The attack surface grows with every template, every enrollment endpoint, and every CA trust relationship.
For organizations running ADCS, the immediate priorities are clear: audit template permissions, disable EDITF_ATTRIBUTESUBJECTALTNAME2, enforce strong certificate mapping, restrict CA administrative permissions, and remove unnecessary HTTP endpoints.
But these are mitigations, not solutions. The underlying architecture remains.
The strategic question is whether ADCS should continue to be the central PKI component, or whether new certificate requirements should be handled by infrastructure designed with these threat models in mind. A governance layer that provides visibility across all certificate authorities, enforces consistent policies, and detects anomalous issuance patterns addresses the systemic risk that per-CA hardening cannot.
