AD CS ESC Attacks: How Attackers Exploit AD Certificate Services and How to Harden It

Active Directory Certificate Services is Microsoft's enterprise PKI, issuing X.509 certificates for authentication, code signing, email encryption, and TLS. In Active Directory environments, certificates can be used for Kerberos authentication via PKINIT: a client presents a certificate instead of a password, and the domain controller validates it against the issuing CA and issues a Kerberos TGT.

This creates a powerful privilege escalation path: if an attacker can obtain a certificate that the domain controller will accept as authenticating a privileged user (such as the domain administrator), they have effectively obtained domain administrator access without needing the password and without triggering password-based authentication alerts.

Why AD CS misconfigurations persist:

• Certificate templates are configured during PKI setup by server teams, not security teams, and default templates are often overly permissive
• AD CS has no equivalent of 'BloodHound for certificates' in most security stacks: the misconfigurations are invisible without specific tooling
• Certificate templates rarely get security reviewed after initial setup
• Many organizations do not know what certificate templates exist or who can enroll in them

Impact of a successful AD CS escalation:

• Domain Administrator TGT issuance (full domain compromise)
• Persistence via certificate-based authentication that survives password resets (the certificate remains valid until it expires)
• Potential for golden certificate forgery if CA private key is compromised (persists until CA is rebuilt)

The full ESC1-ESC16 taxonomy is documented in the SpecterOps and community research. These five are the most frequently exploited in real intrusions.

Certipy is the primary open source tool for AD CS enumeration and exploitation. Run it in your environment to identify vulnerable templates before attackers do.

Installation:

pip install certipy-ad

Find vulnerable templates (from domain-joined system or with domain credentials):

certipy find -u 'domain_user@domain.com' -p 'password' -dc-ip 10.0.0.1

This generates a JSON and BloodHound-format output listing all certificate templates, their enrollment rights, EKUs, and whether they are vulnerable to each ESC class.

Enumerate from BloodHound: Certipy can output to BloodHound format, which visualizes attack paths through AD CS alongside regular AD attack paths. Import the Certipy output into BloodHound to see combined AD privilege escalation paths that include certificate-based escalation steps.

Check CA flags:

certipy find -u 'domain_user@domain.com' -p 'password' -dc-ip 10.0.0.1 -enabled

The -enabled flag shows only enabled templates. Pay attention to:

• Templates with [+] Vulnerable tags in the output
• Client Authentication or Smart Card Logon in the EKU list
• CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag (SAN supply enabled)
• Domain Users or Authenticated Users in the enrollment rights

What to do with Certipy output: For every template flagged as vulnerable, evaluate: (1) Is this template actually in use? Pull enrollment statistics from the CA logs. (2) Can the enrollment rights be restricted to specific accounts? (3) Can the SAN supply flag be disabled? (4) Does the template need client authentication EKU, or can a more restrictive EKU be used?

Run Certipy quarterly and after any PKI infrastructure changes. Include AD CS audit in your regular red team or internal penetration test scope.

AD CS hardening follows a consistent pattern: restrict who can enroll, restrict what can be included in the certificate request, and monitor for anomalous certificate issuance.

1. Audit and restrict certificate template enrollment rights

For every template that allows Authenticated Users or Domain Users to enroll:

• Replace with specific service accounts or security groups if the template has a legitimate use case
• Disable the template if it has no current use (check CA audit logs for recent issuance)
• Set Manager Approval required for any high-privilege template that cannot be restricted

2. Disable 'Supply in the request' SAN for user enrollment templates

In Certificate Templates MMC (certtmpl.msc): select the template, Properties, Subject Name tab, verify that 'Supply in the request' is NOT selected for templates where Domain Users can enroll. 'Build from this Active Directory information' is the safe setting.

3. Enable EPA on all AD CS web enrollment endpoints

For Certificate Authority Web Enrollment and Certificate Enrollment Web Service:

• Open IIS Manager on the CA server
• For the enrollment application, set Authentication > Windows Authentication > Advanced Settings > Extended Protection: Required
• Restart IIS

4. Remove EDITF_ATTRIBUTESUBJECTALTNAME2 from CA configuration

certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc && net start certsvc

Verify the flag is removed:

certutil -getreg policy\EditFlags

5. Enable StrongCertificateBindingEnforcement on domain controllers

This enforces SID-based certificate-to-account binding, blocking ESC9/ESC10 exploitation:

# Set on all DCs (2 = Full Enforcement Mode)
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Kdc' -Name 'StrongCertificateBindingEnforcement' -Value 2 -Type DWord

Note: Microsoft is enforcing this by default in a phased rollout through 2025-2026 Windows updates. Verify your DCs have the required patches and the registry value is set.

6. Enable AD CS audit logging

# Enable Certificate Services audit
auditpol /set /subcategory:'Certification Services' /success:enable /failure:enable

Audit events to monitor:

• Event 4887: Certificate issued (alert on Domain Admin or high-privilege accounts)
• Event 4768: Kerberos TGT request using certificate (PKINIT) for accounts that should not be using certificate auth
• Event 4886: Certificate request received

Detection complements hardening. Alert on these indicators of AD CS abuse in your SIEM.

Certificate issued to unexpected accounts:

SecurityEvent
| where EventID == 4887
| where TargetUserName contains "Administrator" or TargetUserName contains "DA-" or TargetUserName in (watch_list)
| where RequesterName != expected_service_accounts

PKINIT authentication from accounts that should not use certificate auth:

Kerberos TGT requests using certificate authentication (PKINIT) log with a specific pre-authentication type. Alert on domain admin accounts authenticating via certificate if you have not issued certificates to those accounts:

SecurityEvent
| where EventID == 4768
| where TargetUserName in (privileged_account_list)
| where CertThumbprint != ""
| where CertThumbprint !in (known_admin_certs)

Certipy/Certify tool execution:

Certipy and Certify make LDAP queries to enumerate certificate templates. They generate distinctive query patterns. Monitor for LDAP queries for pKICertificateTemplate objects from non-admin accounts or from unusual source IPs.