ESC1

Enrollee-Supplied Subject for Client Authentication

Description

"ESC1 is the stereotypical AD CS misconfiguration that can lead directly to privilege escalation. The vulnerability arises when a certificate template is inadequately secured, permitting a low-privileged user to request a certificate and, importantly, specify an arbitrary identity within the certificate's SAN. This allows the attacker to impersonate any user, including administrators.

The combination of these specific weak settings on a single certificate template creates the ESC1 vulnerability:

• Enrollee Supplies Subject: The template has the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag enabled. In the Certificate Template console, this is the "Supply in the request" option under the "Subject Name" tab. When enabled, the requester - not Active Directory - provides the subject information for the certificate. This is the core setting that allows an attacker to inject a victim's identity (e.g., UPN or DNS name) into the SAN.

• Authentication EKU: The template includes an EKU that permits authentication. Common EKUs that enable this are "Client Authentication" (OID 1.3.6.1.5.5.7.3.2), "Smart Card Logon" (OID 1.3.6.1.4.1.311.20.2.2), "PKINIT Client Authentication" (OID 1.3.6.1.5.2.3.4), or the overly permissive "Any Purpose" (OID 2.5.29.37.0). A certificate with such an EKU can be used for network logons.

• Permissive Enrollment Rights: Low-privileged users or broad groups like "Domain Users" or "Authenticated Users" are granted "Enroll" permissions on the template's security settings. This defines who can request certificates from this template.

• No Effective Security Gates: The template does not enforce manager approval (the "CA certificate manager approval" option in "Issuance Requirements") nor requires authorized signatures (also known as enrollment agent signatures). The absence of these controls means qualifying requests are automatically processed and certificates issued without additional review.

When these conditions are all met, any user with enrollment rights can submit a CSR for this template. In the CSR, they can specify an arbitrary UPN in the SAN (e.g., [e-mail]) and/or a SID in the szOID_NTDS_CA_SECURITY_EXT (OID 1.3.6.1.4.1.311.25.2) or via a specific SAN URL format if the SID extension is not used. The CA, trusting the template's insecure configuration, issues a certificate that appears to belong to the specified privileged account. The attacker can then use this certificate to authenticate via Kerberos PKINIT or Schannel, effectively gaining the privileges of the impersonated user.

This misconfiguration often occurs when administrators duplicate built-in templates (like "User" or "Machine") and modify them to allow "Supply in request", perhaps for compatibility with an application or device that requires specific subject names, without fully understanding the security ramifications. Another common scenario is duplicating a template like "WebServer" or "SubCA", which already has "Supply in request" enabled by default, and then adding a client authentication EKU to it. It's important to note that in an enterprise CA environment, new templates are typically created by duplicating an existing one, not from scratch. Due to its relative simplicity to exploit and its high impact, ESC1 is a frequently discovered and exploited AD CS vulnerability." — Oliver Lyak

There's nobody who can explain better about ESCs than Oliver Lyak — I only show how to build the lab.

Configuration

Go to start menu and type "Certification Authority". Expand the CA and right click "Certificate Templates", then click the "Manage" button.

Duplicate the template "User" and name it "ESC1". Then edit the following:

Select "Supply in the request". Then go to the "Security" tab and leave it like this:

Checking it out with Certipy reveals it is vulnerable.

Written by ruycr4ft