ADCS ESC2, ESC3, ESC5, ESC7: Certificate Escalation Paths Between the Famous Ones

What Is ADCS ESC2 ESC3 ESC5 ESC7 Certificate Escalation Paths

ADCS ESC2 ESC3 ESC5 ESC7 certificate escalation paths sit in the gap between two well-covered ends of the Active Directory Certificate Services (AD CS) attack surface. SpecterOps' Certified Pre-Owned research named eight techniques, ESC1 through ESC8, and later research added ESC9, ESC10, and ESC11 on top of that. This corpus already has both ends: ADCS Attack Paths Explained covers ESC1, ESC4, ESC6, and ESC8, and ADCS ESC9, ESC10, ESC11: Certificate Escalation Paths Beyond ESC1-ESC8 covers the binding-layer techniques published after KB5014754. ESC2, ESC3, ESC5, and ESC7 are the four techniques from the original SpecterOps numbering that neither article tags.

That gap matters because these four are not a random leftover, and they chain into the same Active Directory attack paths that BloodHound-style analysis maps for every other Tier 0 technique. ESC2 and ESC3 are template-level techniques, like ESC1, but instead of a template that leaks who a certificate can authenticate as, they leak what a certificate can be used for once issued — either any purpose at all, or the specific purpose of requesting certificates on behalf of someone else. ESC5 and ESC7 are access-control techniques, like ESC4, but instead of an ACL on one certificate template, they sit on the objects and permissions that control every template and every certificate the CA will ever issue: the CA's own access control, and the PKI containers in Active Directory that hold the templates, the CA registrations, and the list of CAs domain controllers trust for authentication.

An environment that has already remediated every ESC1, ESC4, ESC6, and ESC8 finding, and every ESC9, ESC10, and ESC11 finding, can still have a live path to Domain Admin through these four — because none of the other checks look at EKU scope, enrollment agent delegation, or PKI object and CA-level access control.

How It Works

ESC2 — Any Purpose or No-EKU Templates

ESC2 is a certificate template whose Extended Key Usage (EKU) is either the Any Purpose OID (2.5.29.37.0) or has no EKUs defined at all, which Windows treats as a Subordinate CA-equivalent template usable for any purpose. Per SpecterOps' Certify documentation, exploiting this requires all of the following at once: the attacker's principal has enrollment rights at the CA level, the same principal has enrollment rights on the specific template, the template does not require manager approval, the template does not require authorized (co-signed) signatures, and the template's EKU is Any Purpose or absent entirely.

When those conditions line up, the attacker enrolls a certificate from the template and gets a credential that Windows will accept for any certificate-consuming purpose — including, per SpecterOps' documentation, the same "Certificate Request Agent" role that ESC3 depends on. In other words, an ESC2 template can be used to bootstrap an ESC3-style enrollment agent attack even though it never declares the Certificate Request Agent EKU explicitly. That is also why ESC2 findings should always be checked against the CA's other published templates before being dismissed as low severity: an Any Purpose certificate is only as dangerous as what else the CA lets it be redeemed for.

ESC3 — Enrollment Agent Templates (Two-Template Chain)

ESC3 is a two-template chain, not a single misconfiguration. The first template must carry the Certificate Request Agent EKU (OID 1.3.6.1.4.1.311.20.2.1) — the same OID Microsoft documents as the enrollment agent application policy extension used for smart card issuance. Per SpecterOps' documentation, the first-stage template needs the same enrollment prerequisites as ESC2 (CA-level and template-level enrollment rights, no manager approval, no authorized signatures) plus that specific EKU.

Once the attacker holds that enrollment agent certificate, they need a second template: one that does not restrict who can act as an enrollment agent, that the attacker can enroll in, that does not require manager approval, and whose EKU is compatible with the agent role — client authentication, PKINIT, smart card logon, Any Purpose, or no EKU at all. With both pieces in place, the attacker requests a certificate from the second template on behalf of a target identity, such as a Domain Admin, using the enrollment agent certificate to sign the request. The resulting certificate authenticates as the target, not as the attacker.

Microsoft's own documentation on the Restricted Enrollment Agent feature, introduced in Windows Server 2008 Enterprise, describes exactly why this is dangerous by default: prior to that feature, "it is not possible to permit an enrollment agent to enroll only a certain group of users," so any valid enrollment agent certificate could be used to request a certificate on behalf of any user in the organization, including Domain Admins. Restricted Enrollment Agent lets a CA administrator scope which templates and which target security groups each enrollment agent certificate can be used against — but only on an Enterprise Edition CA, and only if it has actually been configured.

ESC5 — Vulnerable PKI Object Access Control

ESC5 is not a template problem at all. It is an Active Directory ACL problem on the objects that make the entire PKI trustworthy. Per SpecterOps' documentation, the objects in scope are:

• the CA server's own AD computer object
• the CA server's RPC/DCOM server
• the Public Key Services container tree in the Configuration naming context (CN=Public Key Services,CN=Services,CN=Configuration,DC=...), including its Certificate Templates, Certification Authorities, and Enrollment Services sub-containers
• the NTAuthCertificates object inside that container

Per Microsoft's own [MS-WCCE] protocol documentation, the NTAuthCertificates object holds a multivalue attribute of DER-encoded CA signing certificates — in practice, the list of CAs that domain controllers trust for certificate-based authentication (including smart card logon). If an attacker can write to that object, they can add a rogue CA to the trust list; every certificate that rogue CA subsequently signs becomes trusted for domain authentication. SpecterOps' documentation gives a concrete example of the general risk: Domain Users holding GenericAll on the Certificate Templates container and its descendants — full control over every certificate template definition in the forest, from a default-scoped group.

The severity of an ESC5 finding depends entirely on which object is exposed and to whom. Write access to the Certificate Templates container lets an attacker create or modify templates into an ESC1/ESC2/ESC3 shape from scratch, bypassing any hardening already done to the existing templates. Write access to the CA's computer object or its RPC/DCOM server can lead to compromise of the CA host itself, and with it, the CA's private key — the same class of impact documented in Certighost CVE-2026-54121, where a different AD CS flaw let a low-privileged user impersonate a domain controller.

ESC7 — Vulnerable Certificate Authority Access Control

ESC7 lives on the CA object's own security descriptor, not on AD objects at all — and unlike ESC6, it is not a registry flag. Windows CAs support role separation through two access rights configurable in the Certification Authority console's Security tab: ManageCA (the CA Administrator role) and ManageCertificates (the Certificate Manager / Officer role).

Per SpecterOps' documentation, holding ManageCA lets a principal change CA-wide configuration — including toggling the EDITF_ATTRIBUTESUBJECTALTNAME2 flag that ESC6 depends on, re-enabling previously disabled vulnerable templates, and enabling the conditions ESC11 and ESC16 rely on. That means an attacker who only holds ManageCA — with no template misconfiguration in sight — can manufacture ESC6 or ESC11 conditions on demand. SpecterOps' documentation also describes a more direct ManageCA abuse: request a certificate from a template that requires manager approval, let the request fail and be held pending, then use ManageCA together with ManageCertificates to force-issue that pending request regardless of the approval requirement that was supposed to block it.

ManageCertificates alone lets a principal manage and issue certificates that are pending approval. Per SpecterOps' documentation, this enables an ESC1-style bypass through group-linked issuance policies: request a certificate from an approval-gated template, use ManageCertificates to inject a group-linked issuance policy OID into the pending request, then issue it — obtaining a certificate whose issuance policy maps to a privileged group, without ever satisfying the manager-approval control the template was configured to enforce.

The Attack Chain

The pattern across all four: ESC2 and ESC3 abuse what a template is allowed to do once a certificate comes out of it; ESC5 and ESC7 abuse who is allowed to control the templates and the CA in the first place. That second category is why remediating every individual template flagged by ESC1, ESC2, ESC3, ESC4, or ESC6 does not close the door — an attacker with ESC5 or ESC7 access can simply recreate the vulnerable condition after the review is done.

🚨 Danger: ESC3 and the write-access variants of ESC5 both end in the same outcome as ESC1 — a certificate that authenticates as a target identity, which can be converted into a Kerberos TGT and used to impersonate that identity, including a Domain Admin. Escalation into a PKI object's ACL frequently starts as ordinary ACL abuse and DCSync reconnaissance rather than an AD CS-specific technique.

Detection

Remediation

1. Remove Any Purpose and no-EKU authentication templates (ESC2). Restrict every published template's EKU list to only what it actually needs. If a template genuinely needs to be reusable across multiple purposes, keep manager approval and authorized-signature requirements in place instead of relying on a narrow EKU alone.
2. Restrict enrollment agent templates (ESC3). Configure Restricted Enrollment Agent on every Enterprise Edition CA that issues Certificate Request Agent certificates, scoping each enrollment agent to specific templates and specific target security groups rather than leaving it unrestricted. Where restricted enrollment agent is not available, limit who can enroll in the enrollment agent template to the smallest possible, closely managed group.
3. Harden PKI object ACLs (ESC5). Review the ACLs on the Certificate Templates, Certification Authorities, and Enrollment Services containers, on the NTAuthCertificates object, and on each CA server's AD computer object. Remove GenericAll, WriteDacl, WriteOwner, and equivalent rights from any principal outside the intended Tier 0 PKI administration group.
4. Tighten CA role separation (ESC7). Review the Security tab of every CA and confirm that Manage CA and Issue and Manage Certificates are held only by the accounts that need them. Treat both as Tier 0-equivalent privileges, not general IT-admin defaults — see Hardening Active Directory for how these fit into a broader Tier 0 privilege review.
5. Review pending-request handling. Confirm that force-issuing a denied or pending certificate request is not routinely available to the same principals who can also request certificates — that combination is exactly what makes the ESC7 approval bypass possible.
6. Re-test after every change. Enrollment agent restrictions and PKI ACL changes can break legitimate smart card issuance and delegated administration workflows. Validate with a representative pilot group before enforcing changes CA-wide, and keep the CA audit log review from the detection section running through the rollout.

Where This Fits: ANSSI R36, R37, and the Rest of the ADCS Corpus

ANSSI's guide on securely administering Active Directory (ANSSI-PA-099) treats PKI risk to Tier 0 as its own numbered recommendation, independent of general certificate hygiene. R36 states that whenever a PKI can generate certificates usable for authentication into Tier 0, that PKI "must not offer attack paths to Tier 0 from lower-trust tiers, whether through the administration of the systems that host it, through delegation of rights over certificate-generation capabilities, or through published certificate templates" — a near-exact description of what ESC5 and ESC7 abuse (delegated control over certificate-generation capability, i.e. the CA and its PKI objects) and what ESC2 abuses (published templates that grant more capability than intended). The same guide separately calls out R37, which addresses certificate cryptographic strength (banning DSA signatures, requiring SHA-2/SHA-3 hashes, and setting minimum RSA key sizes) — a real but distinct concern from the EKU and ACL misconfigurations covered here, worth auditing alongside these four techniques rather than instead of them.

This article deliberately does not restate ESC1, ESC4, ESC6, or ESC8 — see ADCS Attack Paths Explained for those — or ESC9, ESC10, ESC11, which live in the certificate-mapping and RPC-encryption layer covered in ADCS ESC9, ESC10, ESC11 and its companion piece on weak certificate mapping. A complete AD CS review needs all three articles, plus the broader Tier 0 checklist in Audit Active Directory Security, because none of the eleven techniques substitute for another.

How EtcSec Detects This

EtcSec's AD audit checks map directly to each technique covered here: ESC2_ANY_PURPOSE flags authentication-capable templates with an Any Purpose or empty EKU and no approval gate, ESC3_ENROLLMENT_AGENT flags Certificate Request Agent templates and their unrestricted downstream targets, ESC5_PKI_OBJECT_ACL reviews ACLs on the Public Key Services container tree, NTAuthCertificates, and CA computer objects, and ESC7_CA_VULNERABLE_ACL reviews CA-level role separation for over-broad ManageCA and ManageCertificates grants. Findings from all four roll up into PATH_CERTIFICATE_ESC when they form a live path to Domain Admin, so a template flag or an ACL entry is prioritized by whether it is actually reachable — not flagged in isolation.

Primary References

• SpecterOps / Certify — Escalation Techniques Overview
• SpecterOps / Certify — ESC2: Misconfigured Any Purpose
• SpecterOps / Certify — ESC3: Misconfigured Certificate Request Agent
• SpecterOps / Certify — ESC5: Vulnerable PKI Object Access Control
• SpecterOps / Certify — ESC7: Vulnerable Certificate Authority Access Control
• Certified Pre-Owned: Abusing Active Directory Certificate Services
• Microsoft: AD CS Restricted Enrollment Agent
• Microsoft: [MS-WCCE] NTAuthCertificates Object
• ANSSI-PA-099: Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory