Executive Summary
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.
test environment
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:
- The Enterprise Certificate Authority (CA) grants low-privileged users enrollment rights. The Enterprise CA’s configuration must permit low-privileged users the ability to request certificates.
- Manager approval is disabled. This setting necessitates that a user with CA “manager” permissions review and approve the requested certificate before the certificate is issued.
- No authorized signatures are required. This setting requires any Certificate Signing Request (CSR) to be signed by an existing authorized certificate.
- An overly permissive certificate template security descriptor grants certificate enrollment rights to low-privileged users. Having certificate enrollment rights allows a low-privileged attacker to request and obtain a certificate based on the template.
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.
vulnerability exploitation steps
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
conclusion
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:
- There are various combinations of certificate template settings that can result in domain escalation. For templates that allow SAN specification via the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag AND allow for domain authentication, there are a few approaches for mitigation:
- If the template does not actually require SAN specification, the first option is to remove the “Supply in Request” setting under the “Subject Name” setting for any affected template (this will disable the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag).
- Another option is to enable certificate approvals on the template.
- Also, under “Issuance Requirements”, administrators can configure authorized signatures to enact CSR signing restrictions for the template.
- Contact Avertium to see how we can help you harden your environment against these attacks.
Note: This blog entry was written by Senior Threat Labs Consultant Armend Mala, with editorial contributions by Portia Cole.
APPENDIX II: Disclaimer
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.