How to Harden Active Directory Certificate Services Against ESC Vulnerabilities
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Active Directory Certificate Services misconfigurations are among the most impactful privilege escalation paths in Windows domain environments. The SpecterOps research paper 'Certified Pre-Owned' documented eight vulnerability classes (ESC1-ESC8) that allow low-privilege domain users to obtain certificates for any account, authenticate as domain administrators, and achieve full domain compromise. These are not software vulnerabilities requiring patches: they are misconfigurations that have existed in ADCS deployments for years. Auditing with Certipy takes under five minutes and will identify whether your environment is vulnerable.
Run a Certipy Audit First
Before remediating, enumerate all vulnerabilities in your environment. Certipy is the standard ADCS auditing tool:
# Install Certipy
pip install certipy-ad
# Enumerate certificate templates and CA configurations
# Run from any domain-joined system or with domain credentials
certipy find \
-u 'lowpriv-user@domain.local' \
-p 'Password123' \
-dc-ip 10.0.0.10 \
-stdout
Certipy outputs all certificate templates with their permissions and flags each as [!] Vulnerable with the ESC class if misconfigured. Look for: ESC1: ..., ESC2: ..., ESC3: ... in the output. Also generate a BloodHound-compatible JSON for visualization:
certipy find -u user@domain.local -p pass -dc-ip 10.0.0.10 -bloodhound
Upload the generated .zip to BloodHound to visualize certificate-based privilege escalation paths alongside AD attack paths. The combination shows whether a low-privilege account can reach domain admin via certificates in a single attack path view.
Remediate ESC1: Misconfigured Template SAN
ESC1 is the most exploited ADCS vulnerability. A template is ESC1-vulnerable when: (1) The template allows enrollment by unprivileged domain users or computers; (2) The template does not require manager approval; (3) The template allows the enrollee to supply a Subject Alternative Name (the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is set). An attacker with ESC1 can request a certificate specifying Administrator@domain.local as the SAN, then use that certificate to authenticate as domain admin via PKINIT or pass-the-certificate. Remediation for each affected template in the Certificate Authority console: Certificate Templates > right-click template > Properties > Subject Name tab. If 'Supply in the request' is selected, change it to 'Built from this Active Directory information'. If the template must allow SAN specification for legitimate reasons (BYOD certificates, multi-SAN server certs), enable 'CA Certificate Manager Approval' under the Issuance Requirements tab: this requires manual approval before any certificate is issued from this template, blocking automated ESC1 exploitation.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Remediate ESC2 and ESC3: Any-Purpose Templates
ESC2 templates have the 'Any Purpose' Extended Key Usage (EKU) or no EKU at all, allowing the certificate to be used for any purpose including Kerberos client authentication. ESC3 templates have the 'Certificate Request Agent' EKU, allowing the holder to request certificates on behalf of other users. Both allow privilege escalation by obtaining a certificate usable for authentication as any user. Remediation: Open Certificate Templates console > affected template > Properties > Extensions tab > Application Policies. Remove 'Any Purpose' EKU and replace with the specific EKU the template is intended for (e.g., 'Client Authentication' if the template is for user logons). For ESC3, remove the 'Certificate Request Agent' EKU unless the template is specifically designed for delegated enrollment agents with a restricted set of subject templates. Audit which accounts are configured as Enrollment Agents (CA console > CA Properties > Enrollment Agents): restrict to named service accounts for MDM or smart card enrollment systems only.
Remediate ESC6: CA-Level EDITF Flag
ESC6 is a CA-level misconfiguration that overrides all template settings: the EDITF_ATTRIBUTESUBJECTALTNAME2 flag on the Certificate Authority allows any user to specify a SAN on any certificate request, regardless of whether the template permits it. Check if this flag is set:
certutil -config 'CA-Server\CA-Name' -getreg policy\EditFlags
If EDITF_ATTRIBUTESUBJECTALTNAME2 appears in the output, remove it:
certutil -config 'CA-Server\CA-Name' -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
netsvc CertSvc /restart
This change takes effect immediately after restarting the CertSvc service. Test that legitimate certificate enrollment still works after the change: if any systems were relying on SAN override via this flag (unusual but possible for certain VPN or legacy application certificates), they will need template-level SAN configuration instead. Check the CA's audit log for any certificate requests that used this flag before removal: those certificates should be revoked.
Harden Certificate Template ACLs
Certificate template access control determines who can enroll. Many environments have templates where 'Domain Users' or 'Authenticated Users' have Enroll or AutoEnroll rights, granting every domain account the ability to obtain certificates from that template. Audit template ACLs:
# List all templates and their enrollment permissions
$templates = Get-ADObject -SearchBase 'CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=local' -Filter {objectClass -eq 'pKICertificateTemplate'} -Properties nTSecurityDescriptor
foreach ($template in $templates) {
$acl = $template.nTSecurityDescriptor
$enrollRights = $acl.Access | Where-Object {
$_.ObjectType -eq [Guid]'0e10c968-78fb-11d2-90d4-00c04f79dc55' # Enroll GUID
-and $_.AccessControlType -eq 'Allow'
}
if ($enrollRights.IdentityReference -match 'Domain Users|Authenticated Users') {
Write-Host "REVIEW: $($template.Name) - Enrolled by: $($enrollRights.IdentityReference)"
}
}
For each template where Domain Users have Enroll rights: if the template is needed, restrict to a specific security group (e.g., Workstation-Certificate-Enrollment) and add only the appropriate computers or users. Remove 'Domain Users' and 'Authenticated Users' from Enroll ACEs on all sensitive templates.
Mitigate ESC8: NTLM Relay to HTTP Enrollment
ESC8 exploits the Certificate Authority Web Enrollment (CERTSRV) interface: an IIS-based HTTP endpoint for certificate enrollment that supports NTLM authentication. An attacker who can coerce a machine account into making an HTTP request (via PetitPotam, PrintSpooler, or similar coercion techniques) can relay that authentication to CERTSRV and obtain a certificate for the coerced machine account, then use that certificate to authenticate to the domain. Mitigations: (1) Disable the HTTP enrollment endpoint if not needed: IIS Manager > remove the CertSrv application, or uninstall the Certificate Enrollment Web Service role feature; (2) Enable EPA (Extended Protection for Authentication) on IIS: IIS Manager > CertSrv site > Authentication > Windows Authentication > Advanced Settings > Extended Protection = Required; (3) Require HTTPS (disable HTTP) for CERTSRV: IIS Manager > CertSrv site > SSL Settings > Require SSL; (4) Disable NTLM on the CA's web enrollment: set RequireCertificateChain and configure Kerberos-only authentication. Check if CERTSRV is running: Invoke-WebRequest -Uri http://CA-SERVER/certsrv -UseBasicParsing returning 200 means the endpoint is active.
Enable ADCS Audit Logging
ADCS generates audit events for certificate issuance, revocation, and CA configuration changes. Enable: CA console > CA Properties > Auditing tab. Enable all auditing options, especially 'Issue and manage certificate requests' and 'Change CA security settings'. Events appear in the Security event log on the CA server: Event ID 4886 (certificate requested), 4887 (certificate issued), 4888 (certificate denied), 4896 (certificate revoked), 4899 (CA template changed). Forward CA server Security logs to your SIEM. Alert rules: (1) High-privilege SAN in issued certificate: if Event ID 4887 includes a SAN containing Administrator, Domain Admins members, or krbtgt, investigate immediately; (2) Certificate template modifications (Event ID 4899): any template change should correspond to a change management ticket; (3) Bulk certificate issuance: more than 20 certificates issued from a sensitive template in one hour; (4) Certificate requests immediately followed by Kerberos authentication from the same certificate (correlate 4887 with 4768/4769 Kerberos events using the certificate thumbprint).
The bottom line
ADCS hardening starts with a Certipy audit to identify ESC1-ESC8 vulnerabilities in your specific environment. The most impactful fixes: remove CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT from templates where it's not required (ESC1), remove EDITF_ATTRIBUTESUBJECTALTNAME2 from CA configuration (ESC6), restrict template Enroll ACLs from Domain Users to specific groups, and disable or require HTTPS+EPA on the CERTSRV HTTP enrollment endpoint (ESC8). Enable CA audit logging and alert on certificate issuance to privileged accounts.
Frequently asked questions
How do I check if my ADCS environment is vulnerable to ESC1?
Run 'certipy find -u user@domain -p password -dc-ip x.x.x.x -stdout' from any system with domain credentials. Certipy will flag certificate templates with [!] ESC1 Vulnerable if they have the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag set, allow Domain Users or Authenticated Users to enroll, and do not require manager approval. ESC1 is remediated by changing the template's Subject Name from 'Supply in the request' to 'Build from Active Directory information', or by enabling CA Certificate Manager Approval on the template's Issuance Requirements tab.
What is the EDITF_ATTRIBUTESUBJECTALTNAME2 flag and why is it dangerous?
EDITF_ATTRIBUTESUBJECTALTNAME2 is a Certificate Authority configuration flag that allows any user to specify a Subject Alternative Name on any certificate request, overriding template-level restrictions. With this flag enabled, a low-privilege user who can enroll in any certificate template can request a certificate specifying Administrator@domain as the SAN, obtain a valid certificate for that account, and use it for Kerberos authentication as domain admin. Check with: certutil -config 'CA-Server\CA-Name' -getreg policy\EditFlags. Remove with: certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2.
What are the different ADCS ESC vulnerability types and which are most critical?
The ADCS ESC vulnerabilities (from SpecterOps research) in order of prevalence and criticality: ESC1 (vulnerable certificate templates allowing subject name supply) and ESC2 (any-purpose templates or no EKU templates) enable direct privilege escalation to domain admin. ESC3 (enrollment agent templates) allows impersonating other users. ESC4 (template write permissions) allows modifying template settings to introduce ESC1. ESC6 (EDITF_ATTRIBUTESUBJECTALTNAME2 CA flag) enables ESC1-equivalent impact on all templates. ESC7 (CA officer or manager permissions) allows managing the CA itself. ESC8 (AD CS web enrollment with NTLM relay) enables relay attacks against the certificate enrollment web interface. ESC1 and ESC6 are the highest-priority to remediate: they are common, well-documented, and directly exploitable with widely-available tools like Certipy.
How do I monitor ADCS for certificate abuse in real time?
ADCS monitoring configuration: enable Certificate Services audit logging on the CA server (auditpol /set /subcategory:'Certification Services' /success:enable /failure:enable), which generates Event ID 4886 (certificate requested) and Event ID 4887 (certificate issued) in the CA's security log. Alert on: certificates issued with Subject Alternative Names containing @domain accounts that differ from the requester's account (indicates SAN abuse); certificate requests from unexpected workstations or service accounts; and high-volume certificate issuance from a single account in a short time window. Forward CA security events to your SIEM. Microsoft Sentinel has built-in ADCS analytics rules (search 'ADCS' in the Analytics Templates gallery) that detect common ADCS attack patterns.
How do I secure the ADCS Certificate Authority server itself?
CA server hardening: the CA server is a Tier 0 asset (equivalent to a domain controller) and must be treated accordingly. Physical security: keep it in a locked datacenter; consider an offline root CA (powered off except during subordinate CA certificate renewals). Network: place the issuing CA in a dedicated VLAN with firewall rules limiting access to enrollment web interface (HTTPS 443) and DCOM RPC (135) from authorized systems only. The CA server should not be joined to a domain with broad admin access — use a minimal local admin account for CA operations. Apply CIS Benchmarks for Windows Server to the CA OS. Monitor CA audit logs forwarded to SIEM. Backup the CA database and private key to offline media quarterly and test restoration.
How do I detect Golden Certificate attacks where an attacker has stolen the CA private key?
A Golden Certificate attack occurs when an attacker obtains the CA's private key -- typically by compromising the CA server itself -- and forges arbitrary certificates offline without interacting with the CA. Unlike certificates issued through normal enrollment (which generate Event ID 4887 on the CA), forged certificates leave no issuance record because they are signed without using the live CA service. Detection requires monitoring for certificates presented during Kerberos authentication (PKINIT) that do not appear in the CA's issued certificate database. Extract the CA's issued certificate log via 'certutil -view -out csv > issued_certs.csv' and compare thumbprints against certificates observed in your Kerberos event logs (Event ID 4768/4769 with Certificate Information). Any certificate thumbprint appearing in authentication events that is absent from the CA's issuance log is either forged or from a shadow CA. Prevent CA key theft by protecting the CA server as a Tier 0 asset with privileged access workstations, enforcing HSM-backed key storage (move the CA private key to a hardware security module so it cannot be exported), and enabling Certificate Services audit logging to detect unauthorized access to the CA service and configuration. If a Golden Certificate attack is confirmed, the compromised CA must be revoked and replaced: issue a new CRL revoking all certificates from the compromised CA and deploy a new CA with a fresh key pair.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.