ADCS Attack Path Visualization for Defenders

Almost no AD CS misconfiguration is dangerous entirely on its own. A template with enrollee-supplied subjects enabled, a CA object with slightly broader permissions than intended, a web enrollment endpoint without Extended Protection, none of these individually look like a five-alarm finding in isolation. Chained together, they’re how a low-privileged domain account becomes a privileged one without ever touching a password. This is a defender-focused walkthrough of five common chains, visualized, with the specific breakpoint in each one where remediation actually stops the path.

For deeper coverage of the template-level risks specifically, see AD CS Template Hardening: ESC1-ESC16 Defense Playbook and ADCS Certificate Enrollment with SAN Extensions.

TL;DR: Key Takeaways

These are chains, not single points of failure: a low-privileged domain account is usually the starting position, and each path below describes the specific sequence of AD CS or Active Directory conditions that turn that starting position into privileged access.
AD CS objects are Active Directory objects, governed by ordinary ACLs: templates, CA objects, and PKI containers can be attacked through directory permission misconfiguration alone, with no direct access to a CA server required.
Web enrollment introduces a network-layer attack surface most template-focused reviews miss entirely: NTLM relay against HTTP-based enrollment endpoints is a genuinely distinct path from any template misconfiguration.
Every chain has one breakpoint that matters most: identifying it tells you which single control change removes the most risk, rather than treating every step in the chain as equally urgent.
Enrollment agent misuse is frequently under-reviewed relative to direct template misconfiguration, an agent that can request certificates on behalf of any user is a privileged capability that deserves the same scrutiny as direct CA administration rights.

How These Paths Actually Work

Assume the attacker’s starting position is a single, low-privileged, compromised domain account, the realistic starting point in most real incidents. From there, each path below represents a distinct sequence of conditions, some in AD CS configuration, some in Active Directory delegation, some at the network layer, that can carry that low-privileged foothold to a materially more privileged identity.

Path 1: Template Misconfiguration → Identity Impersonation

The chain: a template configured to accept an enrollee-supplied subject, combined with a client authentication EKU, broad Enroll permissions, and no manager approval, lets a requester supply a subject identifying a different, more privileged account, then authenticate as that account using the resulting certificate.
Why it works: the CA trusts the template’s configuration to have already established who’s allowed to request what, if that trust is misplaced, the certificate itself becomes the impersonation vector.
Remediation breakpoint: scope Enroll and Autoenroll permissions to a small, specifically trusted group and require manager approval, this single change breaks the chain regardless of what else is configured on the template.

Path 2: Enrollment Agent Abuse → On-Behalf-Of Impersonation

The chain: an account holding an enrollment agent certificate can request certificates on behalf of other users against templates configured to accept agent-signed requests, if that agent’s scope isn’t restricted to a specific, limited set of target accounts, it can effectively request a certificate as any user, including privileged ones.
Why it’s under-reviewed: enrollment agent rights are often granted for a legitimate, narrow purpose (helpdesk-issued smart cards, for example) and never revisited for scope creep, an agent’s actual reach frequently exceeds its original intended purpose.
Remediation breakpoint: restrict enrollment agent scope explicitly to the specific accounts or groups it’s meant to serve, using the CA’s enrollment agent restrictions rather than relying on broad, unscoped agent trust.

Path 3: CA-Level Permission Misconfiguration → Full Issuance Control

The chain: an account granted “Manage CA” or “Manage Certificates” rights directly on the CA object, rather than scoped template permissions, can approve pending requests, issue certificates against any template the CA hosts, and in some cases modify CA-wide policy settings.
Why it’s a bigger blast radius than a template issue: a template misconfiguration affects one template, a CA-level permission misconfiguration affects every template that CA issues against, all at once.
Remediation breakpoint: apply least-privilege review specifically to CA-level rights, distinct from template-level review, an audit that only checks templates and never checks who holds direct CA management rights has a real, structural blind spot.

Path 4: Web Enrollment + NTLM Relay → Machine Identity Theft

The chain: if a CA’s HTTP-based web enrollment or CES/CEP endpoints don’t enforce Extended Protection for Authentication, an attacker who can coerce a privileged machine account into authenticating to an attacker-controlled listener can relay that authentication to the web enrollment endpoint and obtain a certificate as that machine, entirely without its actual credentials.
Why this path is distinct from the others: it operates at the network authentication layer, not through certificate template or AD permission misconfiguration at all, a hierarchy with perfectly configured templates and CA permissions can still be exposed here.
Remediation breakpoint: enforce Extended Protection for Authentication on every HTTP-based enrollment endpoint, covered in our roundup of 2025-2026 AD CS changes, this single control closes the relay path regardless of what else is happening upstream.

Path 5: Directory (AD) Misconfiguration → Dynamic Privilege Escalation

The chain: because certificate templates, CA objects, and PKI containers (Enrollment Services, AIA, CDP, NTAuthCertificates) are ordinary Active Directory objects, an account with excessive delegation rights, WriteDACL or WriteOwner on a template object, for example, can modify that object’s own security descriptor to grant itself enrollment rights it never had directly.
Why it’s easy to miss: this path requires no CA server access at all, it’s a pure Active Directory delegation problem that a CA-focused review can walk right past if it doesn’t also audit AD object permissions on PKI-related containers specifically.
Remediation breakpoint: audit AD delegation and ACLs on every certificate template, the CA’s own AD object, and PKI containers, specifically looking for WriteDACL, WriteOwner, or GenericAll grants that shouldn’t be there, this is a directory hygiene problem, not a certificate configuration problem, and needs to be reviewed as one.

Remediation Breakpoints: Where to Intervene

Template misconfiguration: scope Enroll/Autoenroll permissions and require manager approval on any enrollee-supplied-subject template.
Enrollment agent abuse: explicitly restrict agent scope to intended target accounts, don’t leave it unscoped.
CA permission misconfiguration: review CA-level Manage CA/Manage Certificates rights as a distinct exercise from template review.
Web enrollment and NTLM relay: enforce Extended Protection for Authentication on every HTTP-based enrollment endpoint.
Directory misconfiguration: audit AD delegation and ACLs on templates, CA objects, and PKI containers specifically, not just general AD hygiene reviews.

How Encryption Consulting Can Help

These five paths rarely get caught by a review that only looks at one layer, a template audit that never checks AD delegation, or a network security review that never touches certificate templates, both leave real gaps.

Encryption Consulting’s PKI Services team supports this directly:

Full attack path assessment: reviewing templates, enrollment agent scope, CA-level permissions, web enrollment configuration, and AD delegation together, as the connected attack surface they actually are.
Remediation prioritization: identifying the specific breakpoint in each finding, so your team fixes the highest-leverage control first, not just the longest list of individually minor issues.
NTLM relay and EPA hardening: assessing and remediating web enrollment endpoints against relay-based attack paths specifically.
AD delegation audits scoped to PKI infrastructure, catching the directory-side misconfigurations a certificate-only review structurally can’t see.
Ongoing attack path monitoring, so newly introduced permissions, templates, or agent scopes are caught before they reopen a path you already closed.

If you want your AD CS environment assessed as a connected attack surface rather than a checklist of isolated settings, our PKI Services team can map it and fix it.

Conclusion

AD CS privilege escalation almost never comes from one dramatic misconfiguration, it comes from small, individually plausible settings chaining together across templates, enrollment agents, CA permissions, web enrollment, and Active Directory delegation. Reviewing any one layer in isolation misses paths that only become visible when you look at how they connect. Know the five patterns, know the specific breakpoint that stops each one, and review all five together, not as separate projects.

Want your AD CS environment mapped as a connected attack surface, not a checklist? Talk to our PKI Services team about a full attack path assessment. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

Why does AD CS create so many privilege escalation paths in Active Directory environments? Because AD CS templates, CA objects, and enrollment infrastructure are ordinary Active Directory objects governed by ACLs, and certificates issued from them can be used for authentication. A misconfigured ACL, an overly permissive template, or a weak web enrollment setting doesn’t just affect certificate issuance, it can translate directly into the ability to authenticate as a different, more privileged identity.

What is the single most effective control against ESC1-style template attacks? Restricting Enroll and Autoenroll permissions on any template that allows enrollee-supplied subjects to a small, specifically trusted group, and requiring CA manager approval on that template. Removing the client authentication EKU from templates that don’t genuinely need it closes the path even further.

How does NTLM relay connect to AD CS privilege escalation? If HTTP-based CA web enrollment endpoints don’t enforce Extended Protection for Authentication, an attacker who can coerce a privileged machine account into authenticating can relay that authentication to the web enrollment endpoint and obtain a certificate as that machine, without ever needing its actual credentials.

Can a low-privileged Active Directory account escalate privileges through AD CS without ever touching a CA server? Yes, if that account has excessive AD delegation rights over a certificate template, the CA’s own AD object, or PKI-related containers, since these are standard AD objects governed by ACLs. Modifying a template’s security descriptor or adding an entry to the NTAuthCertificates container can create an escalation path without direct access to any CA server.

What is a remediation breakpoint in the context of AD CS attack paths? The specific point in a multi-step attack chain where a single control change breaks the entire path, rather than every individual step needing to be addressed separately. Identifying the breakpoint tells defenders exactly which fix removes the greatest risk, rather than needing to address every step in the chain.