ADCS Attack Paths Explained in Practice

ADCS Attack Paths Explained: What Counts as a Real Path?

For teams searching for ADCS attack paths explained in operational terms, start with the chain rather than the label. An AD CS attack path is not just a weak certificate template. It is the combination of issuance rules, enrollment rights, control over template or CA configuration, reachable enrollment endpoints, and certificate-to-account authentication behavior that lets a low-privileged identity become a more privileged one or reopen that path later.

That is why AD CS review cannot stop at a single screenshot from Certificate Templates. You need to answer five questions together:

Which enterprise CAs exist in the forest?
Which templates are published and usable for authentication?
Who can enroll, auto-enroll, or modify those templates?
Which CA-wide settings widen subject or SAN abuse?
Which enrollment endpoints and authentication paths make those certificates usable in production?

In SpecterOps' Certified Pre-Owned research, the ESC labels are names for recurring abuse patterns. In a real review, they are attack paths because they connect PKI configuration to identity escalation.

Why ADCS Attack Paths Still Matter in Active Directory

Microsoft documents AD CS as the Windows Server role that issues and manages PKI certificates for authentication, encryption, smart card sign-in, TLS, VPN, and other security workflows. That same role becomes a high-impact identity surface when certificate issuance and certificate-based authentication rules drift apart from least privilege.

AD CS paths matter because they do not all look like classic admin abuse. Some paths let an attacker request a certificate that authenticates as another identity. Some let the attacker change the control plane first, then create the dangerous template conditions afterward. Some rely on relaying authentication to enrollment endpoints instead of directly modifying template settings. And some become part of broader escalation chains with Active Directory attack paths or ACL abuse and DCSync rather than acting alone.

A second reason they matter is operational blind spots. Security teams often monitor password resets, group changes, and Kerberos delegation more closely than certificate issuance. If CA auditing, template change visibility, or certificate-authentication baselines are weak, a vulnerable PKI path can stay live long after other privilege escalation routes have been reviewed.

Minimum evidence pack

Evidence	Why it matters
Enterprise CA inventory	Confirms which CAs and role services actually exist in the forest
Published templates	A template that is not published cannot be requested from that CA
Enrollment and auto-enrollment rights	Shows whether low-privileged identities can obtain certificates
Template ACLs	Determines who can tamper with the template itself
Subject and SAN controls	Identifies whether requesters can supply dangerous identity values
CA edit flags	Reveals CA-wide settings such as `EDITF_ATTRIBUTESUBJECTALTNAME2`
Web enrollment, HTTPS, and EPA state	Determines whether relayable enrollment endpoints remain exposed
CA issuance and authentication telemetry	Proves whether monitoring can actually see requests, issuance, and certificate-based authentication

Template Abuse Paths: ESC1 and Published Authentication Templates

ESC1 is the clearest example of a template abuse path. Microsoft Defender for Identity describes the dangerous condition this way: if a certificate template has Supply in the request turned on, and the certificate is also valid for authentication, attackers might be able to enroll a certificate valid for arbitrary users.

In practical terms, an ESC1 path is usually built from these conditions:

the template is published on a CA
low-privileged identities can enroll in it
the template allows requester-supplied subject or SAN values
the certificate can be used for authentication, for example with a client authentication-capable EKU
no stronger control, such as manager approval or required authorized signatures, prevents issuance

What matters here is not just the flag itself. A template can have risky naming behavior and still not be a live attack path if it is unpublished or restricted to tightly governed enrollment populations. Conversely, a published authentication template with weak scope and weak issuance controls is already an identity path, not merely a template hygiene issue.

This is also why the review should talk about published authentication templates, not just "vulnerable templates" in the abstract. Publishing determines exploitability.

Control-Plane Paths: ESC4 and ESC6

ESC4 and ESC6 are control-plane paths. They are dangerous because they let an attacker create or widen exploitable issuance behavior even if the template did not begin in an obviously unsafe state.

With ESC4, the problem is the template object's ACL. Certificate templates are Active Directory objects, and their ACLs control not only enrollment but also who can edit the object. Microsoft Defender for Identity explicitly calls out the risk of unprivileged groups receiving permissions that allow template setting changes, such as Full Control or WriteDACL. In other words, the attacker does not need the template to start as ESC1; they can tamper with the template until it becomes one.

With ESC6, the problem shifts from the template to the CA. If the CA has the EDITF_ATTRIBUTESUBJECTALTNAME2 flag enabled, Microsoft Defender for Identity notes that users can specify SAN settings in certificate requests, and that this affects templates whether or not they individually enable Supply in the request. That does not mean every template becomes a direct Domain Admin button. It means the CA has widened the subject-control surface, so any published authentication-relevant template in the wrong scope becomes much more dangerous.

These two paths belong in the same review as broader permission abuse and replication rights, because they are fundamentally governance problems on the PKI control plane.

Relay Paths: ESC8 and Enrollment Endpoints

ESC8 is different from template abuse. The path depends on relayable enrollment endpoints rather than only on template flags.

Microsoft documents AD CS web enrollment and certificate enrollment web services as HTTP-based enrollment surfaces. Microsoft Support KB5005413 explains why this matters: if attackers can relay NTLM authentication to vulnerable AD CS enrollment endpoints, they may obtain certificates that can then be used for further compromise. Microsoft Defender for Identity's ESC8 assessment narrows the condition further by calling out IIS endpoints that allow NTLM authentication without enforced HTTPS or without Extended Protection for Authentication (EPA).

That makes ESC8 an endpoint and protocol problem as much as a PKI problem. The review should therefore include:

whether CA Web Enrollment or related enrollment web services are installed
whether they remain reachable over HTTP
whether EPA is enforced
whether NTLM is still accepted where Microsoft recommends disabling or constraining it

This path also belongs next to broader relay hardening work such as NTLM relay attacks in AD and SMB signing disabled, because the certificate endpoint is only one step in the chain.

Where Weak Certificate Mapping Fits

Weak certificate mapping matters, but it is not the same problem as ESC1, ESC4, ESC6, or ESC8.

The core AD CS paths above focus on how a certificate gets issued or how the issuance path is reopened. KB5014754 covers a different layer: how Windows domain controllers evaluate certificate-based authentication mappings and move toward stronger binding requirements. That is why weak mapping should be treated as an adjacent control and linked to the dedicated article Weak Certificate Mapping in AD CS: Why Strong Binding Matters, not folded into this post as if it were already represented by the four ADCS vuln tags on the article.

In practice, this means a strong AD CS review has to distinguish two questions:

can an attacker obtain a dangerous certificate?
if a dangerous certificate exists, how will domain controllers bind it to an account?

They are related, but they are not the same attack path.

Detection

Detection has to correlate issuance, control-plane changes, and authentication telemetry. No single event proves AD CS abuse by itself.

CA issuance and CA configuration telemetry

Microsoft's advanced audit policy and PKI monitoring guidance both make CA auditing central. At minimum, security teams should know whether the CA is producing issuance and request telemetry such as:

4886 for certificate requests
4887 for certificate issuance
4882 for Certificate Services security permission changes
4890, 4891, or 4892 for management and configuration changes in Certificate Services

These events are useful because they show that a request or issuance happened, or that the CA configuration changed. They do not prove by themselves that the request was malicious. You still need to correlate the requester, the template, the intended subject, and the expected business flow.

Active Directory object change telemetry

Templates are AD objects, which means 5136 matters when auditing is configured and the relevant SACLs exist. Microsoft documents that 5136 is generated when an AD object is modified. In an AD CS review, that matters for template ACL changes, template publication changes, and other object-level configuration edits that convert a normal template into an attack path.

Authentication telemetry

On the domain controller side, 4768 records TGT issuance activity. That makes it useful for correlating certificate issuance with later authentication patterns, especially for accounts or machines that do not normally use certificate-based logon. But 4768 is not an AD CS detector. It is one correlation source among several, and it becomes much more useful when paired with CA issuance events and a baseline of expected certificate-authentication behavior.

Configuration and exposure evidence

Not all meaningful detection is event-driven. Some of the most important AD CS findings are state findings:

a published authentication template remains enrollable by low-privilege users
a template ACL still grants dangerous write rights
EDITF_ATTRIBUTESUBJECTALTNAME2 is still enabled
an enrollment endpoint still accepts relayable NTLM conditions over HTTP or without EPA

That is one reason Active Directory monitoring event IDs that matter should be paired with a repeatable configuration review rather than treated as the whole answer.

Remediation Priorities

The right remediation order is to break live issuance paths first, then harden the control plane, then close endpoint gaps, then validate adjacent mapping posture.

1. Break live issuance paths

Start by unpublishing or restricting the templates that currently create the path. Microsoft Defender for Identity explicitly recommends removing a dangerous template from being published when it should not be requestable. If a template must remain available, reduce enrollment scope before doing cosmetic cleanup.

Then remove or limit requester-supplied subject and SAN behavior where it is not strictly required. For templates that must support special workflows, apply stronger issuance controls such as approval or authorized signatures instead of leaving broad low-privilege enrollment in place.

2. Remove control-plane abuse conditions

For ESC4, harden template ACLs so unprivileged groups cannot tamper with permissions or template settings. For ESC6, remove EDITF_ATTRIBUTESUBJECTALTNAME2 unless there is a justified and reviewed operational dependency.

Also review who can manage CA settings, publish templates, or delegate PKI administration. A template fix is not durable if another operator or delegated group can silently restore the dangerous state later.

3. Close relayable enrollment surfaces

For ESC8, follow the Microsoft mitigations in KB5005413:

disable unused enrollment web roles where possible
require HTTPS
enable EPA
reduce or disable NTLM exposure on IIS enrollment endpoints where Microsoft recommends it

If web enrollment is not operationally required, removing it is often a better risk reduction than trying to preserve it indefinitely with partial controls.

4. Treat weak mapping as adjacent hardening

Do not confuse template hardening with mapping hardening. If the environment still depends on weak certificate mappings, track KB5014754 as a separate remediation stream and validate those DC-side changes explicitly.

Validation After Remediation

Do not sign off on AD CS remediation until you can show that the attack path is actually broken from the same perspective you use for security review.

Validation should include:

proof that vulnerable templates are no longer published or are no longer enrollable by low-privileged identities
proof that dangerous template ACL entries are gone
proof that the CA no longer exposes EDITF_ATTRIBUTESUBJECTALTNAME2
proof that enrollment endpoints no longer remain exposed over HTTP or without EPA where the path previously depended on those conditions
proof that CA audit logging now captures certificate requests and issuance
proof that AD-side monitoring can see template object changes where those changes matter
proof that previously issued risky certificates were reviewed and revoked where appropriate

This is where a broader audit Active Directory security workflow becomes useful. AD CS validation is not only about one template flag. It is about proving the issuance path, the control plane, and the monitoring path have all changed in production.

How EtcSec Maps ADCS Attack Paths

EtcSec should stay narrow here: it measures the conditions that create the path.

For the core attack paths, that means mapping findings such as:

ESC1_VULNERABLE_TEMPLATE
ESC4_VULNERABLE_TEMPLATE_ACL
ESC6_EDITF_FLAG
ESC8_HTTP_ENROLLMENT

The same review can also surface adjacent findings that explain why the path exists or how it chains further:

ADCS_WEAK_PERMISSIONS
PATH_CERTIFICATE_ESC

The important point is not to promise magical attack detection. The value is in repeatedly measuring template scope, template ACLs, CA flags, and enrollment endpoint exposure so that PKI drift is visible before it becomes an escalation chain.

ADCS Attack Paths Explained: How Certificate Misconfigurations Become Active Directory Escalation Paths