AD CS Part 1: Architecture, Template Semantics, and the ESC Taxonomy

The Identity Bridge: How Certificates Become Kerberos Tickets

In Active Directory environments, Active Directory Certificate Services (AD CS) is not merely an auxiliary PKI service for web servers or VPN endpoints. It functions as an authoritative identity provider directly integrated into the Kerberos Key Distribution Center (KDC) via RFC 4556 (Kerberos PKINIT).

Understanding AD CS exploitation requires recognizing one fundamental principle: an issued X.509 certificate with client authentication capabilities is an unconstrained credential. When an account acquires a certificate specifying its identity:

1. The client constructs a Kerberos AS-REQ containing pre-authentication data of type 16 (PA-PK-AS-REQ).
2. The client signs the authentication request with the private key corresponding to the public key in the certificate.
3. The KDC validates the certificate against the NTAuthCertificates store in the directory (CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=...).
4. The KDC extracts the principal identity from the Subject Alternative Name (SAN) or Object SID extension and issues a Kerberos Ticket Granting Ticket (TGT) with an embedded Privilege Attribute Certificate (PAC).

This authentication path bypasses password verification, NTLM hash verification, and account password rotation. Whoever controls the certificate enrollment parameters controls the resulting Kerberos ticket.

+------------------+         MS-WCCE / RPC          +----------------------+
|  Domain User     | ----------------------------> |  Enterprise CA       |
|  (Enrollee)      | <---------------------------- |  (Issues X.509 Cert) |
+------------------+     Issued Cert (SAN: Target)  +----------------------+
         |
         |  AS-REQ (Pre-Auth Type 16: PA-PK-AS-REQ)
         v
+------------------+                                +----------------------+
|  Kerberos KDC    | =============================> |  Target TGT + PAC    |
|  (Validates PKI) |   Returns TGT for SAN User     |  (Full Impersonation)|
+------------------+                                +----------------------+

Every certificate template configuration in Active Directory resolves four core technical questions. Privilege escalation vulnerabilities emerge whenever a template answers one or more of these questions insecurely:

1. Who can enroll? Governed by the Discretionary Access Control List (DACL) on the template object in LDAP.
2. Who defines the Subject Alternative Name (SAN)? Governed by mspki-certificate-name-flag (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) or CA-wide registry flags.
3. What is the certificate authorized to do? Governed by Extended Key Usage (EKU) OIDs defined in pKIExtendedKeyUsage.
4. How does the KDC map the certificate to a directory account? Governed by the presence of szOID_NTDS_CA_SECURITY_EXT and the KDC registry flag StrongCertificateBindingEnforcement.

Enumerating Certificate Authorities and Templates

In the Game of Active Directory (GOAD) multi-forest lab, two distinct Enterprise Certificate Authorities are deployed across the forest boundary. Running certipy-ad find against both environments highlights the contrast between a hardened baseline and an exploitable configuration.

Baseline CA: SEVENKINGDOMS-CA (Forest Root)

$ certipy-ad find -u [email protected] -p powerkingftw135 -dc-ip 192.168.56.10 -vulnerable -stdout
Certificate Authorities
  0
    CA Name             : SEVENKINGDOMS-CA
    DNS Name            : kingslanding.sevenkingdoms.local
    User Specified SAN  : Disabled
    Enforce Encryption for Requests : Enabled
    Permissions
      Enroll            : SEVENKINGDOMS.LOCAL\Authenticated Users
    [!] Vulnerabilities
      ESC8              : Web Enrollment is enabled over HTTP.

The forest root CA enforces encryption, disables user-specified SAN flags, and restricts template modification. The only flagged exposure is ESC8 (unauthenticated NTLM relay over HTTP web enrollment).

Exploitable CA: ESSOS-CA (Cross-Forest Target)

$ certipy-ad find -u [email protected] -p fr3edom -dc-ip 192.168.56.12 -vulnerable -stdout
Certificate Authorities
  0
    CA Name             : ESSOS-CA
    DNS Name            : braavos.essos.local
    User Specified SAN  : Enabled        # CA-wide ESC6
    [!] ESC8            : Web Enrollment is enabled over HTTP.
    [!] ESC11           : Encryption is not enforced for ICPR (RPC) requests.

Certificate Templates
  Template Name: ESC1     -> Enrollee supplies subject + Client Authentication EKU
  Template Name: ESC2     -> Any Purpose EKU / No EKU defined
  Template Name: ESC3-CRA -> Certificate Request Agent EKU
  Template Name: ESC4     -> Insecure DACL allows low-priv user GenericWrite
  Template Name: ESC9     -> No Security Extension (Missing Object SID)
  Template Name: WebServer -> Schema version 1 / Server Authentication

ESSOS-CA answers every fundamental question insecurely. In a production enterprise assessment, templates are rarely named with explicit vulnerability labels like ESC1. However, an administrative template named WebServer_Internal or VPN_AutoEnroll bearing identical bitmask flags presents the exact same attack path.

The ESC Taxonomy by Architectural Root Cause

Rather than viewing the SpecterOps Certified Pre-Owned taxonomy as an arbitrary list of numbered vulnerabilities, security practitioners should group ESC vectors by their technical failure domain:

Detailed Root Cause Analysis

1. Subject Alternative Name Specification (ESC1 and ESC6)

The Subject Alternative Name (SAN) extension defines the principal identity tied to an X.509 certificate. Normal enrollment procedures require the CA to generate the SAN automatically based on the caller’s Active Directory account properties (e.g., pulling the user’s userPrincipalName or sAMAccountName).

When mspki-certificate-name-flag contains the bit 0x00010000 (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT), the CA allows the certificate requester to inject an arbitrary SAN value during the Certificate Signing Request (CSR):

# CSR Attribute indicating arbitrary SAN supply:
szOID_SUBJECT_ALT_NAME2 (2.5.29.17) = UPN: [email protected]

If the template simultaneously specifies the Client Authentication EKU (1.3.6.1.5.5.7.3.2) or Smart Card Logon (1.3.6.1.4.1.311.20.2.2), this configuration constitutes ESC1. A low-privileged domain user requests a certificate specifying a Domain Admin’s UPN, authenticates through PKINIT, and receives the privileged account’s TGT.

ESC6 shifts this vulnerability from the individual template to the Certificate Authority service itself. By setting the CA registry flag EDITF_ATTRIBUTESUBJECTALTNAME2 (0x00040000), administrators enable client-specified SAN attributes across every template published by that CA. Even templates explicitly configured with CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT = False become vulnerable if they support client authentication.

2. Extended Key Usage Semantics (ESC2, ESC3, and ESC17)

The pKIExtendedKeyUsage attribute restricts how a generated certificate can be used by client applications:

Client Authentication      : 1.3.6.1.5.5.7.3.2
Smart Card Logon           : 1.3.6.1.4.1.311.20.2.2
Any Purpose (All Purpose)  : 2.5.29.37.0
Certificate Request Agent  : 1.3.6.1.4.1.311.20.2.1
Server Authentication      : 1.3.6.1.5.5.7.3.1

• ESC2 (Any Purpose EKU): If a template includes the Any Purpose OID (2.5.29.37.0) or omits the EKU extension entirely, the certificate acts as a universal credential. It can be used for client authentication or to sign secondary certificate requests.
• ESC3 (Certificate Request Agent): Templates configured with the Certificate Request Agent EKU permit the enrollee to act as an enrollment proxy. An attacker requests an Enrollment Agent certificate, then uses it to co-sign an enrollment request on behalf of a target privileged user against a secondary template, bypassing standard authentication checks.
• ESC17 (Server Authentication Pivot): While defenders frequently audit templates for Client Authentication, templates with Server Authentication (1.3.6.1.5.5.7.3.1) that allow user-specified subjects permit an attacker to request certificates on behalf of computer accounts. The resulting machine certificate enables Kerberos Constrained Delegation (S4U2Self / S4U2Proxy) attacks.

3. Identity Binding and Security Extensions (ESC9 and ESC10)

For the KDC to process PKINIT, it must map the certificate to a directory account. In legacy environments, the KDC simply parsed the UPN from the certificate’s SAN and matched it to an account’s userPrincipalName attribute in LDAP.

To prevent UPN spoofing and account collision attacks (such as CVE-2022-26923), Microsoft introduced the Object SID security extension:

szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2) = ASN.1 Encoded Object SID

When this extension is present, the KDC verifies that the certificate’s embedded SID matches the authenticating account’s objectSid.

• ESC9: The template specifies mspki-enrollment-flag containing 0x00080000 (CT_FLAG_NO_SECURITY_EXTENSION). The issued certificate carries no SID extension. If an attacker possesses GenericWrite permissions over a victim account’s userPrincipalName, they change the victim’s UPN to a temporary value, enroll a certificate under their own account using the victim’s UPN, revert the changes, and authenticate as the victim.
• ESC10: Governed by the Domain Controller registry key HKLM\System\CurrentControlSet\Services\Kdc\StrongCertificateBindingEnforcement. If this value is set to 0 (Disabled) or 1 (Compatibility Mode), the KDC accepts certificates lacking the SID extension without performing strong binding checks. Only setting StrongCertificateBindingEnforcement = 2 enforces strict mapping and neutralizes ESC9 fallback.

4. PKI Object Access Control (ESC4, ESC5, and ESC7)

In Active Directory, certificate templates and Certificate Authority definitions are stored as standard LDAP objects under the Configuration naming context:

Templates : CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=essos,DC=local
CA Object : CN=ESSOS-CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=essos,DC=local

Every standard object DACL rule applies:

• ESC4: A low-privileged account holds WriteProperty, WriteDacl, or GenericAll over a certificate template object. The attacker modifies mspki-certificate-name-flag to enable CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT, adds Domain Users to the template’s Enroll ACE, and converts a non-privileged template into an active ESC1 vector.
• ESC7: An account holds ManageCA or ManageCertificates on the Certificate Authority object. ManageCertificates allows approving pending certificate requests that require managerial sign-off. ManageCA allows modifying CA configuration parameters via RPC, including enabling EDITF_ATTRIBUTESUBJECTALTNAME2 or publishing subordinate CA certificates.

Defensive Engineering and Detection Telemetry

Auditing and defending Active Directory Certificate Services requires monitoring both certificate lifecycle events on the CA and authentication traffic on Domain Controllers.

Critical Event IDs for AD CS Monitoring

// KQL Query: Detect PKINIT TGT Requests by Non-Standard Accounts
SecurityEvent
| where EventID == 4768
| extend PreAuthType = tostring(parse_xml(EventData).Data[4].["#text"])
| where PreAuthType == "16"
| extend TargetAccount = tostring(parse_xml(EventData).Data[0].["#text"])
| project TimeGenerated, Computer, TargetAccount, IpAddress, PreAuthType

Remediation Protocol

1. Eliminate Enrollee-Supplied Subjects: Audit all published templates using certipy-ad find -vulnerable. Remove CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT (0x00010000) from any template accessible by non-administrative principals.
2. Disable CA-Wide SAN Injection: Execute on all Enterprise CAs:

   certutil -config "braavos.essos.local\ESSOS-CA" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
   net stop certsvc && net start certsvc

3. Enforce Strong Certificate Binding: On all Domain Controllers, set:

   reg add "HKLM\SYSTEM\CurrentControlSet\Services\Kdc" /v StrongCertificateBindingEnforcement /t REG_DWORD /d 2 /f

4. Harden Template Access Control: Ensure non-administrative users do not hold GenericWrite, WriteDacl, or WriteProperty rights over objects in CN=Certificate Templates.
5. Disable Plaintext Web Enrollment: Remove the CertSrv virtual directory from IIS or enforce HTTPS with Extended Protection for Authentication (EPA).

Up Next in Part 2

With the architectural foundation established, Part 2: ESC1 Exploitation demonstrates the live weaponization of ESC1 against ESSOS-CA. We examine RPC endpoint targeting, analyze the PKINIT authentication exchange, and execute a DRSUAPI DCSync to extract forest root credentials.

Evidence and limits

Certificate Authority and template enumerations were run against SEVENKINGDOMS-CA (192.168.56.10) and ESSOS-CA (192.168.56.23) inside the isolated GOAD lab. All template attributes, OIDs, and DACLs reflect GOAD’s intentionally vulnerable PKI configuration.

References

• Orange Cyberdefense, GOAD: orange-cyberdefense.github.io/GOAD
• SpecterOps, Certified Pre-Owned: posts.specterops.io
• The Hacker Recipes, Active Directory Certificate Services: thehacker.recipes/ad/movement/adcs
• Microsoft, AD CS Architecture and Protocol Overview: learn.microsoft.com
• Microsoft, KB5014754: Certificate-based authentication changes: support.microsoft.com
• MITRE ATT&CK, Steal or Forge Authentication Certificates (T1649): attack.mitre.org/techniques/T1649