Huy Kha | Senior Identity & Security Architect

Privilege escalation in Active Directory (AD) allows cyber attackers to increase access within the environment and potentially compromise entire networks—undetected. Enterprise CA Security Configuration (ESC1) is an attack method that has grown in popularity because it enables bad actors to gain privileged access through a tool that’s actually designed to make administrator’s lives easier: certificate templates.

What is an ESC1 attack?

Certificate templates help simplify administration of Active Directory Certificate Services (AD CS) certification authorities (CAs) by providing a preconfigured set of rules and settings that are applied to incoming certificate requests. They provide a way for administrators to streamline certificate management—and ensure consistency in applying certificate policies.

However, certificate templates can be vulnerable to misuse.

In an ESC1 attack, an attacker exploits a misconfigured Enterprise CA certificate template in AD CS to request a certificate for a high-privileged account—for example, Domain Admin. Then, they use that certificate to act as that account, gaining unauthorized control.

How does an ESC1 attack work?

To perform an ESC1 attack, a malicious actor needs AD CS to be running, and they must have permission to enroll in a misconfigured certificate template.

The attacker looks for a vulnerable certificate template configuration (Figure 1) with:

  • Supply in Request setting checked, which allows the attacker to request a certificate for any account
  • Extended Key Usage (EKU) extensions such as Client Authentication, PKINIT Client Authentication, Smart Card Logon, Any Purpose—or no EKU (such as SubCA)
Figure 1. Vulnerable certificate template, allowing an attacker to impersonate every user within the domain

When these conditions exist, the attacker can request a certificate for any account in the domain (Figure 2) and then use it to impersonate that account.

Figure 2. Request for a certificate on behalf of any specified account

How can you defend against an ESC1 attack?

If your organization has certificate templates that allow Subject Alternative Names (SANs) and support Client Authentication EKUs, they could be vulnerable to an ESC1 attack.

To protect against this, follow these practical steps:

  • Check certificate templates: Review all your certificate templates and identify those that allow SANs and have EKU extensions such as:
    • Client Authentication (1.3.6.1.5.5.7.3.2)
    • PKINIT Client Authentication (1.3.6.1.5.2.3.4)
    • Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2)
    • Any Purpose (OID 2.5.29.37.0)
    • Or templates with no EKU (such as SubCA)
  • Limit who can enroll: Make sure that only the users or groups who truly need access can enroll for certificates with these templates. Tightening access helps minimize who can exploit templates.
  • Require CA manager approval: For any certificate templates that allow SAN and support Client Authentication, turn on CA certificate manager approval. This means someone has to approve each request before a certificate is issued.
  • Disable unused templates: If certain certificate templates aren’t being used, disable them or tweak them to remove risky configurations. For example, turn off the Supply in Request setting so users can’t request certificates for other accounts.

Defenders can use the free Purple Knight AD security assessment tool to identify insecure certificate templates and take action to remediate them (Figure 3).

Figure 3. Purple Knight tool showing vulnerable certificate templates

Defenders can also use Invoke-Locksmith1 (Figure 4) to quickly identify insecure certificate templates and take action to fix them. The Locksmith PowerShell script includes an option for auto-remediation, but it’s important to thoroughly test and review everything before implementing any remediation steps.

A great feature of Invoke-Locksmith is that it also includes Invoke-RevertLocksmith, which allows an organization to easily revert any changes if they notice any negative impact. This provides an extra layer of safety when adjusting certificate templates.

Figure 4. Remediating vulnerable certificate templates with Invoke-Locksmith

How to detect ESC1 attacks

In a large enterprise environment, detecting malicious requests to vulnerable certificate templates can be challenging. While Event IDs 4886 and 4887 can show which user requested a certificate, they don’t reveal the value an attacker has specified in the subjectAltName to impersonate a specific account.

From a forensic standpoint, all certificate requests are logged (Figure 5) and can be viewed in the Certificate Authority UI under Issued Certificates. This section shows when a certificate request includes values like those in the subjectAltName, along with other important details such as who made the request, which certificate template was used, the EKU, and the relevant timestamps. These logs are helpful for investigating and tracing any suspicious certificate requests.

Figure 5. Certificates that have been issued by the CA server

Threat actor profiles

The following threat actors have been executing ESC1 attacks in the wild:

  • UNC53302
  • APT293

ESC1 tools

The following public Active Directory certificate abuse tools can be used to perform an ESC1 attack:

  • Certify
  • Certipy

Threat overview

ATT&CK Tactic: Privilege escalation

On April 4, 2024, Google Cloud published a report outlining how the threat actor UNC5330 exploited vulnerabilities CVE-2024-21893 and CVE-2024-21887 in Ivanti Connect Secure to infiltrate a victim’s network. They used an LDAP bind account to exploit a vulnerable Windows certificate template, creating a computer object and impersonating a domain administrator.4

On April 28, 2022, Mandiant reported that APT29 exploited misconfigured certificate templates to impersonate admin users. By abusing these misconfigurations in AD CS, the attacker was able to request certificates as low-privileged users and specify high-privileged accounts in the Subject Alternative Name (SAN) field. This allowed them to authenticate as those high-privileged users.5

Semperis snapshot

AD CS should be treated as a Tier 0 asset because it has direct control over the security of your entire Active Directory environment. Compromising AD CS could allow attackers to issue certificates that enable them to impersonate high-privileged accounts, bypass security controls, and gain complete access to sensitive systems.

Learn more about privilege escalation in AD

Endnotes

  1. https://github.com/jakehildreth/Locksmith/tree/main
  2. https://malpedia.caad.fkie.fraunhofer.de/actor/unc5330
  3. https://malpedia.caad.fkie.fraunhofer.de/actor/apt29
  4. https://cloud.google.com/blog/topics/threat-intelligence/ivanti-post-exploitation-lateral-movement
  5. https://cloud.google.com/blog/topics/threat-intelligence/tracking-apt29-phishing-campaigns