ADCS ESC1-ESC16 Detection Playbook

Our AD CS Template Hardening: ESC1-ESC16 Defense Playbook covers how to fix each of these sixteen escalation paths. It doesn’t answer the question that comes first: do you actually have any of them right now. This is the detection-focused companion, configuration checks and detection logic for all sixteen ESC paths, grouped by category, with prioritization guidance, false-positive considerations, and how to actually verify a fix closed the gap.

TL;DR: Key Takeaways

All sixteen ESC paths fall into four detectable categories: template misconfigurations, CA and object access control weaknesses, network and relay-based paths, and certificate mapping weaknesses, each with its own primary data source.
ESC1, ESC3, ESC7, and ESC8 deserve first priority, they combine real-world prevalence with a low exploitation bar and a fast, single-query detection check.
ESC9, ESC10, ESC14, and ESC16 overlap directly with strong certificate mapping enforcement, covered in depth in our dedicated mapping guide, don’t treat these as a separate detection effort from that work.
Most false positives come from legitimate, documented delegation, an enrollment agent, an approved manager-review workflow, or authorized HSM administration, that superficially resembles the misconfiguration pattern, cross-reference against your actual documented scope before escalating.
A fix isn’t verified until the original detection query returns clean again, applying a remediation step without re-running the check that found it leaves the fix unconfirmed.

The Complete ESC1-ESC16 Detection Reference

ESC	Category	What to Check	Primary Data Source
ESC1	Template	Enrollee-supplied subject + client auth/smart card EKU + no manager approval + broad enroll rights	Template configuration
ESC2	Template	Any Purpose EKU or no EKU restriction on an enrollable template	Template configuration
ESC3	Template	Certificate Request Agent EKU with no enrollment agent restrictions	Template configuration + agent restriction policy
ESC4	Template	Write access (WriteDACL/WriteOwner/GenericAll) on a template object held by an unexpected principal	AD object ACLs
ESC5	CA/Object ACL	Excessive access to PKI-adjacent AD objects or the CA computer object itself	AD object ACLs
ESC6	CA Configuration	EDITF_ATTRIBUTESUBJECTALTNAME2 enabled CA-wide	`certutil -getreg policy\EditFlags`
ESC7	CA/Object ACL	Manage CA or Manage Certificates rights held by an unexpected principal	CA security configuration
ESC8	Network/Relay	Web enrollment without HTTPS enforcement or Extended Protection for Authentication	IIS configuration
ESC9	Mapping	Template configured without the security extension (CT_FLAG_NO_SECURITY_EXTENSION)	Template configuration
ESC10	Mapping	Weak certificate mapping registry settings, or UPN-based mapping still enabled	Domain controller registry configuration
ESC11	Network/Relay	Missing IF_ENFORCEENCRYPTICERTREQUEST flag on the CA’s RPC interface	CA interface configuration
ESC12	CA/Object ACL	Shell access to a CA server backed by a hardware token allowing direct key access	Server access control, HSM configuration
ESC13	Template	Issuance policy OID linked to a privileged AD group	Certificate template issuance policy configuration
ESC14	Mapping	Weak or overly permissive explicit mapping via altSecurityIdentities	AD account attribute review
ESC15	Template	Schema version 1 template on an unpatched CA (CVE-2024-49019)	Template schema version + CA patch level
ESC16	CA Configuration	Security extension disabled CA-wide, not just per-template	CA configuration

Detecting Template-Based Escalations (ESC1, ESC2, ESC3, ESC4, ESC13, ESC15)

ESC1, the highest-prevalence finding in most assessments: query every template for the combination of enrollee-supplied subject, a client authentication or smart card logon EKU, no manager approval requirement, and enrollment rights broader than a specifically restricted group. All four conditions together are what make the path exploitable, any one alone is not sufficient grounds for escalation.
ESC3, enrollment agent abuse: identify every template carrying the Certificate Request Agent EKU, then check whether the CA or template restricts which target accounts an agent can request on behalf of. A template with this EKU and no restriction configured is a positive finding regardless of whether abuse has actually occurred yet.
ESC4, template ACL abuse: review every certificate template’s access control list for WriteDACL, WriteOwner, or GenericAll grants held by a principal without a documented delegation reason, this is a directory permissions review, not a certificate configuration review, covered in more depth in our attack path guidance.
ESC13, privileged issuance policy links: check whether any certificate template’s issuance policy OID is linked to a privileged AD group. This is a less common finding but a severe one when present, since it ties certificate issuance directly to group membership escalation.
ESC15, schema version 1 exposure: check every template’s schema version against your CA’s patch level for CVE-2024-49019, covered in full detail in our dedicated detection and remediation guide. This is worth checking independently of ESC1, a template hardened against ESC1 can still be exposed here if it remains schema version 1 on an unpatched CA.

Detecting CA and Object Access Control Escalations (ESC5, ESC6, ESC7, ESC12, ESC16)

ESC6, the CA-wide SAN flag: run certutil -getreg policy\EditFlags against every CA and check specifically for EDITF_ATTRIBUTESUBJECTALTNAME2. Because this flag exposes every template on the CA, not just one, it deserves its own standing check independent of any template-level review, covered in depth in our SAN extension guide.
ESC7, CA-level permission grants: review who holds Manage CA and Manage Certificates rights directly on each CA object, against your documented list of authorized administrators. This check needs to happen separately from template permission review, since it grants control across every template a CA hosts at once.
ESC5 and ESC12, broader object and physical access control: ESC5 covers excessive access to PKI-adjacent AD objects generally, ESC12 covers the specific, narrower case of shell access to a CA server backed by a hardware token that permits direct key extraction. Both require reviewing access control outside the certificate configuration itself, at the AD object and server administration level.
ESC16, CA-wide security extension disablement: distinct from ESC9, this is a CA-level setting removing the security extension from every certificate issued, not a single template’s configuration, check this at the CA configuration level specifically, not by sampling individual templates.

Detecting Network and Relay-Based Escalations (ESC8, ESC11)

ESC8, web enrollment relay: confirm every web enrollment endpoint enforces HTTPS and has Extended Protection for Authentication enabled, this is the same check covered in our NDES hardening and attack path guidance, applied here specifically to standard web enrollment rather than NDES’s SCEP-specific endpoints.
ESC11, RPC relay: confirm the CA’s interface configuration includes the IF_ENFORCEENCRYPTICERTREQUEST flag, its absence leaves the RPC-based enrollment interface open to the same fundamental relay risk as ESC8, just through a different protocol.
Both checks are configuration reviews, not log-based hunts, unlike most of the template and mapping checks in this playbook, these are best confirmed by directly inspecting the relevant service configuration rather than searching historical activity for evidence of abuse.

Detecting Certificate Mapping Weaknesses (ESC9, ESC10, ESC14)

These three overlap directly with strong certificate mapping enforcement, covered in full in our complete strong mapping guide, treat that guide’s detection and remediation content as the primary reference rather than duplicating a separate effort here.
ESC9 specifically: check for templates with CT_FLAG_NO_SECURITY_EXTENSION set, combined with domain controllers that don’t enforce strong certificate binding, this combination is what makes the missing extension actually exploitable rather than a benign configuration gap.
ESC10 and ESC14 specifically: review domain controller registry settings for weak mapping methods still enabled, and review altSecurityIdentities attributes across privileged accounts for overly permissive explicit mappings, both are AD-side checks rather than CA-side ones.

Prioritization Logic

Fix ESC1, ESC3, ESC7, and ESC8 first, this combination reflects both real-world prevalence in independent assessments and a low bar for exploitation once a finding exists, each is also detectable with a single, fast configuration check, making them efficient first targets.
Prioritize ESC6 and ESC16 immediately if found at all, both are CA-wide settings rather than single-template issues, a positive finding here has a broader blast radius than almost any template-level misconfiguration and deserves urgent remediation regardless of how rare it turns out to be in practice.
Treat ESC9, ESC10, and ESC14 as part of your standing strong mapping enforcement work, not a separate project, remediation here is largely already covered by the work most organizations have had to do for KB5014754 compliance.
Treat ESC12 as a narrow, environment-specific check, relevant specifically if your HSM deployment uses a token type this technique targets, worth confirming applicability before investing significant hunting effort here.

False-Positive Considerations

Enrollment agent findings (ESC3) are the most common source of false positives, a helpdesk team legitimately issuing smart cards on behalf of users looks identical to abuse at the configuration level, the distinguishing factor is whether agent activity stays within a documented, restricted scope, not whether agent activity exists at all.
Manager-approval workflows can superficially resemble ESC1 exposure, a template with enrollee-supplied subject and a client auth EKU isn’t actually exploitable if manager approval is genuinely enforced and the approval queue is actively reviewed, confirm the approval control is real and functioning, not just configured.
Authorized HSM and CA server administration can resemble ESC12, a documented PKI administrator with legitimate shell access to a CA server isn’t a finding, the risk is specifically about who has that access and whether it’s properly scoped and audited.
Cross-certified or complex multi-CA hierarchies can produce confusing ESC5/ESC7 findings, confirm you understand the actual relationship between CAs before treating an unexpected-looking permission as a genuine finding, some cross-hierarchy delegation is legitimate and intentional.

Remediation Verification

Re-run the exact detection check that originally surfaced the finding, confirming it now returns clean, a fix applied without this step is unconfirmed, not remediated.
Test actual certificate enrollment against the affected template or CA afterward, confirming the fix closed the exploitable path without breaking legitimate enrollment for the accounts that genuinely need it.
Re-scan with whatever broader assessment tooling originally identified the finding, if a security assessment or automated tool surfaced the issue, use the same tooling to confirm remediation, rather than relying solely on a manual spot-check.
Document the remediation and verification together, as part of your change record, this becomes part of the evidentiary trail covered in our continuous risk assessment guidance, useful both for compliance and for confirming the fix hasn’t quietly regressed later.

How Encryption Consulting Can Help

Running detection across all sixteen ESC paths, correctly distinguishing real findings from legitimate delegation, and verifying remediation actually closed each gap is exactly the kind of comprehensive, detail-heavy work that benefits from dedicated expertise rather than a one-time tool scan.

Encryption Consulting’s PKI Services team supports this directly:

Full ESC1-ESC16 detection assessment: running the checks in this playbook against your actual environment, with the context to correctly separate genuine findings from documented, legitimate configurations.
Prioritized remediation planning: sequencing fixes by actual severity and exploitability, not just a flat list of findings.
Remediation verification: confirming each fix actually closed the corresponding detection check without breaking legitimate enrollment workflows.
Integration with strong mapping enforcement, addressing the ESC9/ESC10/ESC14 overlap as part of a unified effort rather than duplicated work.
Ongoing detection as part of your threat hunting program, covered in our threat hunting playbook, so these checks run on a recurring schedule rather than as a one-time assessment.

If you want your environment assessed against all sixteen ESC paths with prioritized, verified remediation, our PKI Services team can run this playbook with you.

Conclusion

Knowing how to fix ESC1 through ESC16 and knowing whether you actually have any of them are two different bodies of work, our hardening playbook covers the first, this detection playbook covers the second. Run the checks grouped by category, prioritize ESC1, ESC3, ESC7, and ESC8 first given their prevalence and low exploitation bar, treat the mapping-related paths as part of your standing strong mapping enforcement work, and never consider a fix complete until the original detection check runs clean again.

Want all sixteen ESC paths checked against your environment, with prioritized and verified remediation? Talk to our PKI Services team. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

Which ESC path should be checked for first? ESC1, ESC3, ESC7, and ESC8 first, since they combine high prevalence in real environments with a low bar for exploitation, and can each be checked with a single, fast configuration query. ESC1 in particular remains the single most commonly found misconfiguration in independent AD CS assessments.

What is the difference between ESC9 and ESC16? ESC9 is a template-level setting, a specific certificate template configured without the security extension that carries strong mapping data. ESC16 is a CA-wide setting that disables the security extension across every certificate the CA issues, a much broader exposure than any single template misconfiguration.

How do you avoid false positives when hunting for ESC3 (enrollment agent abuse)? Cross-reference actual enrollment agent usage against your documented, legitimate list of accounts authorized to hold that role, such as a helpdesk team issuing smart cards. A finding here is only meaningful when agent activity falls outside that documented scope, not simply because agent activity exists at all.

How should remediation of an ESC finding be verified? Re-run the same detection query or configuration check that originally surfaced the finding and confirm it now returns clean, then test actual certificate enrollment against the affected template or CA to confirm the fix didn’t break legitimate functionality. A fix that was applied but never re-verified against the original detection logic isn’t confirmed.

Does hardening a template against ESC1 also protect against ESC15? Not necessarily. ESC15 exploits a validation gap in schema version 1 templates independent of the ENROLLEE_SUPPLIES_SUBJECT and EKU misconfigurations ESC1 depends on, so a template hardened against ESC1 can still be vulnerable to ESC15 if it remains schema version 1 and the CA is unpatched.