AD CS abuse, Part 1: templates and the escalation primitives
PKI foundations, how certificates authenticate, and the ESC1–ESC4 template attacks
Start here
- Part 1 (this page): Templates and the escalation primitives. Public Key Infrastructure (PKI) and Active Directory Certificate Services (AD CS) foundations, how a certificate actually logs you in, certificate-to-account mapping and the 2022–2025 strong-mapping hardening, and the four template attacks: ESC1 (enrollee-supplied subject), ESC2 (Any Purpose), ESC3 (enrollment agent), ESC4 (writable template).
- Part 2: Certificate Authority (CA) configuration, access control, and relay. ESC5 (PKI object Access Control Lists (ACLs)), ESC6 (the Subject Alternative Name (SAN) flag on the CA), ESC7 (dangerous CA permissions), ESC8 and ESC11 (relaying authentication into AD CS), plus certificate theft and golden-certificate persistence.
- Part 3: Defeating the mapping, and the newer escalations. ESC9, ESC10, ESC13, ESC14, ESC15/EKUwu and ESC16 (the techniques that strip or dodge the Security Identifier (SID) extension), ESC17, and the full hardening and remediation program.
Highlight key
- the term being defined
- Key term: bold with a highlighter swash. A concept's defining phrase.
- how something works
- Mechanism: wavy underline. How a piece works or relates to another.
- Risk: what makes an attack possible
- Risk: warm highlight with a dashed edge. Attack prerequisites and dangerous conditions.
- Fix: the mitigation to apply
- Fix: solid green underline. A mitigation or configuration change.
- Verify: how to confirm it worked
- Verify: green underline with a check. How to prove a fix works.
- only if, by default
- Qualifier: bold italic. A word that changes the claim.
4769- Technical literal: monospace chip. Commands, settings, event IDs, exactly as typed.
Plain English first
Organizations hand out digital certificates for Wi-Fi, Virtual Private Network (VPN), smart cards and websites. Active Directory Certificate Services (AD CS) is the in-house machine that prints them. The catch is that a certificate can be a logon credential, not just an encryption key, and the machine is usually configured by whoever first needed certificates, then forgotten.
An attacker who can request the wrong kind of certificate can request one that says "I am a domain administrator," and then Risk: log in as that administrator, no password required. That is the heart of AD CS abuse. The community has catalogued more than a dozen variants, numbered ESC1, ESC2, and so on.
This part lays the foundation, how certificates work and how they authenticate, and then covers the four attacks that come from misconfigured certificate templates. If you learn how templates and certificate mapping work here, the rest of the series is mostly application.
The analogy: a badge printer with a broken form
Think of AD CS as the office badge printer. Normally you fill in a request and the system prints a badge with your own name and your own access level, taken from Human Resources (HR). A misconfigured template is a request form that lets you Risk: type any name and any access level yourself. You write "Chief Executive Officer (CEO), all floors," the printer makes it, and the door reads the badge, not your face. The 2025 security change is like adding a tamper-proof employee number to every badge: the door now checks the number, not the typed name, which spoils the simplest forgery, until attackers find a template that leaves the number off.
Why it matters now
Certificate templates are a top escalation route because the win is so clean: Risk: any domain user can often reach domain admin through one enrollable template, with no exploit and no cracked password. Tooling (Certipy, BloodHound) finds the templates in minutes, and the resulting certificate is Risk: a durable credential that survives password resets.
Microsoft's strong-mapping enforcement has been the default since February 2025, which blunts the classic version, but it doesn't close template ACL abuse, enrollment-agent abuse, or relay, and attackers have ways to dodge the mapping. The levers are concrete: Fix: remove enrollee-supplied subject, scope enroll rights, restrict enrollment agents, lock template ACLs, and treat the CA as Tier 0.
If you remember only 5 things
- A certificate is an identity, not just a key. An authentication Enhanced Key Usage (EKU) plus a private key is a logon credential you can replay with Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). Treat the CA that issues them as Tier 0.
- ESC1 is "name yourself an admin." A template that lets the requester supply the subject and carries an auth EKU, enrollable by ordinary users, Risk: lets anyone request a domain-admin certificate.
- The SID extension changed the game. Since the 2022 patch the CA stamps the requester's SID into the certificate, and Full Enforcement (default since Feb 11, 2025) maps by that SID, so classic ESC1 now maps back to you unless the extension is defeated (Part 3).
- Enforcement didn't end AD CS abuse. Risk: ESC3, ESC4, relay, and the mapping-defeat Escalations (ESCs) still work, so the template fixes still matter.
- Certificates are hard to evict. A stolen or minted certificate Risk: keeps working after password resets until it expires or is revoked. Response means revocation, sometimes rebuilding the PKI.
Core concepts
Thirteen ideas, from "what is a certificate" to "how the Domain Controller (DC) decides who a certificate is." Open "Go deeper" for expert detail.
01What Active Directory Certificate Services (AD CS) is, and why it's dangerousAD CS is Microsoft's certificate authority built into Active Directory, issuing certificates that services and logons trust.
Organizations use certificates for Wi-Fi, Virtual Private Network (VPN), smart cards, web servers and secure email. AD CS is the in-house factory that makes them. The problem is that Risk: a certificate can also be a logon credential, and the factory is often configured by whoever needed Wi-Fi certificates years ago.
A help-desk user requests a certificate from a template nobody has reviewed since 2019, and that certificate lets them log on as a domain administrator.
TechnicalGo deeper
AD CS abuse went mainstream with SpecterOps' 2021 "Certified Pre-Owned" paper (Will Schroeder and Lee Christensen), which named the first eight escalation techniques (ESC1–ESC8). The catalogue has since grown past ESC16. The throughline: the Certificate Authority (CA) issues identity, and identity is the keys to the domain. A CA trusted for authentication is Risk: a Tier 0 asset, as sensitive as a domain controller, yet frequently run and delegated like an ordinary application server.
02Certificates and keys, in plain termsA certificate is a signed statement binding a public key to an identity, vouched for by a Certificate Authority (CA).
You hold a private key that only you have, and a matching public key anyone can see. A certificate is the CA saying "this public key belongs to jdoe." Prove you hold the private key and you've proved you're jdoe, no password involved.
jdoe's smart card holds her private key; her certificate says the matching public key is jdoe's. Inserting the card and entering a Personal Identification Number (PIN) proves possession, and she's logged on.
TechnicalGo deeper
The certificate is public and useless without the private key. That makes the private key the secret worth stealing (Part 2's theft techniques) and Risk: a certificate's long validity a persistence dream: a one-year certificate keeps working even if the victim changes their password, because authentication proves key possession, not knowledge of a secret. Revocation via a Certificate Revocation List (CRL) is the only cancel button, and many clients don't check revocation.
03The certificate authority and the certificate templateA template is the blueprint for a kind of certificate; the Certificate Authority (CA) stamps out certificates according to it.
Rather than configuring each certificate by hand, admins define templates: "User", "Web Server", "Smart Card Logon". A template fixes what the certificate can do, who may request one, and whether someone can fill in the identity themselves.
The built-in "User" template issues a client-authentication certificate to any domain user, with the identity taken automatically from their account.
TechnicalGo deeper
A template is an Active Directory (AD) object under the configuration partition, readable by any domain user over Lightweight Directory Access Protocol (LDAP). The CA "publishes" a subset of templates, meaning it will issue from them. The settings that matter for abuse: the Enhanced Key Usages (EKUs), who has the Enroll right, whether the subject is built from AD or supplied by the requester, whether a manager must approve, and how many authorized signatures a request needs. Every ESC1–ESC4 condition is one of these settings gone wrong. Templates also have a schema version (v1 vs v2+), which changes how application policies behave, important for ESC2, ESC3 and ESC15.
04Enrollment: who can get a certificateEnrollment rights decide which principals may request a certificate from a template.
To abuse a template, you usually have to be allowed to request from it. If the Enroll right is granted to a broad group, the bar is on the floor.
A template grants Enroll to Domain Users, so Risk: every account in the domain, including the next phished one, can request from it.
TechnicalGo deeper
Two gates sit in front of issuance. Fix: Manager approval puts a human in the loop before the certificate is issued (it goes to a pending state). Fix: Authorized signatures require the request itself to be co-signed by one or more existing certificates with specific application policies, the mechanism behind enrollment agents. Both are off on a classic ESC1 template. When auditing, Verify: read the enroll Access Control Entrys (ACEs) and these two settings together; a dangerous Enhanced Key Usage (EKU) is only reachable if someone untrusted can actually enroll.
05Enhanced Key Usages (EKUs): what a certificate is allowed to doThe EKU is the list of purposes a certificate is valid for, each named by an Object Identifier (OID).
A certificate isn't a blank cheque. Its EKU says "this is for encrypting email" or "this is for logging on." The ones that matter for attacks are the authentication EKUs, because they make the certificate a usable logon credential.
A certificate with the Client Authentication EKU can be used to log on; one with only the Encrypting File System EKU cannot.
TechnicalGo deeper
The authentication EKUs to recognise: Client Authentication (1.3.6.1.5.5.7.3.2), Smart Card Logon (1.3.6.1.4.1.311.20.2.2), Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Client Authentication (1.3.6.1.5.2.3.4), and the wildcard Any Purpose (2.5.29.37.0), plus a certificate with no EKU at all, which is valid for anything. Risk: Any of these on an enrollee-supplies-subject template is ESC1. A separate OID, Certificate Request Agent (1.3.6.1.4.1.311.20.2.1), doesn't authenticate but lets the holder enroll on behalf of others, which is ESC3. On v1 templates, application policies can override the listed EKU, the seam ESC15 abuses.
06The subject and the Subject Alternative Name (SAN): the identity in the certificateThe subject and SAN are where the certificate says who you are; the SAN is what authentication actually reads.
A certificate names its owner. For logon, Windows looks at the Subject Alternative Name, usually a User Principal Name (UPN) for a user or a Domain Name System (DNS) name for a computer. Whoever controls what goes in the SAN controls who the certificate claims to be.
A normal User certificate has SAN = jdoe@corp.example, copied from jdoe's account. An ESC1 certificate has SAN = administrator@corp.example, typed by the attacker.
TechnicalGo deeper
The pivotal setting is CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT ("Supply in the request" in the Graphical User Interface (GUI)). Normally the Certificate Authority (CA) builds the subject from the requester's Active Directory (AD) account. Risk: With this flag, the requester dictates the SAN, including someone else's UPN. Combine enrollee-supplied subject with an authentication Enhanced Key Usage (EKU) and open enroll rights and you have ESC1: request a logon certificate that names an administrator. Whether that certificate then authenticates as the administrator depends on certificate mapping and the Security Identifier (SID) extension, next.
07How a certificate logs you in (Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) and Schannel)A certificate authenticates either through Kerberos (PKINIT) or through Transport Layer Security (TLS) (Schannel).
There are two doors. PKINIT swaps a certificate for a Kerberos ticket at the domain controller, the usual attacker path. Schannel uses the certificate as a TLS client certificate to a service like LDAP over SSL (LDAPS) or a web server.
An attacker with an administrator.pfx runs a tool that performs PKINIT and receives a Ticket Granting Ticket (TGT) as the administrator, then uses it like any other ticket.
TechnicalGo deeper
PKINIT is the richer target. Beyond a TGT, a known trick retrieves the account's NT LAN Manager (NTLM) hash from the privileged attribute returned during PKINIT ("UnPAC-the-hash"), turning a certificate into a reusable password hash. Schannel mapping is a bit different and is governed by its own settings (CertificateMappingMethods), which matters for LDAPS-based paths and relay in Part 2. Either way, the certificate is only as good as the account the Domain Controller (DC) maps it to, which is the next concept.
08Certificate-to-account mappingMapping is how the Domain Controller (DC) decides which account a certificate represents.
A certificate presents an identity, but Active Directory (AD) still has to tie it to a specific account. It does this implicitly (match the User Principal Name (UPN) or Domain Name System (DNS) name in the Subject Alternative Name (SAN) to an account) or explicitly (an admin lists the certificate on the account's altSecurityIdentities attribute).
Implicit: a certificate with SAN administrator@corp.example maps to the Administrator account by UPN. Explicit: an account lists a specific certificate's issuer and serial number as allowed.
TechnicalGo deeper
Implicit, name-based mapping is exactly what ESC1 abuses: control the name, control the account. Fix: Explicit mappings can be strong or weak. Strong mappings tie to something unforgeable, the issuer and serial number, the public key, or the Subject Key Identifier (SKI). Weak ones (subject, email, name) can be spoofed. The 2022–2025 hardening, next, makes the DC prefer an unforgeable Security Identifier (SID) carried in the certificate over any name, which quietly changed whether classic ESC1 still works.
09The Security Identifier (SID) security extension and strong mappingSince 2022 the Certificate Authority (CA) embeds the requester's SID in a certificate extension, and the Domain Controller (DC) now requires a strong, unforgeable mapping.
Microsoft closed the "just name yourself an admin" hole. After the May 2022 update, enterprise CAs stamp the requesting account's SID into the certificate. Domain controllers check that SID, so the name in the Subject Alternative Name (SAN) no longer wins on its own.
An ESC1 certificate you request names Administrator in the SAN, but the CA stamps your own SID into the extension. Under Full Enforcement the DC maps by that SID, so you authenticate as yourself, not the administrator, and it logs an object-SID mismatch.
TechnicalGo deeper
The extension Object Identifier (OID) is 1.3.6.1.4.1.311.25.2, tied to Common Vulnerabilities and Exposures (CVE) entry CVE-2022-26923. StrongCertificateBindingEnforcement has three modes: 0 Disabled, 1 Compatibility, 2 Full. Full Enforcement became the default on February 11, 2025, and the registry override stopped being honored on September 9, 2025, so Risk: modern domains are in Full Enforcement whether or not anyone chose it. The practical consequence is huge: classic ESC1 impersonation now depends on defeating the SID extension (stripping it, or finding a CA that doesn't add it), which is the ESC9/ESC10/ESC16 territory of Part 3. On an unpatched or non-enforcing CA, ESC1 still works the old way.
10Why certificates are such good lootCertificates are long-lived credentials that survive password resets and work offline.
A stolen password dies when the user changes it. A stolen certificate keeps authenticating until it expires or is revoked, which for logon certificates is often a year. That makes certificates a favourite for quiet, durable access.
An attacker mints or steals a certificate for a domain admin. The team resets every admin password during incident response, but Risk: the certificate still works because it was never a password.
TechnicalGo deeper
This is why certificate persistence (Part 2's golden certificate, made by stealing the Certificate Authority (CA)'s own private key) is so feared: it lets an attacker Risk: forge certificates for anyone, valid until the CA's key is rotated, which almost never happens cleanly. Response therefore has to include revocation, and sometimes rebuilding the Public Key Infrastructure (PKI). Verify: Hunt for issued certificates, not just tickets, during any suspected Active Directory Certificate Services (AD CS) incident.
11The Escalation (ESC) taxonomy"ESC" numbers are a community catalogue of Active Directory Certificate Services (AD CS) escalation techniques, now running past ESC16.
Each ESC is a named way to turn certificate access into more privilege. They group into template problems, CA-configuration problems, access-control problems, relay, and tricks that defeat the Security Identifier (SID) mapping.
ESC1 is a template that lets you name yourself; ESC8 is relaying authentication to the Certificate Authority (CA)'s web page; ESC16 is a CA configured to omit the SID extension for everyone.
TechnicalGo deeper
Part 1 covers the template family: ESC1 (enrollee-supplied subject), ESC2 (Any Purpose), ESC3 (enrollment agent), ESC4 (writable template). Part 2 covers CA configuration and access control (ESC5, ESC6, ESC7), relay (ESC8, ESC11), and theft and persistence. Part 3 covers the mapping-defeat and newer techniques (ESC9, ESC10, ESC13, ESC14, ESC15/EKUwu, ESC16, ESC17). Numbering is informal and varies by source; some tools now list ESC1–ESC17, and ESC12 is hardware-specific. Treat the names as shared shorthand, not a standard.
12Template schema versionsA template's schema version (v1 vs v2+) changes how it handles policies and enrollment.
Older v1 templates (like the built-in User) behave differently from the v2 and later templates admins create. The difference looks academic until it decides whether an attack works.
The built-in User template is schema v1 and is the usual target for enrollment-agent (ESC3) requests on behalf of others.
TechnicalGo deeper
v1 templates Risk: let the requester specify application policies in the request, and on v1 those application policies can override the template's Enhanced Key Usage (EKU). That seam is Common Vulnerabilities and Exposures (CVE) entry CVE-2024-49019 / ESC15 ("EKUwu"), covered in Part 3: a v1 template meant for web servers can be coaxed into issuing a client-authentication or enrollment-agent certificate. v2+ templates add issuance requirements (authorized signatures, application-policy requirements) that enable or constrain ESC3-style delegation. Verify: When enumerating, note the schema version alongside the EKUs; it tells you which abuses are even possible.
13Active Directory Certificate Services (AD CS) as attack-graph edgesGraph tools model each Escalation (ESC) as an edge from an enrollable principal to a privileged target.
The same graph thinking from the attack-paths note applies: a vulnerable template is an arrow from everyone who can enroll to the account they can become. Certificate edges are often the shortest arrows in the whole graph.
BloodHound shows an ADCSESC1 edge from Domain Users to the domain, because any user can enroll in a template that lets them name a domain admin.
TechnicalGo deeper
BloodHound Community Edition (CE) models AD CS objects (CertTemplate, EnterpriseCA, RootCA, NTAuthStore, Authority Information Access Certification Authority (AIACA)) and derives ADCSESC1, ADCSESC3, ADCSESC4, ADCSESC6a/b, ADCSESC9/10/13 and GoldenCert edges in post-processing from template, Certificate Authority (CA) and enrollment data. Certipy's find does the same enumeration without the graph. Post-processed edges can be wrong if the CA's enforcement state isn't modelled, so Verify: validate a certificate path against the live CA and its mapping mode before reporting it as exploitable. This is where Part 1's mapping concepts pay off.
Visual map
Step through a normal enroll-and-logon, the ESC1 and ESC3 attacks, and the mapping logic that now decides whether ESC1 even works. Verify: Each attack step names the defense that breaks it.
The four template attacks at a glance
| ESC1 | ESC2 | ESC3 | ESC4 | |
|---|---|---|---|---|
| Root cause | Enrollee-supplied subject + auth Enhanced Key Usage (EKU) | Any Purpose / no EKU | Certificate Request Agent EKU | Writable template Access Control List (ACL) |
| Key setting | CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT | EKU = 2.5.29.37.0 or none | EKU = 1.3.6.1.4.1.311.20.2.1 | FullControl / WriteDacl / WriteOwner |
| Who abuses it | Anyone with enroll rights | Anyone with enroll rights | Anyone with enroll rights on the agent template | Anyone with write on the template |
| Impersonation step | Supply a privileged User Principal Name (UPN) in the Subject Alternative Name (SAN) | Use cert as an enrollment agent | Enroll on behalf of a victim | Rewrite into ESC1, then enroll |
| Affected by Full Enforcement? | Yes, mapping now defeats classic impersonation | Partly (its on-behalf-of child carries the victim Security Identifier (SID)) | No, cert is issued for the victim | No (you rebuild the template) |
| First fix | Remove enrollee-supplied subject | Scope the EKU | Enrollment Agent Restrictions + tight enroll | Lock the template ACL |
Authentication EKUs to recognise
| EKU | Object Identifier (OID) | Lets the certificate… |
|---|---|---|
| Client Authentication | 1.3.6.1.5.5.7.3.2 | Authenticate as a client (Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), Schannel) |
| Smart Card Logon | 1.3.6.1.4.1.311.20.2.2 | Log on interactively via smart card / PKINIT |
| PKINIT Client Authentication | 1.3.6.1.5.2.3.4 | Authenticate via PKINIT |
| Any Purpose | 2.5.29.37.0 | Anything, including the above (ESC2) |
| (no EKU present) | — | Anything, like Any Purpose (ESC2) |
| Certificate Request Agent | 1.3.6.1.4.1.311.20.2.1 | Risk: Enroll on behalf of others (not auth itself; ESC3) |
Strong vs weak certificate mapping
| Mapping | Type | Verdict under Full Enforcement |
|---|---|---|
SID security extension (1.3.6.1.4.1.311.25.2) | Implicit, unforgeable | Fix: Preferred; trusted |
| Issuer + serial number | Explicit (altSecurityIdentities) | Fix: Strong; trusted |
| Subject Key Identifier (SKI) | Explicit | Fix: Strong; trusted |
| Public key (SHA1) | Explicit | Fix: Strong; trusted |
| Issuer + subject | Explicit | Risk: Weak; rejected |
| Subject only | Explicit | Risk: Weak; rejected |
| Email (RFC822) | Explicit | Risk: Weak; rejected |
| UPN / Domain Name System (DNS) in SAN | Implicit, name-based | Allowed only with a valid SID extension or strong mapping |
Technical deep dive
TechnicalUnder the hood
The objects, and who can read them
Active Directory Certificate Services (AD CS) stores its configuration in Active Directory (AD)'s configuration partition under CN=Public Key Services: the certificate templates (CN=Certificate Templates), the enterprise Certificate Authoritys (CAs) (CN=Enrollment Services), the NTAuth store (CN=NTAuthCertificates, the list of CAs trusted for authentication), and the trust anchors. All of it is readable by any authenticated user over Lightweight Directory Access Protocol (LDAP), which is why enumeration needs no special rights and why the attack surface is visible to every account in the domain.
A template becomes issuable only when an enterprise CA publishes it (lists it in its certificateTemplates attribute). So the exploitable set is "templates that meet an Escalation (ESC) condition and are published by a CA." Verify: Enumerate both together; an ugly template that no CA publishes is latent, not live.
What actually makes a certificate a logon credential
Three things must line up:
- An authentication Enhanced Key Usage (EKU) (or Any Purpose / no EKU), so the certificate is valid for client authentication.
- An identity the attacker controls, usually a User Principal Name (UPN) or Domain Name System (DNS) name in the Subject Alternative Name (SAN).
- A mapping from that identity to the target account that the Domain Controller (DC) will accept.
Remove any one and the certificate can't impersonate. The ESCs are different ways of obtaining all three; the defenses are different ways of denying one.
Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), the Privilege Attribute Certificate (PAC), and UnPAC-the-hash
PKINIT is pre-authentication with a certificate: the client signs the timestamp with its private key, the Key Distribution Center (KDC) validates the certificate chain and mapping, and returns a Ticket Granting Ticket (TGT). The TGT's Privilege Attribute Certificate (PAC) carries the account's groups. A documented follow-on, "UnPAC-the-hash," extracts the account's NT LAN Manager (NTLM) hash from the PA-PK-AS-REP material, so a single certificate yields both a Kerberos TGT and a reusable New Technology (NT) hash. This is why "it's only a certificate" understates the impact: Risk: one misissued certificate can become a password-equivalent.
The mapping decision, in order
When a certificate is presented, the DC binds it to one account:
- Security Identifier (SID) security extension present? Map by that SID. Fix: Unforgeable, and preferred. This is what defeats classic ESC1, because the CA put the requester's SID there.
- Explicit mapping in
altSecurityIdentities? Trust it if it's strong (issuer+serial, Subject Key Identifier (SKI), public key); Risk: reject it if it's weak (subject, subject-only, email) under enforcement. - Fall back to the SAN name (UPN/DNS). Under Full Enforcement, allowed only if a SID extension or strong mapping also validates; otherwise denied with event 39.
The strong-mapping timeline
| Date | Change |
|---|---|
| May 10, 2022 | Update ships; DCs move to Compatibility mode. Enterprise CAs begin adding the SID extension (1.3.6.1.4.1.311.25.2) to certificates from online templates. Addresses Common Vulnerabilities and Exposures (CVE) entry CVE-2022-26923. |
| April 11, 2023 | Disabled mode (0) is no longer honored. |
| February 11, 2025 | Full Enforcement becomes the default for DCs with no explicit setting. Certificates without a strong mapping or valid SID extension are denied. |
| September 9, 2025 | The StrongCertificateBindingEnforcement registry override is no longer supported; environments are effectively on Full Enforcement. |
So in any current domain, assume Full Enforcement. Classic ESC1 impersonation works only where the CA doesn't add the extension (unpatched, or a template with the no-security-extension flag) or where a Part 3 technique strips it.
Schannel is a separate door
Certificate authentication to Transport Layer Security (TLS) services (LDAP over SSL (LDAPS), Internet Information Services (IIS)) goes through Schannel, governed by CertificateMappingMethods on the DC rather than PKINIT's rules. It has its own weak/strong behavior and is the destination for some relay chains in Part 2. Blocking PKINIT does not block Schannel, so both paths matter when you reason about exposure.
Common misconceptions
| Misconception | Reality |
|---|---|
| "AD CS just does encryption." | It issues identities; an auth-EKU certificate is a logon credential. |
| "Full Enforcement killed AD CS attacks." | It mainly blunts classic ESC1 mapping. Risk: ESC3, ESC4, relay and mapping-defeat still work. |
| "ESC1 is always critical." | Under enforcement with the SID extension, impersonation maps back to the requester. Validate before rating. |
| "Only the Public Key Infrastructure (PKI) team needs to care." | A template setting is an AD privilege decision; it needs joint AD/PKI review. |
| "Revoking the user's password contains it." | Certificates survive resets; Fix: you must revoke the certificate, maybe rotate the CA key. |
| "No CA means no exposure." | True, but AD CS is widely installed for Wi-Fi/Virtual Private Network (VPN)/smartcards and often forgotten. |
| "A scary template is a finding." | Only if a CA publishes it and untrusted principals can enroll. Verify: Check both. |
Finding and verifying templates
# Enumerate (read-only). Certipy flags ESC conditions.
certipy find -u user@corp.example -p '***' -dc-ip 10.0.0.1 -vulnerable -stdout
# Review a specific template's key settings in PowerShell (AD side)
Get-ADObject -SearchBase (("CN=Certificate Templates,CN=Public Key Services,CN=Services," + `
(Get-ADRootDSE).configurationNamingContext)) -Filter * -Properties `
msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage, msPKI-Enrollment-Flag, nTSecurityDescriptor
# msPKI-Certificate-Name-Flag with ENROLLEE_SUPPLIES_SUBJECT (0x1) set is the ESC1 tell.Attacker's view
AttackerAttacker's view, for defenders
Each technique is covered at the level needed to recognise, test for and explain it: the exact template conditions, what makes it vulnerable, the evidence it leaves, and how it reads as a finding. Tool names are given so you can build detections and a lab. Weaponized request syntax is deliberately omitted; the Certipy wiki's per-ESC pages and an authorized lab are the place for hands-on practice.
Enumerating Active Directory Certificate Services (AD CS)ATT&CKT1649 Steal or Forge Authentication Certificates (discovery phase) · T1087 Account Discovery
The attacker reads the Certificate Authority (CA) and template objects from Active Directory (AD) over Lightweight Directory Access Protocol (LDAP) and checks each published template against the Escalation (ESC) conditions. No special rights are needed to look, because templates and CA settings are world-readable to domain users.
Risk: Any authenticated domain account and network reach to a Domain Controller (DC) and the CA.
Any environment with AD CS installed. Exposure rises with Risk: many custom templates, broad enroll rights, and no issuance auditing, so dangerous templates sit unnoticed.
Certipy (find), BloodHound Community Edition (CE) with SharpHound (which collects AD CS objects and derives ESC edges), Certify, and PSPKIAudit or Locksmith on the defensive side.
# Recognise these; they read, they don't exploit
certipy find -u user@corp.example -p '***' -dc-ip 10.0.0.1 -vulnerable
certipy find -enabled -stdout # enabled templates onlyA burst of LDAP reads of the configuration partition's certificate templates and enrollment-services containers. Verify: Quiet on its own; it looks like ordinary directory reads, so detection usually comes later at issuance.
Not a finding by itself. It frames the finding: "these N templates are enrollable by ordinary users and meet ESC1–ESC4 conditions." Retest: the flagged templates no longer meet the conditions.
ESC1: enrollee-supplied subject on an auth templateATT&CKT1649 Steal or Forge Authentication Certificates
The attacker requests a certificate from a template that lets the requester supply the subject and carries an authentication Enhanced Key Usage (EKU), naming a privileged account in the Subject Alternative Name (SAN). They then authenticate as that account via Public Key Cryptography for Initial Authentication in Kerberos (PKINIT).
A published template with Risk: enrollee-supplied subject, an authentication EKU, open enroll rights, no manager approval and no authorized signatures. For impersonation to succeed, the Certificate Authority (CA) must not bind an overriding Security Identifier (SID) (older/unpatched CA, or paired with a Part 3 mapping-defeat).
Risk: Templates with "Supply in the request" plus Client Authentication, Smart Card Logon, PKINIT or Any Purpose EKU, enrollable by Domain Users. Often created for a one-off need and never locked down.
Certipy (req to request with a chosen -upn/-sid, auth to PKINIT), Certify, Rubeus for the ticket side.
# Request naming another principal, then authenticate
certipy req -template VulnTemplate -upn administrator@corp.example -ca CORP-CA ...
certipy auth -pfx administrator.pfx -dc-ip 10.0.0.1CA events Verify: 4886 (request) and 4887 (issue) where the subject doesn't match the requester; a certificate logon (4768 with certificate fields) for the impersonated account; under Full Enforcement, Domain Controller (DC) Verify: event 41 (SID mismatch) when the SAN SID fights the extension.
"Any domain user can obtain a domain-admin logon certificate." Critical when it reaches Tier 0 and the CA doesn't enforce an overriding SID. Severity drops to high/medium where Full Enforcement defeats the impersonation but the template still misissues. Retest: enrollee-supplied subject removed, or EKU and enroll rights tightened.
ESC2: Any Purpose (or no Enhanced Key Usage (EKU)) templateATT&CKT1649 Steal or Forge Authentication Certificates
A template issues certificates with the Any Purpose EKU or no EKU at all, so the certificate is valid for anything, including client authentication and acting as an enrollment agent. The attacker uses it to authenticate, or to request certificates on behalf of others.
Risk: An enrollable Any-Purpose or no-EKU template without manager approval or authorized signatures.
Templates built as a "flexible" catch-all. Because the certificate can act as an enrollment agent, Risk: it chains into on-behalf-of requests against authentication templates (see ESC3).
Certipy (req, then req ... -on-behalf-of), Certify.
certipy req -template AnyPurposeCert -ca CORP-CA ...
certipy req -template User -on-behalf-of 'CORP\Administrator' -pfx attacker.pfx ...4886/4887 for an Any-Purpose template, then Verify: a second issuance where the requester and subject differ (the on-behalf-of step). Enrollment-agent use shows in the request's application policies.
"An over-permissive template issues all-purpose certificates usable to impersonate others." High to critical depending on what it can reach. Retest: the template carries only the specific EKUs it needs.
ESC3: enrollment agent templateATT&CKT1649 Steal or Forge Authentication Certificates
A template grants the Certificate Request Agent Enhanced Key Usage (EKU), which lets its holder enroll on behalf of other users. The attacker gets an agent certificate, then requests an authentication certificate as a privileged user.
Risk: An enrollable template with the Certificate Request Agent EKU, plus a target authentication template that permits enrollment-agent requests and names the victim as enrollable.
Enrollment-agent delegation set up for a legitimate purpose (smart-card issuance desks) but Risk: left enrollable by too many people, or without restricting which users and templates an agent may act for.
Certipy (req for the agent cert, then req ... -on-behalf-of), Certify.
certipy req -template EnrollAgent -ca CORP-CA ...
certipy req -template User -on-behalf-of 'CORP\Administrator' -pfx agent.pfx ...Issuance of a Certificate Request Agent certificate, then Verify: an on-behalf-of request (4886/4887) for a privileged user. The agent's signature on the second request is the tell.
"Enrollment-agent rights allow issuing logon certificates for any user." Critical when the agent can act for Tier 0. Retest: enroll rights on the agent template restricted, and Fix: Enrollment Agent Restrictions configured on the Certificate Authority (CA) to limit which users and templates agents may serve.
ESC4: writable template (template hijack)ATT&CKT1649 Steal or Forge Authentication Certificates · T1222 Permissions Modification
A low-privileged principal holds write access over a template object (FullControl, WriteDacl, WriteOwner, or write to key properties). They rewrite the template into an ESC1 state, enroll, then optionally revert it.
Risk: A write Access Control Entry (ACE) on a published template held directly or through group membership.
Templates whose Access Control Lists (ACLs) grant write to broad groups or stale admins; Risk: leftover delegations from migrations and Public Key Infrastructure (PKI) handoffs. This is the Active Directory Certificate Services (AD CS) instance of the ACL-edge problem from the attack-paths note.
Certipy (template to read/modify/restore, saving a JavaScript Object Notation (JSON) backup), BloodHound (to find the write edge), PowerView.
certipy template -template SecureFiles -save-configuration backup.json # back up first
certipy template -template SecureFiles -write-default-configuration # weaken
# ... enroll as in ESC1 ...
certipy template -template SecureFiles -configuration backup.json # restoreVerify: 5136 directory-change events on the template object (the Discretionary Access Control List (DACL) or the enrollee-supplied-subject/Enhanced Key Usage (EKU) attributes), ideally paired with a matching 4886/4887. A weaken-then-revert pattern is especially telling.
"A non-administrator can rewrite a certificate template into a privilege-escalation path." Critical, because it's self-service ESC1. Retest: template ACLs restricted to PKI admins and the change alerting in place.
Using the certificate: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), Ticket Granting Ticket (TGT), and UnPAC-the-hashATT&CKT1649 Steal or Forge Authentication Certificates · T1558 Steal or Forge Kerberos Tickets
Whatever Escalation (ESC) produced the certificate, the payoff is the same: PKINIT exchanges the certificate for a Kerberos TGT as the mapped account. The same exchange can yield the account's NT LAN Manager (NTLM) hash (UnPAC-the-hash), a reusable credential.
A certificate with an authentication Enhanced Key Usage (EKU) that Risk: maps to the target account under the Domain Controller (DC)'s current mapping rules, and reach to the Key Distribution Center (KDC).
Any domain where PKINIT is available (the default). Schannel paths (LDAPS) are an alternative where PKINIT is blocked.
Certipy (auth), Rubeus (asktgt /getcredentials), Kekeo.
certipy auth -pfx administrator.pfx -dc-ip 10.0.0.1 # PKINIT; can also recover the NT hashVerify: 4768 Kerberos TGT request with certificate information populated (pre-authentication type 16, PKINIT), from an unusual host or for an account that doesn't normally use smart cards.
This is the impact half of every certificate finding: a usable TGT and often a password hash for the target. It is why a template misconfiguration is rated on the account it can reach, not on the certificate itself.
How template findings chain
- Enumerate: list published templates and their enroll rights; flag ESC1–ESC4 conditions and the Certificate Authority (CA)'s enforcement state.
- Pick the live one: a template that is published, enrollable by a broad group, and Risk: reaches a privileged account.
- Obtain the certificate: supply a Subject Alternative Name (SAN) (ESC1), use an all-purpose or agent cert on behalf of a victim (ESC2/ESC3), or rewrite a template you can write (ESC4).
- Cash it in: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) for a Ticket Granting Ticket (TGT), and optionally UnPAC-the-hash for the New Technology (NT) hash.
- Report by root cause and reach: the finding is the template setting; the severity is the account it reaches and whether enforcement defeats it.
Defender's playbook
DefenderThe strategy: find the templates untrusted users can enroll in, Fix: remove enrollee-supplied subject and scope Enhanced Key Usages (EKUs) and enroll rights, lock template Access Control Lists (ACLs), restrict enrollment agents, treat the Certificate Authority (CA) as Tier 0, and alert on the few issuance and change events that signal abuse.
Quick wins (days)
- Enumerate your own templates and triage the flagged ones. Run it the way an attacker would, as an ordinary user.
certipy find -u svc_audit@corp.example -p '***' -dc-ip 10.0.0.1 -vulnerable -stdout - Remove enrollee-supplied subject from any authentication template. The subject should be built from Active Directory (AD). Fix: This is the single highest-value fix (kills ESC1).
# In the Certificate Templates console: Subject Name tab → # select "Build from this Active Directory information" (not "Supply in the request") - Scope enroll rights. Remove Enroll/AutoEnroll for Domain Users, Authenticated Users and Everyone on sensitive templates; grant it to a specific group. Verify: Re-check with
certipy find. - Constrain EKUs. Replace Any Purpose or no-EKU with the specific EKUs the template needs (kills ESC2).
- Lock template ACLs so only Public Key Infrastructure (PKI) admins hold write (FullControl, WriteDacl, WriteOwner, WriteProperty). Fix: This closes ESC4.
- Restrict enrollment agents. On the CA, configure Fix: Enrollment Agent Restrictions (which agents, for which users and templates) and tighten enroll rights on agent templates (kills ESC3).
- Turn on stopgaps where redesign is slow: Fix: manager approval on a sensitive template puts a human in the loop until it's fixed.
Longer-term fixes (weeks to months)
- Treat the enterprise CA as Tier 0: restrict local admin and the ManageCA/ManageCertificates roles, put it on a protected management path, and Fix: monitor it like a domain controller.
- Confirm strong-mapping enforcement is in place (it is the default since Feb 2025) and that your own apps still authenticate; remediate any that relied on weak mappings by issuing SID-bearing certificates or adding strong
altSecurityIdentities. - Inventory and justify every published template; unpublish the ones no one uses. Fewer templates, fewer surprises.
- Separate duties but review jointly: a standing AD-plus-PKI review of template changes, because Risk: a template setting is a privilege grant.
- Enable CA and Domain Controller (DC) auditing end to end (issuance and certificate-mapping events) and feed them to the Security Information and Event Management (SIEM).
- Adopt continuous checking: schedule
certipy findor a BloodHound collection and Verify: alert when a new Escalation (ESC) condition appears, the same attack-path-management loop from the attack-paths note.
Detection signals
| Signal | Source | Alert on |
|---|---|---|
| 4886 / 4887: certificate requested / issued | CA Security log (CA auditing on) | Verify: Issued subject (SAN) differs from the requesting account, the ESC1 and on-behalf-of signature |
| 4887 with an enrollment-agent co-signature | CA Security log | On-behalf-of requests for privileged users from a new or unexpected agent |
| 4898 / 4899 / 4900: template loaded / updated | CA Security log | Template EKU, name-flag or ACL changes outside a change window (ESC4) |
| 5136: directory object modified on a template | DC Security log (directory-change auditing + System Access Control Lists (SACLs)) | Changes to a template's Discretionary Access Control List (DACL), pKIExtendedKeyUsage, or msPKI-Certificate-Name-Flag |
| 4768 Kerberos Ticket Granting Ticket (TGT) request with certificate info | DC Security log | Verify: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) logon (pre-auth type 16) for an account that doesn't use smart cards, or from an unusual host |
| DC events 39 / 41 | DC System log (Kdcsvc) | Verify: 39 no strong mapping / no usable Security Identifier (SID); 41 SID mismatch, which can mean someone is probing ESC1 under enforcement |
| Microsoft Defender for Identity (MDI) Active Directory Certificate Services (AD CS) alerts | Microsoft Defender for Identity | Suspicious certificate enrollment and use; several ESC techniques have built-in analytics |
Verify the fix worked
- Re-run Verify:
certipy find -vulnerable(and the BloodHound collection); confirm the template no longer flags ESC1–ESC4. - As a standard user, attempt an enrollee-supplied-subject request and Verify: confirm it is refused or the subject is built from AD.
- Confirm the Enroll Access Control Entry (ACE) is now a small group, EKUs are scoped, and the template ACL grants write only to PKI admins.
- Confirm Enrollment Agent Restrictions are configured and that an agent request for an out-of-scope user fails.
- Confirm the CA and DC events above are being collected, and that a test misissue Verify: raises the 4887-subject-mismatch alert.
Why remediation stalls, and workable compromises
| Objection | Workable compromise |
|---|---|
| "That template is used for Virtual Private Network (VPN)/Wi-Fi; we can't touch it." | Keep the EKU and use; just Fix: remove enrollee-supplied subject so the name comes from AD. If a custom subject is truly needed, scope enroll and add manager approval. |
| "We need enrollment agents for the smart-card desk." | Keep them, but Fix: configure Enrollment Agent Restrictions and restrict enroll on the agent template to that team. |
| "We're on Full Enforcement, isn't that enough?" | It blunts ESC1 mapping only. Risk: Fix ESC3/ESC4 and relay too, and watch for mapping-defeat (Part 3). |
| "The PKI team is separate and busy." | Make it a joint, time-boxed review of only the flagged templates; that's usually a handful, not the whole PKI. |
| "We can't rotate the CA key; too disruptive." | You rarely need to for template fixes. Key rotation is for suspected CA-key compromise (Part 2), not routine hardening. |
| "Auditing is too noisy." | Start with just 4887 subject-mismatch and 5136 on template objects; both are low-volume and high-signal. |
Executive brief
ExecutiveThe risk in plain language
We run a certificate service, the system behind our Wi-Fi, Virtual Private Network (VPN) and smart cards. It works like a badge printer. The danger is that one of its "forms," a certificate template, can be set up to let ordinary staff Risk: print a badge with someone else's name and access level, including an administrator's. The door, our network, reads the badge, not the person. An attacker who gets into any normal account can use this to Risk: become a full administrator, without breaking a password.
Business impact
- A path from a single phished or low-level account to Risk: full control of the Windows environment, which is the setup for ransomware and large-scale data theft.
- The forged credential is a certificate, so Risk: it keeps working even after we reset passwords, making an incident far harder and more expensive to clean up.
- Our certificate service turns out to be as sensitive as the servers that run logon, Risk: but it's often managed with less care.
What drives likelihood
- Old, loosely configured templates that let staff choose the identity on their certificate.
- Broad permissions that let Risk: ordinary users request from, or even edit, sensitive templates.
- Split ownership: the certificate team and the Active Directory team are separate, so Risk: no one reviews these templates together.
- No monitoring of what certificates get issued, so misuse looks like business as usual.
Cost of inaction
The fixes are configuration changes, not purchases: tighten a handful of templates, lock their permissions, and watch for changes. Leaving them in place means any successful phishing email is Risk: a short, quiet step from company-wide compromise, through a system most organizations don't watch. And because certificates outlive passwords, the cleanup after a real incident can mean Risk: rebuilding part of the certificate system.
What good looks like
- Certificate templates issue identities Fix: built from our directory, never typed by the requester.
- Only a Fix: small, named group can request from, or change, sensitive templates.
- The certificate service is Fix: protected and monitored like a domain controller.
- We're Verify: alerted when a certificate is issued for someone other than the requester, or when a template changes.
- The certificate and Active Directory teams Fix: review these settings together.
Questions executives ask
We have a certificate server for Wi-Fi and Virtual Private Network (VPN). Why is that a domain-admin risk?
"Because the same server that issues Wi-Fi certificates can, if one template is misconfigured, issue a certificate that logs in as an administrator. A certificate is an identity, not just an encryption key. We treat that server as one of the crown jewels, the same tier as the domain controllers."
Is this a vulnerability we need to patch, or a configuration problem?
"Mostly configuration. A handful of certificate templates were set up too loosely, often years ago. Fix: Fixing them is a settings change, not a product purchase, and we can verify it. A few related items are genuine patches, which we'll list, but the core fix is tightening templates."
Didn't Microsoft fix the 'name yourself an admin' trick already?
"They added a strong check in 2022, and it's been mandatory since early 2025, which blunts the simplest version. But attackers have found ways around it, and plenty of certificate servers still issue the risky certificates for other reasons. The hardening helps; it doesn't close the topic, so the templates still need fixing."
If an attacker gets one of these certificates, what can we do?
"That's the uncomfortable part. Risk: A certificate keeps working even after we reset passwords, because it isn't a password. Containing a certificate incident means revoking certificates and, in the worst case, rebuilding part of the certificate system. That's why preventing the misconfiguration is far cheaper than responding to it."
How exposed are we right now?
"We can measure it this week. Free tooling reads the certificate templates and flags the dangerous ones and who can use them. Verify: We'll report how many risky templates exist and whether ordinary staff can reach them, then re-measure after the fixes."
Who should own fixing this?
"The team that runs the certificate service, working with the Active Directory team. Those two are often separate, which is exactly why these templates go unreviewed. The ask is a joint review and a standing check when templates change."
Presenting this finding to leadership
- Headline: "A misconfigured certificate template let an ordinary account issue itself an administrator credential, Risk: with no password cracked."
- Make it concrete: name the template and what it reached; show the issued certificate and the administrator logon.
- Set the fix in proportion: a settings change on a few templates, plus treating the certificate server as a crown jewel.
- The ask: a joint certificate/Active Directory (AD) review, the template fixes, monitoring of issuance, and a standing check when templates change.
Talk the talk
Jargon decoder
Microsoft's in-house certificate authority, built into Active Directory.
"The AD CS server is Tier 0; let's confirm who administers it."
The blueprint that fixes what a certificate can do and who can request it.
"Which templates allow enrollee-supplied subject? Those are the ESC1 candidates."
The list of purposes a certificate is valid for, such as client authentication.
"This template's EKU includes Smart Card Logon, so the cert can be used to log on."
A template setting that lets the requester choose the identity in the certificate.
"Supply-in-the-request plus an auth Enhanced Key Usage (EKU) is the textbook ESC1."
The certificate field that holds the identity authentication actually reads.
"The SAN said administrator@corp, but the requester was a help-desk account."
The Kerberos extension that trades a certificate for a ticket.
"We ran PKINIT with the minted cert and got a Ticket Granting Ticket (TGT) as the Domain Admin (DA)."
An extension the Certificate Authority (CA) stamps into a certificate carrying the requester's SID, checked by strong mapping.
"The SID extension pins the cert to the requester, so Subject Alternative Name (SAN) spoofing maps back to us."
Tying a certificate to an account by something unforgeable (Security Identifier (SID), issuer+serial, key), not by name.
"Under Full Enforcement, weak name-based mappings are rejected."
A certificate that lets its holder request certificates on behalf of other users.
"The smart-card desk uses an enrollment agent; make sure its template isn't broadly enrollable."
A template setting that holds a request for human approval before issuance.
"Turn on manager approval for the sensitive template as a stopgap."
A forged certificate made with the stolen Certificate Authority (CA) private key; covered in Part 2.
"If the CA key leaked, we're looking at golden-certificate persistence."
Recovering an account's NT LAN Manager (NTLM) hash from the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) exchange.
"We UnPAC'd the hash from the cert, so now we have a reusable credential too."
A community number for an Active Directory Certificate Services (AD CS) escalation technique (ESC1, ESC8, and so on).
"Certipy flagged ESC1 and ESC4 on two templates."
The standard open-source tool for enumerating and abusing Active Directory Certificate Services (AD CS).
"Certipy find with the vulnerable flag is our first pass."
Smart questions to ask
Sysadmins
- Which published templates allow "Supply in the request", and do they carry an authentication Enhanced Key Usage (EKU)?
- Who holds Enroll and AutoEnroll on those templates, Risk: is it Domain Users or Authenticated Users?
- Who can write to the template objects (FullControl, WriteDacl, WriteOwner)?
- Are Fix: Enrollment Agent Restrictions configured on the Certificate Authority (CA), and who can enroll in agent templates?
- Is the enterprise CA Fix: managed as Tier 0, and who holds ManageCA/ManageCertificates?
- Do you audit issuance (4887) and Verify: alert when the subject doesn't match the requester?
Executives
- Do we treat our certificate service with the same care as our most critical servers?
- Do the certificate team and the Active Directory team review these settings together?
- If a certificate were misused, could we detect and revoke it?
Coworkers
- Is the CA on Full Enforcement, and does it add the Security Identifier (SID) extension, so is classic ESC1 actually exploitable here?
- Did we validate the certificate path with Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), Verify: or just trust the graph?
- Which EKU and schema version does the template have, so which abuses are even possible?
Say this, not that
"The certificate server gives out encryption keys."
"The certificate server issues identities; a bad template issues an identity you can log in as."
"BloodHound says ESC1, so it's domain admin."
"It's ESC1, but the Certificate Authority (CA) enforces strong mapping, so we validated whether impersonation actually works before rating it."
"Just revoke the password to contain it."
"Passwords don't help; we have to revoke the certificate, and maybe rotate the Certificate Authority (CA) key."
"Any purpose Enhanced Key Usage (EKU) is convenient."
"Any Purpose means the cert also works as an enrollment agent and a logon credential; scope the EKU."
"We enabled enrollment agents, that's fine."
"Enrollment agents are fine with Enrollment Agent Restrictions and tight enroll rights; without them it's ESC3."
"Microsoft's 2025 enforcement fixed Active Directory Certificate Services (AD CS) attacks."
"Enforcement blunts classic ESC1 mapping, but ESC3, ESC4, relay and the mapping-defeat Escalations (ESCs) still work; fix the templates."
"The Public Key Infrastructure (PKI) team handles certificates, not us."
"The PKI and Active Directory (AD) teams need a joint review, because a template setting is an AD privilege decision."
Same point, two audiences
"A certificate is a form of ID badge. The certificate server can, if misconfigured, print a badge that opens the top-floor door."
"A template with an authentication Enhanced Key Usage (EKU) issues a cert that works for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), so it's a Kerberos credential, not just a Transport Layer Security (TLS) key."
"Microsoft added a strong identity check that's now mandatory. It helps, but attackers work around it, so the templates still need fixing."
"Full Enforcement of StrongCertificateBindingEnforcement has been default since Feb 2025, so the Domain Controller (DC) maps by the Security Identifier (SID) extension; classic ESC1 now needs ESC9/ESC16 to strip that extension."
"Unlike a password, a stolen certificate keeps working until it expires or we revoke it, sometimes forcing a rebuild of the certificate system."
"Resets don't revoke certs. You need Certificate Revocation List (CRL)/Online Certificate Status Protocol (OCSP) revocation, and if the Certificate Authority (CA) key is compromised, krbtgt-style rotation won't help; you rotate the CA key or rebuild."
"The certificate server deserves the same protection as the servers that run logon, because it can create logons."
"Put the enterprise CA in Tier 0: restrict local admin and ManageCA, monitor issuance, and keep it off general-purpose management paths."
Keep going
What's next in this series
- Part 2: Certificate Authority (CA) configuration, access control, and relay. ESC5 (Access Control Lists (ACLs) on Public Key Infrastructure (PKI) objects), ESC6 (the
EDITF_ATTRIBUTESUBJECTALTNAME2flag that lets anyone add a Subject Alternative Name (SAN)), ESC7 (ManageCA/ManageCertificates abuse), ESC8 and ESC11 (relaying authentication into web enrollment and the Remote Procedure Call (RPC) interface), plus certificate theft and golden-certificate persistence. Say "continue" to build it. - Part 3: Defeating the mapping, and the newer escalations. ESC9, ESC10, ESC13, ESC14, ESC15/EKUwu (Common Vulnerabilities and Exposures (CVE) entry CVE-2024-49019) and ESC16, which strip or dodge the Security Identifier (SID) extension to bring ESC1 back, ESC17, and the full hardening and remediation program.
Related notes
- Active Directory attack paths, thinking in graphs. Active Directory Certificate Services (AD CS) edges (
ADCSESC1and friends) are the short arrows in that graph; this series is the detail behind them. - The Kerberos series. Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), the Ticket Granting Ticket (TGT) and UnPAC-the-hash connect directly to Kerberos Parts 1–3.
Resources worth seeking out
- "Certified Pre-Owned" (SpecterOps, 2021) by Will Schroeder and Lee Christensen, the foundational whitepaper that named the first Escalations (ESCs).
- The Certipy wiki (ly4k/Certipy), which documents each ESC's conditions and the tool's enumeration and abuse commands.
- Microsoft's KB5014754, the authoritative reference on certificate-based authentication changes and strong mapping.
- Locksmith and PSPKIAudit, for defensive enumeration and remediation of AD CS.
- A practice lab: a deliberately vulnerable AD CS range (several open-source labs include ESC templates) so you can enumerate, exploit and remediate Verify: where you're authorized to break things.
AD CS abuse, Part 1: templates and the escalation primitives
Acronyms
Every acronym used on this page. Four test modes are below the table.
| Acronym | Expansion | Plain English | Why it matters |
|---|---|---|---|
| ACE | Access Control Entry | A single permission in an Access Control List (ACL): a principal, a right, and allow or deny. | The enroll right and the write rights that enable ESC4 are individual Access Control Entrys (ACEs) on the template object. |
| ACL | Access Control List | The permissions attached to an object saying who can do what to it. | Weak Access Control Lists (ACLs) on a template let a low-privileged user rewrite it into a vulnerable state, which is ESC4. |
| AD | Active Directory | Microsoft's on-premises directory service for users, computers, groups and their permissions. | Certificate templates, the Certificate Authority (CA)'s objects and enrollment rights all live as Active Directory (AD) objects, readable by ordinary users. |
| AD CS | Active Directory Certificate Services | Microsoft's certificate authority role, integrated with Active Directory, that issues and manages digital certificates. | The whole series is about abusing how it issues certificates; a misconfigured template here is often the shortest path to domain admin. |
| AIACA | Authority Information Access Certification Authority | A BloodHound node type for a Certificate Authority (CA) referenced by Authority Information Access data. | Part of how the graph models the Active Directory Certificate Services (AD CS) trust chain. |
| ATT&CK | Adversarial Tactics, Techniques, and Common Knowledge | MITRE's public catalogue of attacker techniques. | Gives findings a shared vocabulary; T1649 is the technique for stealing or forging authentication certificates. |
| CA | Certificate Authority | A server that issues digital certificates and vouches for the identity in them by signing them. | An enterprise Certificate Authority (CA) the domain trusts for logon can mint credentials for anyone, which is why it is a Tier 0 asset. |
| CE | Community Edition | The free, open-source edition of BloodHound. | What most testers and defenders run to visualise Active Directory Certificate Services (AD CS) edges. |
| CEO | Chief Executive Officer | The most senior executive of an organization. | Used in the badge analogy for the highest-access identity an attacker forges. |
| CEP | Certificate Enrollment Policy Web Service | An Active Directory Certificate Services (AD CS) web role that tells clients which templates and Certificate Authoritys (CAs) are available. | Part of the HTTP enrollment surface; named here for completeness with Certificate Enrollment Web Service (CES). |
| CES | Certificate Enrollment Web Service | An Active Directory Certificate Services (AD CS) web role that lets clients request certificates over HTTP. | Along with the Web Enrollment role, it is the HTTP front end abused by relay attacks (ESC8) in Part 2. |
| CFO | Chief Financial Officer | The executive responsible for finances. | Often in a readout, asking the cost-and-cleanup questions. |
| CIO | Chief Information Officer | The executive responsible for Information Technology (IT). | Usually asks whether the 2025 Microsoft change already solved the problem. |
| CISO | Chief Information Security Officer | The executive responsible for an organization's security program. | The usual audience for a readout explaining why a certificate server is as sensitive as a domain controller. |
| CRL | Certificate Revocation List | A published list of certificates the Certificate Authority (CA) has revoked before their expiry. | Revocation is the main way to cancel a stolen or misissued certificate, but clients must actually check it. |
| CSR | Certificate Signing Request | The request a client sends to a Certificate Authority (CA), containing the public key and the desired subject, to be signed into a certificate. | Enrollee-supplied-subject attacks work by putting an attacker-chosen identity into the Certificate Signing Request (CSR). |
| CVE | Common Vulnerabilities and Exposures | A public catalogue of disclosed security vulnerabilities, each with an identifier. | Common Vulnerabilities and Exposures (CVE) entry CVE-2022-26923 (certifried) and CVE-2024-49019 (EKUwu) are the Active Directory Certificate Services (AD CS) vulnerabilities behind the mapping changes and ESC15. |
| DA | Domain Admin | A member of the Domain Admins group, with full control of a domain. | The usual target account an Escalation (ESC) certificate is minted for. |
| DACL | Discretionary Access Control List | The part of an object security descriptor that grants or denies access. | Write access to a template Discretionary Access Control List (DACL) is the ESC4 condition; it lets an attacker grant themselves enroll and rewrite the template. |
| DC | Domain Controller | A server that holds the Active Directory (AD) database and authenticates logons; it runs the Key Distribution Center (KDC). | The Domain Controller (DC) enforces certificate mapping and strong-binding rules; impersonating a DC's own account is a common endgame. |
| DNS | Domain Name System | The system that resolves names to addresses; also the name form used to identify computer accounts. | Machine certificates map by a Domain Name System (DNS) name in the Subject Alternative Name (SAN), which matters for impersonating computers (including Domain Controllers (DCs)). |
| EDR | Endpoint Detection and Response | Security software on each host that records activity and can block or respond to threats. | It may catch enumeration tools and private-key theft, though a certificate request itself can look routine. |
| EKU | Enhanced Key Usage | A field in a certificate listing what the certificate is allowed to be used for, as a set of object identifiers. | An authentication Enhanced Key Usage (EKU) is what turns a certificate into a logon credential; the wrong EKU on an enrollable template is the core of several Escalations (ESCs). |
| ESC | Escalation | The community scheme numbering Active Directory Certificate Services (AD CS) escalation techniques (ESC1, ESC2, and so on). | Shared shorthand for a specific certificate misconfiguration; the numbering is informal and varies by source. |
| GPO | Group Policy Object | A bundle of settings Active Directory (AD) pushes to users and computers. | The root Certificate Authority (CA)'s certificate is distributed to clients' trust stores by Group Policy Object (GPO), which is what makes CA-issued certificates trusted. |
| GUI | Graphical User Interface | The visual, point-and-click part of a tool, such as the Certificate Templates console. | Admins configure templates in a Graphical User Interface (GUI) where the dangerous flags are a single checkbox, which is how misconfigurations happen. |
| HR | Human Resources | The function that manages employee records. | Used in the badge analogy: the certificate normally takes your identity from an authoritative source, like Human Resources (HR). |
| IIS | Internet Information Services | Microsoft web server, used by the Active Directory Certificate Services (AD CS) web-enrollment roles. | A Schannel certificate-auth endpoint and the front end abused by ESC8 relay in Part 2. |
| IR | Incident Response | The practice of investigating and containing a security incident. | Certificate Incident Response (IR) must revoke issued certificates, not just reset passwords, because certs survive resets. |
| IT | Information Technology | The function that runs an organization's computers and networks. | The Public Key Infrastructure (PKI) team is often separate from the Active Directory (AD) team, which is why dangerous templates go unreviewed. |
| JSON | JavaScript Object Notation | A plain-text data format of keys and values. | Certipy saves a template backup as JavaScript Object Notation (JSON) before an ESC4 change, so it can be restored. |
| KDC | Key Distribution Center | The Kerberos service on a domain controller that issues tickets. | The Key Distribution Center (KDC) is what validates the certificate and decides which account it maps to during Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). |
| LAN | Local Area Network | A network within one site or building. | Appears inside NT LAN Manager (NTLM); listed so the expansion is complete. |
| LDAP | Lightweight Directory Access Protocol | The protocol used to read and write Active Directory (AD) objects. | Template and Certificate Authority (CA) settings are read over Lightweight Directory Access Protocol (LDAP) by any domain user, which is how enumeration finds vulnerable templates. |
| LDAPS | LDAP over SSL | Lightweight Directory Access Protocol (LDAP) wrapped in Transport Layer Security (TLS), which can authenticate clients by certificate through Schannel. | A target for certificate authentication outside Kerberos, and a relay destination in later parts. |
| LSASS | Local Security Authority Subsystem Service | The Windows process that handles logons and holds credential material in memory. | Private keys and tickets can be lifted from it, which is the theft angle in Part 2. |
| MDI | Microsoft Defender for Identity | Microsoft's sensor-based detection product for on-premises Active Directory (AD) and Active Directory Certificate Services (AD CS). | It ships Active Directory Certificate Services (AD CS) sensors and detections for several Escalation (ESC) techniques and for suspicious certificate use. |
| MDM | Mobile Device Management | A system that manages and configures devices, often issuing them certificates. | MDM-issued certificates had to be reworked to include the Security Identifier (SID) so they would still authenticate after enforcement. |
| NDES | Network Device Enrollment Service | The Active Directory Certificate Services (AD CS) role implementing Simple Certificate Enrollment Protocol (SCEP) so network devices can enroll for certificates. | An extra enrollment surface that widens the attack surface, especially for devices and Mobile Device Management (MDM). |
| NT | New Technology | The Windows New Technology (NT) family name, carried in terms like NT LAN Manager (NTLM). | Appears inside NT LAN Manager (NTLM); listed so the expansion is complete. |
| NTLM | NT LAN Manager | Microsoft's older challenge-response authentication protocol. | Certificate authentication is often promoted as a way to move away from NT LAN Manager (NTLM); relay of NTLM into Active Directory Certificate Services (AD CS) is the ESC8 attack in Part 2. |
| OCSP | Online Certificate Status Protocol | A protocol for checking in real time whether a certificate is revoked. | With a Certificate Revocation List (CRL), the way to cancel a misissued or stolen certificate; only effective if clients check it. |
| OID | Object Identifier | A globally unique dotted-number name, such as 1.3.6.1.5.5.7.3.2, used to label things like Enhanced Key Usages (EKUs) and policies. | Enhanced Key Usages (EKUs), application policies and the Security Identifier (SID) extension are all identified by Object Identifier (OID); recognising the key ones is essential. |
| PAC | Privilege Attribute Certificate | The structure inside a Kerberos ticket carrying the account groups and Security Identifier (SID). | UnPAC-the-hash pulls the NT LAN Manager (NTLM) hash from the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) reply, turning a certificate into a reusable credential. |
| PFX | Personal Information Exchange | A file format (Public Key Cryptography Standards (PKCS)#12) holding a certificate together with its private key, often password-protected. | A stolen or minted .pfx is the portable credential an attacker carries off and replays with Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). |
| PIN | Personal Identification Number | A short secret that unlocks a smart card or key. | Proving card possession with a Personal Identification Number (PIN) is the normal use the attacks subvert. |
| PKCS | Public Key Cryptography Standards | A family of public-key standards; Public Key Cryptography Standards (PKCS)#12 is the certificate-plus-key (.pfx) file format. | Names the .pfx container an attacker carries off and replays. |
| PKI | Public Key Infrastructure | The system of Certificate Authoritys (CAs), certificates, keys and policies that lets parties trust each other's public keys. | Active Directory Certificate Services (AD CS) is Microsoft's Public Key Infrastructure (PKI); understanding the pieces is what makes the Escalation (ESC) attacks make sense. |
| PKINIT | Public Key Cryptography for Initial Authentication in Kerberos | The Kerberos extension that lets a client get a ticket using a certificate instead of a password. | It is how a certificate becomes a Kerberos Ticket Granting Ticket; nearly every Active Directory Certificate Services (AD CS) attack ends here. |
| RFC822 | Request for Comments 822 (email address format) | The email-address name form; here, a weak, name-based certificate mapping type. | An Request for Comments 822 (email address format) (RFC822) (email) explicit mapping is weak and rejected under Full Enforcement. |
| RPC | Remote Procedure Call | A mechanism for one computer to call a function on another. | The ICertPassage Remote Procedure Call (RPC) interface is a relay target (ESC11) and a certificate-request path. |
| SACL | System Access Control List | The part of a security descriptor that decides which access attempts get audited. | Directory-change detection on templates (event 5136) only fires where a System Access Control List (SACL) requests it. |
| SAN | Subject Alternative Name | A certificate field holding the identities the certificate is valid for, such as a User Principal Name (UPN) or Domain Name System (DNS) name. | If a requester can supply the Subject Alternative Name (SAN) on an authentication template, they can name someone else, which is ESC1. |
| SCEP | Simple Certificate Enrollment Protocol | A protocol for devices to request certificates, often used by Mobile Device Management (MDM). | SCEP-issued certificates were a focus of the strong-mapping enforcement because they often lacked the Security Identifier (SID) extension. |
| SChannel | Secure Channel | Windows' implementation of Transport Layer Security (TLS)/SSL, used for certificate-based authentication to services like LDAP over SSL (LDAPS) and web servers. | The non-Kerberos path for authenticating with a certificate; Active Directory Certificate Services (AD CS) attacks can target it as well as Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). |
| SHA1 | Secure Hash Algorithm 1 | A 160-bit cryptographic hash; here, the public-key hash used for a strong certificate mapping. | Public-key (SHA1) is one of the strong altSecurityIdentities mapping types. |
| SID | Security Identifier | The unique, permanent identifier Windows assigns to every account. | Since 2022 the Certificate Authority (CA) embeds the requester's Security Identifier (SID) in a certificate extension, and strong mapping checks it, which reshapes whether ESC1 still works. |
| SIEM | Security Information and Event Management | The platform that collects logs centrally and runs correlation and alerting. | Where Certificate Authority (CA) issuance events (4886/4887) and Domain Controller (DC) mapping events (39/41) are correlated into detections. |
| SKI | Subject Key Identifier | A certificate field holding a hash of the public key, usable as a strong, unforgeable mapping. | One of the strong explicit mappings that survive Full Enforcement. |
| SOC | Security Operations Center | The team that monitors alerts and responds to incidents. | Needs to know which issuance and mapping events (4887, 39/41) deserve a page. |
| TGT | Ticket Granting Ticket | The Kerberos ticket that proves who you are and is used to request access to services. | A certificate attack's payoff is usually a Ticket Granting Ticket (TGT) for a privileged account, obtained via Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). |
| TLS | Transport Layer Security | The protocol that encrypts and authenticates network connections. | Certificate authentication over Schannel rides on Transport Layer Security (TLS) client certificates; server-auth certificate abuse (ESC17) is a TLS-spoofing problem. |
| UPN | User Principal Name | A user's logon name in email form, such as jdoe@corp.example. | A User Principal Name (UPN) in a certificate's Subject Alternative Name (SAN) is how Active Directory (AD) implicitly maps the certificate to a user account. |
| VPN | Virtual Private Network | An encrypted tunnel into a private network, often authenticated by certificate. | A common legitimate reason a risky template exists, which is why admins resist changing it. |
Test yourself
Flashcards
Quiz
Fifteen questions, mostly scenarios. Feedback appears as soon as you choose.
Conversation drills
Say or type your answer first, then compare with the sample.
Export cards
Basic cards (Quizlet and Anki Basic)
Anki cloze cards
My private notebook
Personal notes and bookmarks are private. Unsaved text is temporarily kept in this tab’s browser storage to recover supported sign-in redirects and reloads. Closing the tab may lose unsaved text.
Checking sign-in…