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:<RFC822>[email protected]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:<UPN>[email protected]Maps certificates containing this User Principal Name. Vulnerable because the userPrincipalName attribute can be modified.
3. Subject-Based - NOT EXPLOITABLE
X509:<S>CN=User Name,OU=Dept,DC=domain,DC=comRequires exact Subject match. Not exploitable via ESC14 because the CA controls the Subject field based on the requesting user.
4. Issuer + Subject - NOT EXPLOITABLE
Requires specific CA and Subject. Both values are CA-controlled and cannot be spoofed.
5. Serial Number + Issuer - NOT EXPLOITABLE
The serial number is randomly generated by the CA and unpredictable.
6. Subject Key Identifier (SKI) - NOT EXPLOITABLE
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 modifySubject/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:
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:
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
Target user (high-privileged) has:
altSecurityIdentities: X509:<RFC822>[email protected]Attacker controls low-privileged user who can enroll in vulnerable template
Attacker modifies controlled user's
mailattribute:mail: [email protected]Attacker requests certificate - CA includes the spoofed email
Certificate contains: Subject=lowpriv, [email protected], No SID
Attacker authenticates - DC checks altSecurityIdentities, finds admin user
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
NoSecurityExtensionflag removes SID from certificateTrusted 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:
SubjectAltRequireEmailORSubjectAltRequireUpnEnrollment Flag:
NoSecurityExtensionEnrollment permissions for attacker-controlled user
2. Target User Configuration
Has
altSecurityIdentitiesset with email or UPN formatHigher privileges than attacker's current access
3. Attribute Modification Rights
GenericAll, WriteDACL, or WriteProperty on controlled user
Ability to modify
mailoruserPrincipalNameattribute
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:
Look for: altSecurityIdentities: X509:<RFC822>[email protected]
Step 2: Find Vulnerable Template
Identify template with:
SubjectAltRequireEmailflagNoSecurityExtensionflagEnrollment rights for your user
Step 3: Modify Mail Attribute
Verify:
Step 4: Request Certificate
Output: Certificate saved as controlleduser.pfx
Step 5: Verify Certificate Content
Check for:
Subject: CN=controlleduser
Email: [email protected] (spoofed!)
No SID extension
Step 6: Authenticate as Target
Result: TGT and NTLM hash for admin user obtained!
Step 7: Use Credentials
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:
Request certificate (same as email-based):
Authenticate (same process):
Combined Approach
For maximum reliability, modify both attributes:
This ensures success regardless of which field the template includes.
References
Last updated