In 2021, the SpecterOps team published research documenting a series of attack techniques against Active Directory Certificate Services that they named ESC (Enterprise Subordinate CA abuse) techniques. The research revealed that the PKI infrastructure present in the vast majority of enterprise environments — which most organizations assumed was benign infrastructure — was in fact one of the most exploitable attack surfaces in the entire domain. Four years later, we still find ESC1-vulnerable templates in nearly every AD CS environment we assess.
The number of documented ESC techniques has since grown to 16. This article focuses on the most commonly exploited classes — ESC1 through ESC8 — along with the audit tooling and hardening steps needed to address them. If your organization has never audited AD CS, assume multiple of these findings exist in your environment right now.
What AD CS Is and Why It's a Target
Active Directory Certificate Services is Microsoft's PKI implementation. An enterprise CA issues digital certificates used for authentication (smart cards, computer authentication, user authentication), encryption (EFS, BitLocker), code signing, and TLS. The critical detail from an attacker's perspective is that Kerberos accepts certificates as an authentication method — specifically through PKINIT. This means a certificate issued by a trusted enterprise CA can be used to obtain a Kerberos TGT for any user the certificate claims to represent.
That creates a fundamental attack primitive: if an attacker can obtain a certificate that claims to represent a Domain Administrator, they can authenticate as that administrator — even after the administrator's password has been reset. Certificates are not invalidated by password changes. This is Golden Certificate persistence, and it makes AD CS compromises among the hardest to fully remediate.
CA servers must be treated as Tier 0 assets — equivalent to domain controllers in terms of sensitivity. Most organizations don't do this. They treat the CA server as infrastructure, leave it accessible to lower-tier administrators, and never audit the certificate templates it publishes.
The ESC Vulnerability Classes (ESC1–ESC8)
ESC1: Attacker-Controlled Subject Alternative Name (SAN)
A certificate template vulnerable to ESC1 meets three conditions: it has an authentication EKU (Client Authentication, PKINIT, or similar), it allows low-privileged users to enroll, and it allows the enrollee to specify the Subject Alternative Name. That last condition is the critical one. The SAN is what Kerberos uses to map a certificate to an AD account. If the enrollee can specify the SAN, they can request a certificate that claims to represent any user in the domain — including Domain Admins.
ESC2: Any-Purpose EKU
Templates with the Any Purpose EKU or no EKU at all can be used for any purpose, including client authentication. Combined with low-privileged enrollment rights, these templates are effectively equivalent to ESC1 in impact.
ESC3: Enrollment Agent Abuse
ESC3 exploits templates with the Certificate Request Agent EKU. An enrollment agent can request certificates on behalf of other users. An attacker who obtains an enrollment agent certificate can enroll for certificates as any user in the domain, using the enrollment agent to bypass the identity check on the final certificate request.
ESC4: Template Object Misconfiguration
If an attacker has write access to a certificate template object in AD, they can modify it to introduce ESC1 conditions — enabling SAN specification, removing manager approval requirements, or adding broad enrollment rights. The template object itself becomes the attack surface.
ESC5: PKI Object Misconfiguration
ESC5 extends ESC4 to other PKI objects beyond templates — including the CA object, the Certificate Templates container, the NTAuthCertificates object, and enrollment service objects. Write access to any of these can lead to full CA control and unauthorized certificate issuance.
ESC6: EDITF_ATTRIBUTESUBJECTALTNAME2 Flag
ESC6 is a CA-level configuration — when the EDITF_ATTRIBUTESUBJECTALTNAME2 flag is set on the CA, all templates become ESC1-vulnerable regardless of their individual settings. This flag, intended for specific legacy scenarios, effectively allows any enrollee to specify a SAN on any certificate request.
ESC7: Vulnerable CA Object Permissions
Direct abuse of CA-level permissions — specifically ManageCA and ManageCertificates rights. An attacker with ManageCA can enable the ESC6 flag. An attacker with ManageCertificates can approve pending certificate requests that were previously denied, or issue arbitrary certificates directly.
ESC8: NTLM Relay to AD CS HTTP Enrollment
The Certificate Authority Web Enrollment service — accessible at http://<CA>/certsrv — accepts NTLM authentication over HTTP by default. This makes it a relay target. An attacker who can coerce a privileged account (like a DC machine account using techniques such as PetitPotam, CVE-2021-36942) to authenticate to their controlled server can relay that authentication to the CA web enrollment endpoint and obtain a certificate for the victim account. Relaying DC authentication yields a certificate that can be used to perform DCSync-equivalent operations.
Vulnerable Certificate Template Conditions to Audit
The majority of ESC vulnerabilities trace back to misconfigured templates. The combination of conditions that creates an exploitable template:
- Authentication EKU present (Client Authentication OID: 1.3.6.1.5.5.7.3.2)
- Enrollment rights granted to Domain Users, Authenticated Users, or similarly broad groups
- Manager approval disabled (allows immediate certificate issuance)
- Enrollee supplies subject OR
EDITF_ATTRIBUTESUBJECTALTNAME2set on CA - No authorized signature requirement (no existing certificate required to enroll)
Templates are often created for specific use cases (VPN authentication, Wi-Fi certificates, old smart card deployments) and then left in production long after the original use case is retired. The template remains published, the enrollment rights remain broad, and the vulnerability remains exploitable.
Auditing with Certify and Certipy
Two tools dominate AD CS enumeration: Certify (C#, Windows-native) and Certipy (Python, can run remotely). Both identify vulnerable templates, CA misconfigurations, and ESC conditions. Run whichever fits your environment.
# Certify — enumerate AD CS environment (run on domain-joined Windows host):
# Download from https://github.com/GhostPack/Certify
.\Certify.exe find /vulnerable
# Find vulnerable templates specifically:
.\Certify.exe find /vulnerable /enabled
# Show all templates:
.\Certify.exe find /showAllPermissions
# Request a certificate (ESC1 exploitation — for authorized testing only):
# .\Certify.exe request /ca:CA01.corp.local\corp-CA01-CA /template:VulnerableTemplate /altname:administrator
# Certipy — remote enumeration from Linux (requires domain credentials):
# pip install certipy-ad
certipy find -u username@domain.com -p 'Password' -dc-ip 10.0.0.1
# Find vulnerable templates only:
certipy find -u username@domain.com -p 'Password' -dc-ip 10.0.0.1 -vulnerable -enabled
# Check CA configuration (ESC6 detection):
certipy find -u username@domain.com -p 'Password' -dc-ip 10.0.0.1 -stdout
Both tools output a JSON and text summary of all certificate templates, CA configurations, and identified ESC conditions. A finding of "ESC1" with "Enabled: True" in the output means an authenticated domain user can obtain a Domain Admin certificate right now.
Golden Certificate Persistence
Once an attacker has compromised a CA — whether through ESC7, physical access, or through escalation via the above techniques — they can extract the CA's private key and forge arbitrary certificates. These forged certificates are signed by the trusted enterprise CA and accepted by every domain member. Revoking them is extremely difficult because revocation requires the CA to be operational, and an attacker in this position may already have compromised it.
This persistence mechanism survives:
- All user password resets
- KRBTGT rotation (the forged certificate generates legitimate Kerberos tickets)
- Reimaging of compromised workstations
- Removal of backdoor accounts
The only reliable remediation is revoking the compromised CA's certificate and rebuilding the PKI hierarchy — a significant operational effort. This is why CA servers must be treated as Tier 0 from the outset.
Hardening AD CS: Specific Actions
1. Remove Unnecessary Templates
# Audit published templates in Active Directory:
Get-ADObject -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=com" `
-Filter * -Properties * | Select-Object Name, DisplayName
# Identify templates published by each CA:
certutil -catemplates
# Unpublish a template from a CA (via Certificate Authority MMC):
# CA Properties → Certificate Templates → right-click → Delete
# Or via PowerShell:
Get-CertificationAuthority | Remove-CATemplate -Name "VulnerableTemplateName"
2. Enforce Manager Approval on Authentication Templates
For any template that grants authentication certificates (Client Authentication EKU), enable CA Certificate Manager approval. This requires a human to approve each certificate request, preventing automated ESC1 exploitation.
# Enable manager approval via PowerShell (PSPKI module):
Install-Module -Name PSPKI -Force
Import-Module PSPKI
$template = Get-CertificateTemplate -Name "VulnerableTemplate"
$template | Set-CertificateTemplateAcl -Identity "Domain Users" -AccessType Allow -AccessRights Read
# Set CAManagerApproval flag:
$template.Settings.EnrollmentOptions = [PKI.CertificateTemplates.EnrollmentOptions]::IncludeSymmetricAlgorithms
# Configure via MMC: Certificate Templates Console → Template Properties
# → Issuance Requirements → CA certificate manager approval
3. Disable NTLM on CA Web Enrollment (ESC8 Mitigation)
# Migrate CA web enrollment to HTTPS (prerequisite for EPA):
# Install SSL certificate on the IIS site hosting /certsrv
# Enable Extended Protection for Authentication (EPA) on IIS:
# IIS Manager → Site → Authentication → Windows Authentication
# → Advanced Settings → Extended Protection → Required
# Or disable web enrollment entirely if not needed:
# Server Manager → Remove Role Services → Certification Authority Web Enrollment
4. Audit Certificate Enrollment Events
Enable auditing on the CA to log all certificate request and issuance events. Without this, certificate-based attacks leave almost no trace in default logging.
# Enable CA auditing (run on the CA server):
certutil -setreg CA\AuditFilter 127
# Restart the CA service:
net stop certsvc && net start certsvc
# Key Event IDs to monitor:
# 4886 — Certificate request received
# 4887 — Certificate issued
# 4888 — Certificate request denied
# 4768 — Kerberos TGT request (watch for certificate-based auth: CertIssuerName populated)
5. Restrict Enrollment Rights and Remove Broad Groups
# Review template enrollment permissions:
$template = Get-CertificateTemplate -Name "TemplateName"
$acl = $template | Get-CertificateTemplateAcl
$acl.Access | Where-Object { $_.Rights -match "Enroll" } |
Select-Object Identity, Rights
# Remove Domain Users or Authenticated Users enrollment rights:
$acl.RemoveAccess("Domain Users", "Enroll")
$acl | Set-CertificateTemplateAcl
6. Treat CA Servers as Tier 0
Move your CA servers into the Tier 0 management boundary immediately:
- CA servers should only be administered from Privileged Access Workstations (PAWs)
- Only Tier 0 admin accounts should have local administrator access to CA servers
- CA servers should not be joined to the same OU as member servers — place them with or adjacent to Domain Controllers in your OU structure
- Implement just-in-time access for CA management operations
- Take offline backups of the CA key material and store them securely — the loss of a CA's private key is catastrophic
Where to Start if You've Never Audited AD CS
Run Certipy or Certify with the find -vulnerable -enabled flags. If either tool returns any ESC findings, treat them as critical findings requiring immediate remediation. An ESC1-vulnerable template with Domain Users enrollment rights is a one-command domain compromise from any authenticated account in your environment — no additional privilege is needed.
After remediating template vulnerabilities, audit CA object permissions (ESC7), verify the EDITF_ATTRIBUTESUBJECTALTNAME2 flag is not set (ESC6), and enforce HTTPS with EPA on web enrollment (ESC8). These four steps eliminate the majority of the AD CS attack surface in most enterprise environments.
AD CS is likely the most unaudited component in your environment.
We conduct AD CS security assessments as part of our Active Directory security practice — identifying vulnerable templates, CA misconfigurations, and ESC conditions before they're exploited. If your organization has never audited its PKI, we need to talk.