SECNORA® is a CREST Accredited cyber security focused consulting firm with expertise in Information Security and Governance, Risk, Compliance.
Active Directory Certificate Services (ADCS) runs the public key infrastructure behind Windows authentication in most enterprise domains. It issues the certificates that let users log in, machines trust each other and services authenticate without a password crossing the wire. That same convenience is exactly why misconfigured ADCS for short, has become one of the more consistent paths to domain-wide privilege escalation over the last five years and why it’s worth a regular place on the security review calendar.
Independent security research first mapped this attack surface, documenting eight escalation paths known as ESC1 through ESC8. The security community has since extended that taxonomy all the way to ESC16, adding techniques uncovered through further research, CVE disclosures and real-world penetration testing engagements. The practical question isn’t whether every ESC technique applies to your environment. It’s whether certificate templates and CA configuration have been reviewed recently and how confident your team is in the answer.
A certificate template controls three things, who can request a certificate, what that certificate can be used for and how the certificate’s subject, the identity it represents, gets defined. Get any of those three wrong and a low-privileged domain user can end up holding a certificate that authenticates as a Domain Admin. The templates most organisations deploy by default were never designed with this attack path in mind. They were designed for convenience, auto-enrollment for machines, flexible subject naming for edge cases, broad enrollment rights so IT doesn’t have to manually approve every request.
Each of those conveniences maps directly to an ESC technique, which is what makes Active Directory Certificate Services such a productive target once an attacker has any foothold in the domain. Once exploited, these certificate-based attack paths can contribute to broader Active Directory compromise through privilege escalation and lateral movement. Understanding that trade-off is the first step to closing it.
ESC1 remains the most common and most reliable path to Domain Admin in ADCS environments. The vulnerability exists when a template allows low-privileged users to enroll and specifies that the enrollee can supply the Subject Alternative Name, while also permitting client authentication and requiring no manager approval. Under those conditions, a standard domain user can request a certificate and specify a Domain Admin account in the SAN field. The certificate authority has no reason to question the request and issues a valid certificate for that administrator.
ESC2 involves templates configured with an “Any Purpose” Enhanced Key Usage, or no EKU restriction at all. When a template lacks an EKU entirely or carries this setting, the resulting certificate can be used for almost anything. On its own, this doesn’t grant impersonation. With strong certificate mapping enforced, the default since Microsoft’s KB5014754 update, an Any Purpose certificate becomes dangerous only when paired with a SAN or SID injection path such as ESC6, ESC9 or ESC10.
ESC3 exploits Enrollment Agent templates. Enrollment Agents are permitted to request certificates on behalf of other users. If a template allows a standard user to request an Enrollment Agent certificate, and a second template allows that agent to request client authentication certificates for arbitrary users, the attacker can effectively become anyone in the domain.
ESC15, tracked as CVE-2024-49019, targets legacy version 1 templates that support Application Policies. Application Policies are a Microsoft-specific extension that, when present alongside an Enhanced Key Usage field, take precedence over it. Version 1 templates don’t validate the Application Policy field in a request which means an attacker can manipulate it to override the template’s intended EKU and turn a low-risk certificate into one valid for client authentication. Microsoft has since patched this vulnerability.
These techniques don’t depend on how a template is configured. They depend on who has write access to the template or CA objects in the first place which makes them a permissions and governance question rather than a settings one and a natural fit for a routine access review.
ESC4 applies when an attacker holds WriteOwner, WriteDACL or GenericWrite permissions on a certificate template object in Active Directory. A secure template can be temporarily reconfigured into an ESC1-vulnerable one, exploited to request an administrative certificate, and then reverted, which makes this a technique that leaves comparatively little trace if the attacker cleans up after themselves.
ESC5 extends the same idea to the broader PKI infrastructure. If an attacker can modify the CA object, the NTAuthCertificates object, or other critical PKI containers, they can introduce new vulnerabilities or get a rogue certificate authority trusted outright.
ESC7 targets permissions on the certificate authority itself. If a user holds ManageCA or ManageCertificates rights, they can manipulate CA settings remotely, force the CA to issue pending certificates or enable dangerous flags such as the one exploited in ESC6.
Microsoft’s KB5014754 hardening update reshaped this entire cluster of techniques. Legacy configuration, registry workarounds and incomplete rollout of the patch are what keep these vectors viable today.
ESC6 relies on the EDITF_ATTRIBUTESUBJECTALTNAME2 flag on the CA server, which, when enabled, accepts a user-supplied Subject Alternative Name from any request regardless of template settings. This effectively turns every template that allows client authentication into an ESC1 vector. Since KB5014754, certificates issued this way must carry the newer SID security extension or rely on weak mapping to still authenticate, so ESC6 exploitation alone is considerably less reliable than it once was. It’s typically chained with ESC9 or ESC10.
ESC9 exploits the CT_FLAG_NO_SECURITY_EXTENSION setting on a template, which omits the SID-based security extension Microsoft introduced to strengthen certificate mapping. In environments that still permit weak certificate mapping, attackers can abuse this configuration to impersonate privileged identities.
ESC10 covers weak certificate-to-account mapping at the domain controller level, either through writable altSecurityIdentities attributes on user accounts or permissive Schannel registry settings that allow partial subject matching rather than strict binding.
ESC13 abuses issuance policies linked to Active Directory groups through the msDS-OIDToGroupLink attribute. If a certificate template carries an issuance policy tied to a privileged, empty, universal-scope group such as Enterprise Admins, authenticating with a certificate from that template automatically grants the attacker membership in the linked group.
ESC14 covers a broader set of certificate mapping abuses, including writable altSecurityIdentities entries and shadow credential attacks carried out through the msDS-KeyCredentialLink attribute which can establish authentication paths that don’t go through standard certificate enrollment at all.
ESC16 is the CA-wide version of ESC9. Instead of a single template omitting the security extension, the szOID_NTDS_CA_SECURITY_EXT extension is disabled globally on the certificate authority, exposing every certificate that CA issues to implicit mapping attacks regardless of individual template settings. This technique has since been publicly documented in detail.
Active Directory Certificate Services supports various enrollment interfaces beyond the standard template-based flow, and some of these don’t enforce NTLM signing by default.
ESC8 targets the HTTP Web Enrollment endpoint, which Active Directory Certificate Services (ADCS) often hosts without requiring NTLM signing. An attacker can coerce a privileged machine account such as a domain controller, into authenticating to an attacker-controlled server, then relay that authentication to the ADCS HTTP endpoint. The attacker requests a certificate for the relayed machine account, obtaining a highly privileged credential in the process.
ESC11 functions similarly to ESC8 but targets the RPC-based MS-ICPR endpoint instead of the HTTP interface. If the certificate authority does not enforce RPC encryption, meaning the IF_ENFORCEENCRYPTICERTREQUEST setting is disabled, an attacker can relay NTLM authentication to the RPC interface to obtain certificates on behalf of coerced victims.
In Active Directory Certificate Services, ESC12 applies when a certificate authority stores its private keys on a hardware security module such as a YubiHSM, where the keys are meant to be physically isolated. If an attacker gains shell access to the CA server itself, they can abuse the logical connection between the server and the HSM to sign forged certificates or extract key material where the device is misconfigured. Physical key isolation alone doesn’t help once that logical connection is compromised.
The pattern across all sixteen techniques is consistent, none of them rely on a zero-day. Each one rests on a template, a permission or a CA setting that’s worth a periodic second look. That makes this an unusually tractable audit, not an open-ended threat and one that security and IT teams can work through without new tooling spend.
A few starting points worth prioritising:
Active Directory Certificate Services is one of the most trusted components of Windows identity infrastructure, but it also represents one of the largest privilege escalation surfaces when left unchecked. Most ESC techniques exploit certificate templates, access permissions, certificate mapping or Certificate Authority settings that have remained unchanged for years rather than sophisticated malware or zero-day vulnerabilities.
For defenders, the priority is clear: regularly audit certificate templates, review Certificate Authority permissions, verify certificate mapping configurations and secure enrollment endpoints against relay attacks. While Microsoft’s security improvements have strengthened certificate-based authentication, they do not eliminate the risks introduced by insecure configurations. Regular Active Directory Certificate Services (ADCS) assessments help ensure your PKI remains an asset for secure authentication instead of becoming an attacker’s path to Domain Admin.
https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-49019
SECNORA® is a CREST Accredited cyber security focused consulting firm with expertise in Information Security and Governance, Risk, Compliance.
Copyright @ 2026 SECNORA®