Understanding Active Directory Certificate Services: A Focus on ESC1 and ESC8

Active Directory Certificate Services (AD CS) can be a highly attractive target for attackers, particularly through exploitation techniques known as ESC1 and ESC8. In this case, “ESC” stands for “escalation”; however, throughout this blog post, we will stick with ESC1 and ESC8 for brevity. These are the most common AD CS misconfigurations we see in engagements that often provide a quick win and allow escalation to domain administrator privileges. For a deep dive into AD CS in general and other specific AD CS misconfigurations, check out the original whitepaper Certified_Pre-Owned from SpecterOps, released in 2021. It’s great research, and the AD CS misconfigurations outlined in that paper are still commonly found at the time of this writing.

What is AD CS?

Active Directory Certificate Services (AD CS) is a Microsoft server role that provides public key infrastructure (PKI) functionality, enabling organizations to issue and manage digital certificates. Digital certificates can be used for file encryption and digital signatures, but also for authentication of user or computer accounts within an AD environment. In most cases, AD CS enhances security by binding the identity of a person, computer, or service to a corresponding private key. Additionally, AD CS tightly integrates with AD Domain Services, which simplifies the management and revocation of digital certificates. Administrators can also create custom certificate templates in which they can define specific attributes and policies for the certificate. If certificate templates or the CA server itself are misconfigured, an attacker may be able to abuse those misconfigurations to request and obtain a certificate on behalf of an arbitrary user. That certificate could then be used to access resources in the impersonated user’s context, and the attacker would be able to perform any action which the victim has permissions for.

Domain Architecture

The following table reflects the relevant domain architecture in use to make the specific examples in this post clearer. I’m using the fantastic Game of Active Directory in my home lab to illustrate these concepts.

IP	Hostname	Role
10.2.10.99	TS-Kali	Attacker’s Kali machine
10.2.10.12	MEEREEN.ESSOS.LOCAL	Domain Controller
10.2.10.23	BRAAVOS.ESSOS.LOCAL	AD CS Certificate Authority

 

It is worth noting that for the purpose of this blog post, we will assume a penetration test scenario where we are not overly concerned with being detected as opposed to a “Red Team” scenario where we would be trying to evade Antivirus, Endpoint Detection and Response (EDR), etc. Evasion techniques are outside the scope of this article, so none of the enumeration or exploitation methods outlined here will address evasion, code obfuscation, or anything else that would likely be required if stealth is a primary consideration for the engagement.

ESC1: Misconfigured Certificate Templates

ESC1 refers to the exploitation of misconfigured certificate templates. Specifically, when all of the following configurations exist, an attacker can abuse this to escalate privileges in the domain:

• Overly Permissive Enrollment Rights. Members of an unprivileged group such as “Authenticated Users” can request certificates using the affected template.
• Client Authentication. The certificate can be used for authentication enabling access to resources in the network.
• Enrollee Provides Subject: The attacker can specify a Subject Alternate Name (SAN) in the Certificate Signing Request, making it possible to use the certificate to authenticate as an arbitrary user.
• Manager Approval is Not Required. There is no secondary approval required for certificate enrollment using the affected template.

If we have valid credentials for a domain user, we can use certipy from the attacking Kali machine to query the domain controller to enumerate vulnerable templates. First, certipy can be installed using pipx on the attacker’s Kali machine by running:

After certipy is installed, we can enumerate vulnerable templates as shown below:

Since all members of the “Domain Users” can enroll and supply the subject when requesting the certificate, it is possible to abuse this misconfiguration to request a certificate on behalf of any other user, including a domain administrator. From BloodHound, it is evident that “daenerys.targaryen” is a member of the “Domain Admins” group in the ESSOS.LOCAL domain. For this demonstration, we will request a certificate on her behalf.

Now that we have a target, we can request a certificate on behalf of “daenerys.targaryen” using certipy.

Perfect! Now that we have a pfx file containing the certificate and private key, we can again use certipy to authenticate to the domain controller and retrieve the NTLM hash for Daenerys. Although the specific method used for obtaining the NTLM hash is outside the scope of this post, additional details on the “UnPAC the Hash” technique can be found here.

Now, despite having recovered the NT hash for Daenerys, you may want to consider authenticating with the TGT to blend in with normal traffic better and make it more difficult for the defenders to identify an anomalous login. To use the TGT, we first need to export the credential cache (ccache) file that was saved in the previous step (i.e., daenerys.targaryen.ccache) using the following command:

Now, with the credential cache exported to the KRB5CCNAME environment variable, we can use Kerberos authentication with NetExec, as shown below:

With administrative access, we can dump the NTDS.DIT, which is the primary Active Directory database file containing credentials for all domain users. The following snippet shows extracting the NTLM hash for the krbtgt user for simplicity but dumping the entire NTDS.DIT would give us access to any credentials stored in the database.

Since all Kerberos Ticket Granting Tickets (TGT) are encrypted with the key of the krbtgt account, if an attacker obtains the krbtgt secret, they can forge a ticket impersonating a privileged user. This attack is commonly referred to as a “Golden Ticket” and can provide the attacker persistence in the domain since the ticket will remain valid until the krbtgt secret is changed twice. This makes the krbtgt account a very attractive target for an attacker.

If operational security (OPSEC) is crucial for the current engagement, CAs and templates can be enumerated using LDAP queries, which may be a bit quieter than using a well-signatured tool like certipy. The following snippet shows an example of enumerating PKI services from the attacker’s Kali machine using the ldapsearch tool:

 

Description	OID
PKINIT Client Authentication	1.3.6.1.5.2.3.4
Smart Card Logon	1.3.6.1.4.1.311.20.2.2
Any Purpose	2.5.29.37.0

It should be noted that this certificate will remain valid, and the attacker will be able to use it to access resources in the network even if the victim user’s password is changed. To mitigate ESC1, organizations should:

1. 1. Review and Audit Certificate Templates: Regularly check templates for misconfigurations. Use a tool like certipy (Linux) or certify (Windows) to periodically audit AD CS templates. Specifically, review templates for the ENROLLEE_SUPPLIES_SUBJECT flag. This allows the requestor to specify the alternate SAN. This flag is controlled by the Supply in the request configuration option.
   2. Restrict certificate requests for arbitrary users: Apply at least one of the following measures recommended by Microsoft:
      1. Turn off the Supply in the request configuration.
      2. Review all templates to determine if it is necessary to include an Extended Key Usage (EKU) that enables user authentication; remove any EKUs that allow authentication that are not necessary for business functions.
      3. Remove overly permissive enrollment rights such as Authenticated Users or Domain Computers.
      4. Turn on the CA certificate Manager Approval requirement
      5. If the vulnerable certificate is not needed, remove it from being published by any CA.

The template configuration can be accessed in the Windows Server Manager Certification Authority GUI (certsrv). Right-click on “Certificate Templates” and select “manage”.

Then, in the Certificate Templates Console, find the vulnerable template, right-click, and select “Properties”.

To prevent users from being able to request a certificate on behalf of an arbitrary user, ensure the “Supply in the request” radio button is unselected. Manager approval can be configured on the “Issuance Requirements” tab by selecting “CA certificate manager approval” is checked.

ESC8: Abusing AD CS Certificate Enrollment Endpoints

ESC8 involves exploiting insecure AD CS enrollment IIS endpoints used for certificate enrollment. AD CS supports enrollment via HTTP using the Certificate Enrollment Service (CES) or the Web Enrollment interface (Certsrv). If the IIS endpoint allows NTLM authentication but does not enforce protocol signing (HTTPS) or Extended Protection for Authentication (EPA), these endpoints can be vulnerable to NTLM relay attacks and can allow an attacker to obtain a certificate on behalf of a machine account if the attacker is able to induce a target computer or user to send a network authentication request to the attacker-controlled machine. The general flow of this attack is as follows:

1. 1. The attacker sets up a relay to the certificate enrollment endpoint from the attacker-controlled Kali machine.
   2. The attacker coerces network authentication from a vulnerable DC to the attacker-controlled Kali machine where the relay is waiting to forward requests to the certificate enrollment endpoint.
   3. The AD CS CA server responds to the relayed network authentication request with a certificate which can then be used to request a TGT for the affected DC machine account.
   4. Using the TGT of the DC machine account, the attacker performs a DCSync attack to recover additional domain credentials.

Enumerating the AD CS with certipy again, we find that the CA server is vulnerable to ESC8, which abuses an NTLM relay to the CA web enrollment endpoint.

This attack requires two terminals to exploit. In the first terminal, we need to start up an application like certipy or ntlmrelayx.py from the Impacket suite to relay authentication requests to the certificate authority as follows:

Then, in the second terminal, we need to coerce an authentication request from the DC. Several tools can accomplish this, but for this demonstration, we will use the Coercer tool. Coercer leverages multiple methods to attempt to induce a target machine to send a network authentication request to an attacker-controlled host. This network authentication can then be intercepted with a tool like Responder for offline password attacks with something like “John the Ripper” or “Hashcat” or relayed using a tool like certipy or ntlmrelayx.py. As mentioned, we will be using certipy to relay the network authentication request from the DC to the CA to obtain a certificate on behalf of the DC machine account.

It’s worth noting here that if the DC is not sufficiently patched against the PetitPotam vulnerability, this step can be performed without valid domain credentials.

Back in the first terminal where we have the relay running, we can see that we’ve obtained a certificate for the MEEREEN.ESSOS.LOCAL machine account, MEEREEN$, and have the certificate and private key stored in the “meereen.pfx” file.

Now that we have a pfx file for the DC machine account, we can authenticate to the DC and obtain the NTLM hash. Note the “$” at the end of the “ESSOS\\MEEREEN$” in the output above; the “$” indicates that we’re working with a machine account.

If this causes an error, try specifying the IP address of the target DC using the -dc-ip option.

With access to credentials for a DC machine account, we can perform a DCSync to obtain credentials for all domain objects stored in the NTDS.dit. This is possible due to the innate permissions DCs have relating to replication. In short, if multiple DCs are in use in an organization, each DC must be aware of any changes made in the environment. These changes are synchronized between all the DCs via the Microsoft Directory Replication Service Remote Protocol (MS-DRSR). The DCSync attack mimics a DC requesting replication via the MS-DRSR protocol; however, it should be noted that the DCSync attack works regardless of the number of DCs in use. If successful, the replication data will include password hashes that can be used in other attacks via pass-the-hash or taken offline to be cracked.

In this case, since we were able to obtain the machine account credentials of the MEEREEN.ESSOS.LOCAL DC (MEEREEN$), we can use secretsdump.py to extract the credentials of the “krbtgt” account, as shown below:

To mitigate ESC8, organizations should:
ol>

• Disable web enrollment if it is not necessary. If AD CS certificate enrollment IIS endpoints are not needed for business purposes, they should be disabled.
• Enforce HTTPS: Ensure all certificate enrollment endpoints use HTTPS to secure communications.
• Enable Extended Protection for Authentication (EPA): This helps prevent relay attacks by binding the authentication process to the secure channel.
• Disable NTLM Authentication. If possible, disable NTLM authentication on DCs and AD CS servers using Group Policy.

To enable EPA on the web enrollment endpoint, open the IIS Manager application and select “Authentication” for the “CertSrv” site, as shown below:

From within the Authentication menu, right-click on “Windows Authentication” and select “Advanced Settings”. Then, under “Extended Protection” select “Required” as shown below:

After configuring EPA on the enrollment endpoint, update the web.config file at <%windir%>\systemdata\CES\<CA Name>_CES_Kerberos\web.config. An example from Microsoft is below:

To enable HTTPS, select the “SSL Settings” for the CertSrv site, and check “Require SSL”.

Requiring HTTPS on the web enrollment endpoint

Conclusion

AD CS is a powerful tool for managing digital certificates, but it comes with risks that need to be carefully managed. By understanding and mitigating vulnerabilities like ESC1 and ESC8, organizations can better protect their AD environments from potential attacks. Regular audits, proper configuration, and adherence to security best practices are key to maintaining a secure infrastructure.

Beyond just looking for these specific vulnerabilities in an environment, organizations should consider adopting the following best practice recommendations to further secure their network/domain:

• Restrict certificate templates to only necessary permissions and limit the certificates all domain users can request. To the extent possible, limit blanket enrollment rights for unprivileged groups, such as “Authenticated Users”.
• Periodically check the AD CS server and certificate templates for misconfigurations. For example:
  • Are web enrollment endpoints in use? Make sure HTTPS is enforced and implement EPA for the endpoints in use.
  • Are there certificate templates that can be used for authentication? Do they have the ENROLLEE_PROVIDES_SUBJECT flag set? Disable this if it’s not necessary.
  • Adhere to the principle of least privilege as much as possible.
• Monitor issued certificates and revoke certificates that are no longer needed.
• Refer to Microsoft’s recommendations for mitigating specific AD CS misconfigurations. This example addresses ESC2 relating to an overly permissive certificate template with a privileged EKU.

References

• Identify insecure AD CS certificate enrollment IIS endpoints (ESC8) – Microsoft Defender for Identity | Microsoft Learn
• Certified_Pre-Owned.pdf (specterops.io)
• Prevent users to request a certificate valid for arbitrary users based on the certificate template (ESC1) – Microsoft Defender for Identity | Microsoft Learn
• KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS) – Microsoft Support