Active Directory Certificate Services (ADCS) is a widely used component in Active Directory (AD) environments due to the benefits it provides for organizations. However, its implementation must be carefully audited to avoid introducing vulnerabilities that attackers can exploit to compromise a network and gain elevated privileges, such as those of a Domain Administrator (DA) or higher.
In our experience, ADCS misconfigurations are common and often result in a complete compromise of the network. These misconfigurations are frequently overlooked by penetration testers who focus on traditional testing methods and processes. At Avertium, our goal is to provide the highest value to our customers, so we ensure that every environment is assessed for such misconfigurations in every engagement. Let’s look at how ADCS misconfigurations can be used to elevate privileges and why it’s important for organizations to assess those potential misconfigurations.
While there are several different ways to elevate privileges using ADCS misconfigurations, today we will be focusing on one method “Misconfigured Certificate Templates - ESC1”. In our experience this is the most common misconfiguration encountered. The requirements for this are that a certificate template allows the following:
This article will initiate the assessment from the perspective of an unauthorized threat actor with access to a rogue device and a vulnerable certificate template within the system. The assessment will utilize Responder and NTLM relay attacks to gain access to login credentials by adding a machine account to the domain. Subsequently, we will use this account to enumerate the domain, exploit any misconfigurations in ADCS, and elevate permissions to that of a DA.
Step 1 - We start by modifying the Responder.conf file and switching the HTTP and SMB servers to off as shown in figure 1 below:
Figure 1: Modifying Responder.conf File
Step 2 - We start Responder using the command shown in Figure 2.
Figure 2: Starting Responder
Step 3 - When the network experiences high traffic, which is often the case, the captured traffic will begin to come in as seen in Figure 3.
Figure 3: Poisoned Traffic via Responder
Step 4 - Using Impacket's ntlmrelayx.py, we relay the captured credentials via the ldaps protocol to a domain controller previously identified and attempt to add a machine account to the domain (refer to Figure 4). This method is selected because, by default, domain networks permit any user to add a machine to the domain, which often yields valid credentials.
Figure 4: Using NTLM Relay to Obtain Valid Credentials
As you can see in figure 4, the attack worked, and a machine account was added to the domain.
Step 5 - Next, we used the obtained credentials to run bloodhound as well as enumerate the ADCS environment using a tool named Certipy. The tool was written by Security Researcher Olyver Lyak and streamlines the process of enumerating and exploiting ADCS configurations. Figure 5 shows the command used to enumerate the domain using bloodhound.py.
Figure 5: Using Bloodhound to Enumerate the Environment
Step 6 - Figure 6 displays the enumeration of the ADCS environment to identify vulnerable ADCS templates and export the outcomes in a format that can be imported into BloodHound. [1]Please note that the version of BloodHound utilized in this exercise is a customized edition released by Olyver Lyak, which integrates seamlessly with Certipy.
Figure 6: Enumerating the ADCS Using Certipy
[1] Download Olyver Lyak’s version of BloodHound - https://github.com/ly4k/BloodHound
Step 7 - In figure 7, you can see that, with the use of BloodHound, we queried for vulnerable templates.
Figure 7: Finding Vulnerable CA Templates
Step 8 - Next, BloodHound is employed to identify the members of the Domain Administrators group, with the aim of selecting a suitable target for privilege escalation (refer to Figure 8).
Figure 8: Members of Domain Admins Group
Step 9 - For the purpose of this demonstration, we opted for the Administrator account. Subsequently, utilizing Certipy with the "req" parameter, we requested a certificate with the previously created credentials, while specifying the SAN of the Administrator account, as shown in Figure 9.
Figure 9: Requesting a Certificate for Administrator Account
Step 10 - As demonstrated, the certificate is saved to the local directory. Next, Certipy's "auth" parameter is utilized to retrieve the Kerberos Service Ticket (TGT) and NTLM hash of the Administrator account, as displayed in Figure 10.
Figure 10: Obtaining a TGT Ticket and NTLM Hash for Administrator Account
Step 11 - Next, the saved administrator.ccache file is exported to KRB5CCNAME as seen in Figure 11.
Figure 11: Exporting the ".cache" File
Step 12 - Figure 12 shows that with this completed, we can now use the wmiexec to logon to the domain controller as administrator and add an account “Avertium” to the domain, before adding it to the Domain Admins group.
Figure 12: Domain Admin Access
Upon attaining Domain Administrator (DA) access, achieving the other objectives of the engagement becomes a much easier task. Once access is obtained on the network, threat actors have access to everything within the organization. Properly configuring ADCS and assessing the environment for potential misconfigurations could prevent a threat actor from elevating privileges to DA.
Fortunately, there are recommendations that, if implemented correctly, can help mitigate the risks associated with this kind of vulnerability:
Note: This blog entry was written by Senior Threat Labs Consultant Armend Mala, with editorial contributions by Portia Cole.
This document and its contents do not constitute, and are not a substitute for, legal advice. The outcome of a Security Risk Assessment should be utilized to ensure that diligent measures are taken to lower the risk of potential weaknesses be exploited to compromise data.
Although the Services and this report may provide data that Client can use in its compliance efforts, Client (not Avertium) is ultimately responsible for assessing and meeting Client's own compliance responsibilities. This report does not constitute a guarantee or assurance of Client's compliance with any law, regulation or standard.
COPYRIGHT: Copyright © Avertium, LLC and/or Avertium Tennessee, Inc. | All rights reserved.