# Certified Pre-Owned: AD CS and Active Directory's Second Trust Root
> AD CS ESC1-ESC16: how Microsoft shipped Certificate Services in 2000, what SpecterOps named in 2021, and why the catalog grows faster than the patches.
*Published: 2026-05-25*
*Canonical: https://paragmali.com/blog/certified-pre-owned-ad-cs-and-active-directorys-second-trust*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
**Microsoft Certificate Services shipped in Windows 2000 Server on February 17, 2000 and was renamed Active Directory Certificate Services in Windows Server 2008.** Its misconfigurations remained admin-tunable knobs without numbered names for twenty-one years. In June 2021, Will Schroeder and Lee Christensen at SpecterOps published *Certified Pre-Owned* and named eight of them ESC1 through ESC8. Through 2025 the community extended the catalog to ESC16 across IFCR, Compass Security, SpecterOps, TrustedSec, and independent researchers, each one abusing one of six primitives: the template, the issuing authority, the transport, the mapping, the authentication step, or the persistence substrate. Two ESCs have cleanly received CVE-class Microsoft patches (EKUwu / ESC15 -> CVE-2024-49019; ESC8 received KB5005413 *hardening guidance* rather than a CVE, and the adjacent Certifried CVE-2022-26923 patches the dNSHostName impersonation chain on the Machine template rather than a numbered ESC); the rest are administrative hardening matters per Microsoft's Windows Security Servicing Criteria. The KB5014754 strong-mapping rollout closed ESC9 and ESC10 but is bypassed by ESC16. The architectural property -- that every CA in NTAuth is a key parallel to krbtgt that can mint a Domain Admin authenticator -- is not closable by any patch. The operational playbook is to run Locksmith, BloodHound CE, MDI, PSPKIAudit, and Certipy in parallel, ingest CA logs, and prepare a Lane-3 CA rebuild before you need it.
## 1. Two Hours, No KRBTGT, No Touch on Tier Zero
The operator's stopwatch reads two hours and seven minutes when the SOCKS proxy lights up with a Ticket-Granting Ticket for the Domain Administrator account. No service was crashed. No LSASS process was touched. No Tier-Zero principal had its password reset. The [`krbtgt` account hash](/blog/krbtgt-the-account-that-owns-active-directory/) from last quarter's rotation is still good. The certificate that minted the ticket was issued, signed, and logged by the enterprise's own Certificate Authority -- the one the IT director's slide deck calls "internal PKI" -- against a template the help desk uses to enroll Wi-Fi clients.
Walk the chain backwards. The operator joined `Domain Users` four hours ago via a phishing payload that never escalated past medium integrity. They ran one tool. Certipy `find` enumerated every certificate template the foothold account was permitted to enroll in [@certipy-gh]. One of those templates -- call it `WiFi-Auth` -- had three properties: low-privilege enrollment open to `Authenticated Users`, the Client Authentication Extended Key Usage attached, and the `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` bit flipped on. Certipy `req` produced a Certificate Signing Request that supplied `DOMAIN\Administrator` as the Subject Alternative Name. The Enterprise CA, doing exactly what its template configured it to do, issued the certificate. Certipy `auth -pfx` exchanged the certificate for a TGT via the Public Key Cryptography for Initial Authentication extension to Kerberos. Mimikatz `ptt` loaded the TGT into the operator's session. Domain Admin.
What did not fire is the part that frustrates the incident response team. There was no Windows Event 4624 for the Administrator account anywhere on the domain. Microsoft Defender for Identity raised no lateral-movement alert. No Pass-the-Ticket detection triggered, because the ticket was minted as fresh PKINIT authentication, not replayed. The only artifact in the entire chain was a single Event ID 4886 in the CA's issuance log -- the event the SOC's SIEM does not ingest, because the SOC's SIEM was built to follow `krbtgt` and not to follow PKI.
RFC 4556's Public Key Cryptography for Initial Authentication in Kerberos. The protocol extension that lets a Kerberos client present a certificate to a Key Distribution Center and receive a Ticket-Granting Ticket in return. Authored by L. Zhu (Microsoft) and B. Tung (Aerospace), published in June 2006 [@rfc4556]. PKINIT is the authentication step that converts an issued certificate into a TGT, and therefore the step every ESC must cross to convert a misconfigured template into Domain Admin.
The TGT in this scenario is produced by Active Directory's Key Distribution Center after it validates the certificate against its trusted certificate stores. The KDC does not call back to the CA -- it trusts any certificate signed by a CA published into the forest's `NTAuthCertificates` container. That trust relationship is the load-bearing detail; we will return to it in section eight.
So how is any of this possible? The operator's organization rotated krbtgt twice last quarter, runs a top-quartile EDR product, and bought Microsoft Defender for Identity with the AD CS sensor add-on. The simple answer is: rotating krbtgt closes one of the keys that can mint a Domain Admin authenticator in this forest. It does not close the others. The forest has more than one such key, and nobody told the IR plan.
> **Key idea:** Every domain whose CA can issue authentication certificates has two trust roots that can mint a Domain Admin authenticator, not one. The first is the `krbtgt` account hash. The second is the private key of any Certificate Authority published into the forest's `NTAuthCertificates` container. Rotating one does not touch the other. The catalog this article walks through is the community's attempt to enumerate the misconfigurations that turn the second trust root into a path low-privilege users can walk.
The vocabulary for this surface -- the named techniques, the numbered identifiers, the tool that enumerates them in eleven seconds -- did not exist until June 2021. The misconfigurations did. They had been shipping as customer-tunable knobs in Microsoft's identity stack since Windows Server 2003. If this surface has been available for twenty-one years, why did it take twenty-one years for someone to give the misconfigurations names?
## 2. Twenty-One Years of Unnamed Knobs
February 17, 2000. Windows 2000 Server reaches general availability. Microsoft Certificate Services -- the AD-integrated CA role -- ships as an optional server component on day one [@wikipedia-w2k]. The role is *not yet* called Active Directory Certificate Services; that rename arrives with Windows Server 2008. The shipping defaults that the operator in section one just exploited were already buildable on the 2000 release.
The misconfigurations the catalog later attacks did not all arrive at once. Three Microsoft releases between 2000 and 2008 built the surface piece by piece.
Windows Server 2003 (general availability April 24, 2003 [@wikipedia-ws2003]) shipped Version 2 (V2) certificate templates, user and computer autoenrollment over the V2 schema, and the AD-stored template store [@msl-ws2003-ca]. Most of the surface ESC1 and ESC4 later attack first appears in this release: `msPKI-Certificate-Name-Flag`, the `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` bit, per-template DACLs editable in Active Directory Sites and Services, and the modifiable Extended Key Usage list. The Enrollee-Supplies-Subject flag, in particular, is a customer-tunable bit; it ships off by default on the stock templates but is a one-click enable in `certtmpl.msc` [@msl-adcs-2012r2]. Microsoft's documentation warned against it on sensitive templates. It did not warn against it as a numbered identifier.
Certificate templates have version numbers tied to the Active Directory schema. V1 templates ship with Windows 2000 and are non-modifiable from the GUI. V2 templates ship with Windows Server 2003 and are fully modifiable; they introduce the per-template DACL and the editable `msPKI-Certificate-Name-Flag` properties the catalog attacks. V3 templates ship with Windows Server 2008 and add Suite B cryptography support. The catalog mostly attacks V2 templates; ESC15 specifically attacks the residual V1 templates that ship pre-installed and cannot be removed.
Windows Server 2008 (general availability February 27, 2008 [@wikipedia-ws2008]) renamed the role to Active Directory Certificate Services and added new role services: Online Certificate Status Protocol Responder, Network Device Enrollment Service, Certificate Enrollment Web Service, and Certificate Enrollment Policy Web Service. These role services expanded the transport surface that ESC8 and ESC11 later attack. The Windows Server 2012 R2 documentation page `hh831740` became the canonical reference SpecterOps later linked from the 2021 paper [@msl-adcs-2012r2].
Between 2008 and 2021 Microsoft published hardening guidance for AD CS in several places -- Test Lab Guides, PKI design pages, role-service deployment docs [@msl-pki-design]. The guidance covered template ACLs, manager approval, least-privilege enrollment, and the Enrollee-Supplies-Subject bit. It did not assign numbered identifiers to specific dangerous combinations. It did not appear in MSRC's vulnerability pipeline. It did not get a Common Vulnerabilities and Exposures registration. The configurations were *documented but unnamed*.
In 2019, two seeds for the named class appeared. Géraud de Drouas at the French ANSSI published a brief GitHub note that the Active Directory `Public-Information` property set includes `altSecurityIdentities`, which lets an attacker with that permission map their own certificate onto a privileged user [@dedrouas-altsec]. The note ends with a striking line: "This issue has been responsibly disclosed to MSRC and received a 'won't fix' response." The same year Microsoft began documenting the `szOID_NTDS_CA_SECURITY_EXT` extension in certificate-related KBs, though without making it default-on. The substrate for what would become ESC9, ESC10, and ESC14 was already in place; nobody had named it yet.
Twenty-one years from the role's ship date, then. Twenty-one years of admin-tunable knobs. No numbered identifiers, no patch cadence, no scanner enumeration, no MSRC pipeline. Microsoft documented every one of these settings individually, often well; what was missing was the *catalog*. Hardening guidance without numbered identifiers produces no defensive prioritization in real enterprises, because enterprise security programs prioritize against catalogs, not against documentation pages [@bollinger-ekuwu]. So what happened in June 2021 that turned a documentation pattern into a catalog?
flowchart LR
A[2000 Microsoft Certificate Services ships in Windows 2000 Server] --> B[2003 V2 templates and autoenrollment]
B --> C[2008 Role renamed Active Directory Certificate Services]
C --> D[2019 de Drouas notes altSecurityIdentities abuse]
D --> E[June 2021 SpecterOps catalog ESC1 through ESC8]
E --> F[2021 to 2022 KB5005413 CVE-2022-26923 KB5014754]
F --> G[2022 to 2023 ESC9 to ESC12 from Lyak Heiniger Knobloch]
G --> H[2024 ESC13 to ESC15 Knudsen and Bollinger CVE-2024-49019]
H --> I[2025 ESC16 strong-mapping full enforcement]
## 3. Six Primitives Every ESC Abuses
Before opening the catalog, install the vocabulary. Every ESC -- without exception -- abuses one of six primitives: the template, the issuing authority, the enrollment transport, the certificate mapping, the authentication bridge, and the persistence substrate. Once you have these six names in your head, the sixteen ESCs compose into a small grid.
### The Template
A certificate template is an Active Directory object stored in the `CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration` partition that tells an Enterprise CA what kind of certificate to issue and to whom. Templates carry their own DACL controlling who can enroll, who can write, and who can autoenroll. They carry a `msPKI-Certificate-Name-Flag` attribute whose bits control how the Subject and Subject Alternative Name fields are populated. They carry an Extended Key Usage list that names what the certificate is permitted to do. And they carry a Manager Approval bit that gates whether issuance is automatic or whether a CA officer must approve each request [@msl-adcs-2012r2].
The Active Directory-stored object specifying who can request what kind of certificate from an Enterprise CA. Templates carry per-object DACLs (enrollment, autoenrollment, write), a `msPKI-Certificate-Name-Flag` controlling Subject and SAN behavior, an Extended Key Usage list, and a Manager Approval bit. V1 templates (Windows 2000) are non-modifiable; V2 templates (Windows Server 2003) are fully modifiable; V3 templates (Windows Server 2008) add Suite B cryptography.
ESC1, ESC2, ESC3, ESC4, and ESC15 all attack the template. They differ only in which template property is misconfigured. (ESC9 also begins on a template flag, `CT_FLAG_NO_SECURITY_EXTENSION`, but its effect lives in the mapping layer; we file it under mapping below, matching SpecterOps's own Certify taxonomy [@specterops-certify-docs-index].)
### The Issuing Authority
An Enterprise CA is a Windows Server role service that signs certificate requests against published templates. To be trusted for authentication, the CA must be published into the forest's `NTAuthCertificates` container. That container is the single list of CA certificates the Key Distribution Center trusts for PKINIT. The CA carries its own security descriptor controlling who can enroll, who can manage certificates, and who can manage the CA itself. It carries two registry flags that change its issuance behavior: `EDITF_ATTRIBUTESUBJECTALTNAME2`, which permits requesters to specify arbitrary Subject Alternative Names, and `IF_ENFORCEENCRYPTICERTREQUEST`, which controls whether RPC enrollment requires packet privacy [@compass-esc11]. The 2022 KB5014754 patch introduced `szOID_NTDS_CA_SECURITY_EXT`, a Microsoft-specific extension carrying the requester's Security Identifier; that extension is the load-bearing artifact of the strong-mapping enforcement track [@kb5014754].
The AD-integrated certificate authority role in AD CS. Publishes certificate templates into Active Directory, processes certificate requests against those templates, and signs issued certificates with its private key. To be trusted for Windows authentication, the CA's certificate must be present in the forest-wide `NTAuthCertificates` container.
The AD-published container `CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration` listing CA certificates trusted by the Key Distribution Center for client authentication. Any certificate signed by a CA in this container can, given a valid mapping, mint a Kerberos Ticket-Granting Ticket. Publishing a CA into NTAuth is the moment that CA's private key becomes a trust root parallel to krbtgt.
ESC5, ESC6, ESC7, and ESC16 attack the issuing authority itself -- its DACL, its registry flags, its extension policy. (ESC11's RPC packet-privacy gap is a CA-side configuration, but its abuse is an NTLM relay; we group it with ESC8 under transport, matching the §5 diagram.)
### The Enrollment Transport
A certificate is requested over a network protocol. The default transport is DCOM/MS-WCCE -- the Windows Client Certificate Enrollment protocol, an RPC-based interface that ships enabled on every Enterprise CA [@ms-icpr-spec]. Additional transports ship as separate role services: HTTP Web Enrollment (IIS-based, with NTLM auth by default), the Certificate Enrollment Web Service (web service, supports basic and Kerberos), the Network Device Enrollment Service (the SCEP gateway), and the Certificate Enrollment Policy Web Service. Each transport is a network attack surface for relay primitives that route a coerced NTLM authentication into a certificate request.
ESC8 attacks the HTTP Web Enrollment transport. ESC11 attacks the RPC transport. Both are [NTLM-relay attacks](/blog/ntlmless-the-death-of-ntlm-in-windows/); they differ only in which transport the relayed authentication targets.
The CA's security model distinguishes two rights that look similar but differ in scope. *Issue and Manage Certificates* permits the holder to approve pending requests, revoke issued certificates, and read the request store. *Manage CA* permits the holder to edit the CA's own configuration -- including its registry-controlled extension policy and its DACL. ESC7 attacks the latter. The escalation chain that follows ESC7 typically pivots to ESC4 (edit a template) or to issuing a certificate directly via a CA officer's request-approval right.
### The Certificate Mapping
When a CA issues an authentication certificate, the certificate identifies a principal -- a user or a computer. The Key Distribution Center has to decide which Active Directory principal that certificate represents. Two mappings exist. *Implicit mapping* reads the Subject Alternative Name (or the Subject, on older templates) and looks up the principal by User Principal Name. *Explicit mapping* reads the AD principal's own `altSecurityIdentities` attribute, which holds one or more X.509 issuer/serial expressions [@dedrouas-altsec]. The May 2022 KB5014754 patch redefined which mappings the KDC accepts: explicit mappings using `X509IssuerSerialNumber`, `X509SKI`, or `X509SHA1PublicKey` are *strong*; everything else is *weak* and will be rejected once Full Enforcement is active [@kb5014754].
OID 1.3.6.1.4.1.311.25.2. The Microsoft certificate extension introduced by KB5014754 that embeds the SID of the requesting Active Directory principal directly into the issued certificate. When present, the KDC matches the certificate against the principal whose SID is embedded, defeating SAN-supply attacks like ESC1. The extension is the load-bearing mechanism of strong mapping enforcement.
Per KB5014754, explicit `altSecurityIdentities` entries using the `X509IssuerSerialNumber`, `X509SKI`, or `X509SHA1PublicKey` formats are *strong*. All other formats -- including implicit UPN and SAN matching -- are *weak* and rejected once Full Enforcement mode is active (February 11, 2025 default; legacy-mapping registry override removed September 9, 2025) [@kb5014754]. The strong-mapping track was the single largest Microsoft mitigation of the ESC era.
ESC9, ESC10, ESC13, and ESC14 all attack the mapping. They abuse the gap between what a certificate asserts and which AD principal the KDC binds it to.
### The Authentication Step
This component is the part of Windows that turns a certificate into an authenticator. For [Kerberos](/blog/kerberos-in-windows-the-other-half-of-ntlmless/), the protocol is PKINIT (RFC 4556 [@rfc4556]): client presents a cert, KDC validates the cert and the mapping, KDC issues a TGT. For TLS-based services -- LDAPS, RDP with smart card, IIS with client cert -- the protocol is Schannel. For the legacy smart-card pipeline, the path is the combination of the Smart Card Resource Manager and PKINIT.
No ESC attacks this step directly. Every ESC must *cross* it to convert a misconfigured template, ACL, or mapping into a usable authenticator. The authentication step is the choke point; it is also the point Microsoft has reshaped most heavily with KB5014754.
### The Persistence Substrate
An issued certificate is not a transient credential. It is a signed authenticator with a configurable validity period (one year is common, ten years is permitted). The certificate authenticates the embedded principal as long as the certificate is valid and not revoked. That property is what the SpecterOps paper's `DPERSIST` and `THEFT` classes attack [@cpo-blog]. UnPAC-the-Hash recovers the NTLM hash from a PKINIT-issued TGT, giving the attacker a password-equivalent credential they did not previously have. The Golden Certificate attack steals the CA's own private key, granting forever-issuance against the entire forest.
This article scopes those attacks to a sidebar; the body walks the ESC1 to ESC16 escalation catalog. But every ESC ends in the persistence substrate: the certificate the attacker walks out with is the receipt that survives password rotation.
> **Note:** A *primitive* is a Microsoft-shipped knob, flag, ACL, or protocol that, when misconfigured, becomes part of an escalation. An *exploitation chain* is the specific sequence of operator actions that turns one or more misconfigured primitives into a Domain Admin authenticator. ESCs are exploitation chains, not primitives. ESC1, for example, abuses the *template* primitive's `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` bit, combined with the *bridge* primitive (PKINIT), to produce the authenticator. The catalog enumerates chains; the six categories above enumerate the substrate.
Now that the vocabulary is in place, sixteen named attacks compose neatly onto a 6 by 16 grid. Here is the moment they did.
flowchart TD
T[Template per-template DACL Name-Flag bits EKU list Manager Approval]
A[Issuing Authority NTAuth membership CA security descriptor EDITF flags extension policy]
X[Enrollment Transport RPC/MS-WCCE HTTP Web Enrollment CES/CEP NDES/SCEP]
M[Certificate Mapping implicit UPN/SAN explicit altSecurityIdentities strong vs weak SID extension]
B[Authentication Bridge PKINIT for Kerberos Schannel for TLS smart-card pipeline]
P[Persistence Substrate validity period UnPAC-the-Hash Golden Certificate CRL bypass]
T --> A
A --> X
X --> B
A --> M
M --> B
B --> P
## 4. Certified Pre-Owned
Will Schroeder pushes the SpecterOps Medium post live on June 17, 2021. (A revision tagged `[EDIT 06/22/21]` follows the next week; the literature settles on "June 2021" as the canonical date [@cpo-blog].) The whitepaper PDF drops in the same window and is rehosted on the SpecterOps domain the following year [@cpo-whitepaper]. Seven weeks later, on August 5, Schroeder and Christensen present *Certified Pre-Owned: Abusing Active Directory Certificate Services* at Black Hat USA 2021. Three GhostPack tools ship to GitHub on schedule: PSPKIAudit for defense [@pspkiaudit-gh], Certify for offense [@certify-gh], and ForgeCert for Golden Certificate work.
The paper names eight escalation paths and three persistence and theft prefixes:
- **ESC1 through ESC8** -- *escalation* paths from a low-privilege foothold to Domain Admin
- **DPERSIST** -- *domain persistence* via forged certificates after CA private-key compromise
- **THEFT** -- *certificate and credential theft* primitives, including the UnPAC-the-Hash technique
- **DETECT** -- *defensive detection* primitives the team mapped to each abuse
The contribution was not the *discovery* of new individual primitives. Most of the individual misconfigurations had appeared in Microsoft's hardening guidance or in scattered community posts well before the paper. ENROLLEE_SUPPLIES_SUBJECT had been a documented warning for a decade. NTLM relay to IIS had been a known attack class since at least 2008. The `EDITF_ATTRIBUTESUBJECTALTNAME2` flag was a documented option in `certutil` since Windows Server 2008 R2. What the paper contributed was the *unified catalog* -- numbered identifiers, reproducible exploitation, a tool that enumerated each path, and a single document tying every abuse to its primitive and its mitigation.
"While AD CS is not installed by default for Active Directory environments, from our experience in enterprise environments it is widely deployed, and the security ramifications of misconfigured certificate service instances are enormous." -- Will Schroeder and Lee Christensen, *Certified Pre-Owned* (June 2021) [@cpo-blog]
Microsoft's response was uncharacteristically fast. KB5005413 published in late July 2021 -- roughly six weeks after the blog -- recommending Extended Protection for Authentication and "Require SSL" on the AD CS Web Enrollment and Certificate Enrollment Web Service role services [@kb5005413]. The KB closes ESC8 over HTTPS when EPA is enabled. It does not close ESC1 through ESC7, and it does not close ESC11 (which had not yet been named).
The "ESC" prefix is an acronym for *escalation*. The catalog uses three sibling prefixes from the same paper: `DPERSIST` for *domain persistence*, `THEFT` for credential and certificate theft, and `DETECT` for defensive detection identifiers. ESC numbering is consecutive but not contiguous in time -- ESC12 (a hardware substrate attack) was disclosed by Knobloch in October 2023 [@knobloch-esc12] [@knobloch-esc12-archive], four months before Knudsen disclosed ESC13 and ESC14 from SpecterOps. The numbering tracks the order of community disclosure, not a planned roadmap.
Here is the observation that this article will load-bear: the breakthrough was *naming*, not discovery. Until SpecterOps named the eight configurations, every one of them had been documented somewhere in Microsoft Learn or in a community blog. The hardening documentation had existed for years and had produced essentially no defensive prioritization in real enterprises. Microsoft Defender for Identity did not flag ESC1 templates. BloodHound did not graph ESC4-shaped DACLs. SIEMs did not ingest CA Event ID 4886. No commercial scanner shipped a rule for the Enrollee-Supplies-Subject bit. The reason was not that the information was inaccessible. The reason was that the *configurations had no names* -- and an enterprise security program cannot prioritize against an unnamed configuration.
> **Key idea:** Naming is itself a defensive primitive. The 2021 SpecterOps catalog converted twenty-one years of unnamed admin-tunable knobs into a numbered backlog that scanners could enumerate, BloodHound could path-find, MSRC could patch, and operators could prioritize. Every subsequent mitigation generation -- KB5005413, CVE-2022-26923, KB5014754, CVE-2024-49019, BloodHound CE ADCS edges, Locksmith, Microsoft Defender for Identity's posture assessments -- builds on the catalog rather than on the underlying hardening documentation. The catalog is the security primitive; the patches are downstream of the catalog.
Eight ESCs in 2021. Within fifteen months, two researchers extended the catalog past the original boundary: Oliver Lyak at the Institute For Cyber Risk added ESC9 and ESC10 in August 2022 [@lyak-certipy-4-archive]; Sylvain Heiniger at Compass Security added ESC11 in November 2022 [@compass-esc11]. Hans-Joachim Knobloch added ESC12 in October 2023 [@knobloch-esc12]. SpecterOps's Jonas Bülow Knudsen added ESC13 in February 2024 [@knudsen-esc13] and ESC14 two weeks later [@knudsen-esc14]. Justin Bollinger at TrustedSec added ESC15 in October 2024 [@bollinger-ekuwu]. Lyak named ESC16 in 2025 against a workaround Schroeder himself had documented in 2022 [@specterops-esc16-docs]. Sixteen ESCs by the time you read this. Here is what each one does.
## 5. The Catalog: ESC-1 through ESC-16
Of the sixteen named ESCs, the original eight name the surface; ESC9 through ESC16 name the residual after every Microsoft mitigation shipped to date. We walk them in primitive-grouped order, following the same taxonomy the SpecterOps Certify documentation uses: template misconfigurations, access-control vulnerabilities, CA configuration issues, certificate mapping issues, and one hardware-substrate sidebar [@specterops-certify-docs-index].
### Template misconfigurations: ESC1, ESC2, ESC3
**ESC1 -- Misconfigured Certificate Template.** A V2 template that lets a low-privilege principal enroll, has Client Authentication in its Extended Key Usage list, has `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` set, and does *not* require Manager Approval. The attacker requests a certificate naming the target principal in the Subject Alternative Name; the CA issues; the certificate maps via UPN to the target; PKINIT produces a TGT as the target. One operator chain: `certipy req -u user -p pass -ca CA -template VulnTemplate -upn administrator@domain.local`. First disclosed by SpecterOps in June 2021 [@cpo-blog]. BloodHound CE edge: `ADCSESC1` [@bh-esc1-edge].
The `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` bit in `msPKI-Certificate-Name-Flag`. When set, the requester is allowed to supply the Subject or Subject Alternative Name in the CSR rather than having the CA build the Subject from the requester's own AD attributes. This is the load-bearing primitive of ESC1.
```powershell
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 |
Where-Object {
($_.'msPKI-Certificate-Name-Flag' -band 0x1) -ne 0 -and
($_.'msPKI-Enrollment-Flag' -band 0x2) -eq 0 -and
($_.pKIExtendedKeyUsage -contains '1.3.6.1.5.5.7.3.2')
} | Select-Object Name
```
The query lists templates with ESS set, no manager approval, and Client Authentication EKU. Locksmith, PSPKIAudit, and Certipy all run a logically equivalent check; this is the smallest reproducible form for an audit script that does not depend on a vendor tool.
**ESC2 -- Any-Purpose or Subordinate CA EKU.** A template that grants the Any-Purpose EKU (`2.5.29.37.0`) or the Subordinate CA EKU permits the certificate to be used for arbitrary purposes, including subordinate CA work. The attacker enrolls and then forges new certificates against the issued certificate's keypair. First disclosed by SpecterOps, June 2021 [@cpo-blog]. No BloodHound CE edge; the abuse pattern lives in Certify and Certipy [@certipy-wiki-priv].
**ESC3 -- Enrollment Agent Template.** A template with the *Certificate Request Agent* EKU lets the holder enroll certificates *on behalf of other users*. Combined with a second template flagged "Enrollment Agent" the attacker can request a certificate naming any principal. The chain is two requests rather than one. SpecterOps, June 2021 [@cpo-blog]. BloodHound CE edge: `ADCSESC3`.
### Access-control vulnerabilities: ESC4, ESC5, ESC7
**ESC4 -- Vulnerable Certificate Template ACL.** Any principal with `GenericAll`, `GenericWrite`, `WriteOwner`, or `WriteDacl` on a template can modify the template into an ESC1-shaped configuration and then enroll. This converts a write right on a template object into Domain Admin. SpecterOps, June 2021 [@cpo-blog]. BloodHound CE edge: `ADCSESC4`.The ADCSESC4 edge composes with BloodHound's general DACL graph, so a `Domain Users` principal that holds `WriteDacl` on a sensitive template inherits the path automatically without a hand-written query. The edge composes naturally with the rest of BloodHound's principal-DACL graph -- a `Domain Users` principal with `WriteDacl` on the template inherits the path.
**ESC5 -- Vulnerable PKI Object ACL.** The same class of write rights on the CA computer object, the `NTAuthCertificates` container, or the AIA container. Compromising any of these gates the entire AD CS substrate. SpecterOps, June 2021 [@cpo-blog]. No BloodHound CE edge today; the surface is wide and the operator chain depends on the specific object compromised.
**ESC7 -- Vulnerable CA ACL.** A principal with the *Manage CA* right on the Enterprise CA can edit its registry-controlled configuration (including the `EDITF_ATTRIBUTESUBJECTALTNAME2` flag, which converts the CA into a global ESC6 condition). A principal with *Issue and Manage Certificates* can approve their own otherwise-blocked certificate requests. SpecterOps, June 2021 [@cpo-blog]. No BloodHound CE edge; the abuse is a CA-side write rather than an AD principal-graph relationship.
### CA configuration issues: ESC6, ESC8, ESC11
**ESC6 -- `EDITF_ATTRIBUTESUBJECTALTNAME2` on the CA.** When this CA-wide flag is set, *every* certificate request can specify an arbitrary Subject Alternative Name regardless of the template's Name-Flag bits. The CA becomes globally ESC1-shaped against any template the attacker can enroll into. SpecterOps, June 2021 [@cpo-blog]. BloodHound CE edges: `ADCSESC6a` and `ADCSESC6b` (the latter for cases where the CA also disables the SID extension).
**ESC8 -- NTLM Relay to AD CS HTTP Web Enrollment.** The AD CS Web Enrollment role service ships with NTLM authentication enabled and, by default, no Extended Protection for Authentication. An attacker who can coerce a target computer to authenticate (PetitPotam, PrinterBug, DFSCoerce) can relay that authentication to the CA's `/certsrv/` endpoint, request a certificate naming the relayed principal, and walk away with a certificate impersonating the coerced computer -- including Domain Controllers. SpecterOps, June 2021 [@cpo-blog]. BloodHound CE graphs this as the `CoerceAndRelayNTLMToADCS` edge [@bh-coerce-adcs-edge]: a Group-to-Computer edge whose source is `Authenticated Users` and whose destination is the coerced target computer, with the edge's evaluation conditioned on at least one ESC8-vulnerable Web Enrollment endpoint being reachable on the network.
> **Note:** ESC8 needs no template misconfiguration. It needs a CA with HTTP Web Enrollment role service installed -- common in environments that ever provisioned smart cards or did web-based renewal -- and at least one computer account the attacker can coerce. Microsoft mitigated it with KB5005413 in July 2021 [@kb5005413], but the mitigation is configuration guidance (EPA on, "Require SSL" on, Web Enrollment disabled if unused), not a binary patch. Environments that never enabled EPA on /certsrv/ remain exploitable today. The "Domain Users to Domain Admin in eight minutes" demos that pepper conference talks are usually ESC8 demos.
**ESC11 -- NTLM Relay to ICPR/RPC.** The ICertPassage RPC interface (the default enrollment transport on every Enterprise CA) enforces packet privacy when the `IF_ENFORCEENCRYPTICERTREQUEST` flag is set; that flag has been on by default since Windows Server 2012. However, because the flag breaks certificate enrollment for legacy Windows XP clients, Compass Security observed real-world environments where administrators had explicitly *removed* the flag for compatibility, leaving the RPC enrollment surface unencrypted. When packet privacy is not enforced, an attacker can relay a coerced NTLM authentication into the CA's RPC interface and obtain a certificate impersonating the coerced principal. Disclosed by Sylvain Heiniger at Compass Security, November 2022 [@compass-esc11]. The SpecterOps Certify documentation describes the misconfiguration as "an insufficiently protected certificate authority RPC interface" [@specterops-esc11-docs]. No BloodHound CE edge; the RPC transport is below the principal-graph model.
### Certificate mapping issues: ESC9, ESC10, ESC13, ESC14, ESC15, ESC16
**ESC9 -- No Security Extension.** A template flagged `CT_FLAG_NO_SECURITY_EXTENSION` instructs the CA to issue certificates *without* the `szOID_NTDS_CA_SECURITY_EXT` SID embedding. KB5014754's strong-mapping enforcement then falls back to weak UPN mapping, and the attacker can rename a controlled user account to match a privileged user's UPN, enroll, and authenticate as that privileged user. Disclosed by Oliver Lyak at IFCR on August 4, 2022, twelve weeks after KB5014754 [@lyak-certipy-4-archive]. BloodHound CE edges: `ADCSESC9a` and `ADCSESC9b`.
**ESC10 -- Weak Certificate Mapping.** The registry values `StrongCertificateBindingEnforcement` (on KDCs) and `CertificateMappingMethods` (on Schannel servers) control whether weak mappings are accepted. In Compatibility mode (the KB5014754 staged-rollout default through February 11, 2025), weak mappings still pass. An attacker who can write `altSecurityIdentities` on a target, or who can engineer a weak UPN match, authenticates as the target. Same disclosure: Lyak, August 4, 2022 [@lyak-certipy-4-archive]. BloodHound CE edges: `ADCSESC10a` and `ADCSESC10b`.
**ESC13 -- Issuance Policy linked to AD Group via msDS-OIDToGroupLink.** Active Directory issuance-policy OIDs can be linked to a security group via the `msDS-OIDToGroupLink` attribute. When a certificate carries that issuance-policy OID, the issued PAC includes the linked group. A template configured with such an issuance policy effectively grants its enrollees membership in the linked group at authentication time. Disclosed by Jonas Bülow Knudsen at SpecterOps on February 14, 2024; discovery credit goes to Adam Burford, who brought the technique to Knudsen and Stephen Hinck [@knudsen-esc13]. BloodHound CE edge: `ADCSESC13`.
**ESC14 -- Explicit altSecurityIdentities Write.** A principal with write access to a privileged user's `altSecurityIdentities` attribute can add their own certificate's X.509 expression to that attribute, then authenticate as the privileged user. The prior art goes back to Géraud de Drouas in 2019 [@dedrouas-altsec] and Jean Marsault at Wavestone in June 2021 [@marsault-wavestone]; Knudsen catalogued it as ESC14 in February 2024 [@knudsen-esc14]. No BloodHound CE edge today; the abuse traces through a write right on a single AD attribute and is in scope for future BloodHound coverage.
**ESC15 -- V1 Template Application Policies Override (EKUwu).** The pre-installed V1 `WebServer` template -- which ships on every CA, cannot be deleted, and is enrollable by `Authenticated Users` by default -- accepts `Application Policies` extensions in the request. Application Policies, a Microsoft extension parallel to standard EKU, are honored by the KDC. An attacker submits a CSR adding the Client Authentication Application Policy to a WebServer certificate, gets it signed, and authenticates as the requester. Disclosed by Justin Bollinger at TrustedSec on October 8, 2024 [@bollinger-ekuwu]. Microsoft assigned CVE-2024-49019 and patched it on November 12, 2024 [@cve-2024-49019-msrc]. No BloodHound CE edge.
**ESC16 -- CA-wide SID Extension Disabled.** The CA's `DisableExtensionList` registry value can list OIDs the CA will *omit* from issued certificates. If `szOID_NTDS_CA_SECURITY_EXT` (1.3.6.1.4.1.311.25.2) is on that list, the CA stops embedding the SID extension globally, and the strong-mapping enforcement of KB5014754 collapses into weak mapping for every certificate the CA issues. The SpecterOps Certify documentation records the punchline: "The configuration was first described in 2022 by Will Schroeder in this blogpost as a temporary workaround for the interaction between ESC7 and ESC6, but was later tagged ESC16 by Oliver Lyak" [@specterops-esc16-docs]. No BloodHound CE edge.
By the time you reach ESC10 here, a pattern is visible without anyone naming it: every Microsoft mitigation in this class is followed by a new ESC that side-steps it. KB5005413 closes ESC8 over HTTPS; ESC11 routes around it via RPC. KB5014754 closes ESC9 and ESC10 under Full Enforcement; ESC16 disables the underlying SID extension. CVE-2024-49019 closes ESC15 on V1 templates; the V1 templates themselves remain on every CA. The catalog grows faster than the patches.
Of the sixteen entries above, BloodHound CE ships eleven principal-graph edges covering eight distinct ESCs: `ADCSESC1`, `ADCSESC3`, `ADCSESC4`, `ADCSESC6a/b`, `ADCSESC9a/b`, `ADCSESC10a/b`, `ADCSESC13`, plus the `CoerceAndRelayNTLMToADCS` edge that graphs ESC8 [@bh-llms]. The remaining eight ESCs (ESC2, ESC5, ESC7, ESC11, ESC12, ESC14, ESC15, ESC16) are out of edge coverage today -- some because their primitive lives below the principal graph (ESC11's RPC transport), some because their abuse is a CA-side write rather than a domain principal relationship (ESC7, ESC5), and some because they are too new to have been edge-modeled (ESC14, ESC15, ESC16). The gap is structural and operationally significant; section eight explores why.
flowchart TD
subgraph TEMPLATE[Template]
E1[ESC1 ESS+ClientAuth+LowPriv SpecterOps 2021]
E2[ESC2 AnyPurpose/SubCA SpecterOps 2021]
E3[ESC3 Enrollment Agent SpecterOps 2021]
E15[ESC15 V1 AppPolicy TrustedSec 2024]
end
subgraph ACL[Access Control]
E4[ESC4 Template DACL SpecterOps 2021]
E5[ESC5 PKI Object DACL SpecterOps 2021]
E7[ESC7 CA DACL SpecterOps 2021]
end
subgraph CA[CA Configuration]
E6[ESC6 EDITF SAN2 SpecterOps 2021]
E16[ESC16 Disable SID Ext tagged Lyak 2025]
end
subgraph TRANSPORT[Transport]
E8[ESC8 Relay to HTTP SpecterOps 2021]
E11[ESC11 Relay to RPC Compass 2022]
end
subgraph MAP[Mapping]
E9[ESC9 No SID Ext IFCR 2022]
E10[ESC10 Weak Mapping IFCR 2022]
E13[ESC13 OIDToGroupLink SpecterOps 2024]
E14[ESC14 altSecurityIdentities SpecterOps 2024]
end
subgraph HW[Hardware]
E12[ESC12 YubiHSM Substrate Knobloch 2023]
end
The static rules that Certipy, Certify, Locksmith, and PSPKIAudit all run to decide whether a template is ESC1-shaped are simpler than the catalog above might suggest. Three boolean inputs, three conjunctive conditions, one output label.
{`
function classifyTemplate(t) {
const ess = t.flags.includes('CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT');
const clientAuth = t.eku.includes('1.3.6.1.5.5.7.3.2');
const lowPriv = t.enroll.some(p => ['Authenticated Users', 'Domain Users'].includes(p));
const noApproval = !t.flags.includes('CT_FLAG_PEND_ALL_REQUESTS');
if (ess && clientAuth && lowPriv && noApproval) return 'ESC1';
return 'safe-for-now';
}
const wifi = {
flags: ['CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT'],
eku: ['1.3.6.1.5.5.7.3.2'],
enroll:['Authenticated Users']
};
console.log(classifyTemplate(wifi));
`}
## 6. The 2026 Toolchain
Sixteen ESCs is too many for one tool. The 2026 state of the art is a stack: defenders run Locksmith, PSPKIAudit, BloodHound CE, and Microsoft Defender for Identity in parallel; offense runs Certipy and Certify. No single tool covers every ESC, prioritizes its findings, *and* produces forensic primitives for response. Coverage gaps are structural, not accidental.
**Certify** is the original offense-side tool from the SpecterOps team that wrote *Certified Pre-Owned*. A C# Windows binary that enumerates and abuses AD CS misconfigurations using the operator's in-process credentials [@certify-gh]. Released at Black Hat 2021, built against .NET 4.7.2. Certify covers the ESC1 through ESC16 enumeration surface via its documentation pages [@specterops-certify-docs-index]; abuse implementations exist for the catalog's most operator-friendly entries, with ESC11 documented as enumeration-only at the most recent docs revision [@specterops-esc11-docs].
**Certipy** is the Linux-side sibling, written in Python by Oliver Lyak at IFCR (now an independent project) [@certipy-gh]. The README carries the strongest coverage claim in the tool community: "full support for identifying and exploiting all known ESC1-ESC16 attack paths." Certipy ships its own NTLM relay (`certipy relay`), embedded BloodHound output, certificate forging, and PKINIT-to-TGT exchange. The Certipy wiki's privilege-escalation page is the best walking reference for the entire catalog [@certipy-wiki-priv].
**BloodHound Community Edition** is the only tool in the stack that integrates AD CS findings into the broader Active Directory attack graph. SharpHound CE collects AD CS objects -- CAs, templates, NTAuth membership, per-template DACLs -- and the BloodHound server computes ten `ADCSESC*N*` edges (ESC1, ESC3, ESC4, ESC6a/b, ESC9a/b, ESC10a/b, ESC13) plus the `CoerceAndRelayNTLMToADCS` edge that graphs ESC8 via coercion [@bh-llms]. BloodHound CE 7.x added Privilege Zones, which let defenders tag NTAuth CAs and their templates as Tier-Zero objects and surface paths to them in the analysis UI.
**Locksmith** is a PowerShell defender tool by Jake Hildreth (with Spencer Alessi) [@locksmith-gh]. It runs locally on a domain-joined host and reports template, CA, and NTAuth-container findings against the catalog. Modes 0 through 4: identify-and-report, auto-remediate where safe, produce a CSV, and so on. The lowest-friction defender tool in the stack -- a single `Invoke-Locksmith` cmdlet returns a triage list against the published ESC range.
**PSPKIAudit** is the SpecterOps team's own defender baseline, built on top of PKI Solutions' PSPKI module [@pspkiaudit-gh]. Its `Invoke-PKIAudit` and `Get-CertRequest` cmdlets cover ESC1 through ESC8 plus the "Explicit Mappings" surface for ESC14. The README is marked beta; PSPKIAudit predates Locksmith and ships fewer remediation primitives, but it is the canonical reference for what the original SpecterOps team thinks the defensive audit should do.
**Microsoft Defender for Identity** ships the ADCS posture assessment suite when the MDI sensor is installed on the CA itself [@mdi-certs]. The current product surface assesses nine ESCs by name: ESC1 (Preview), ESC2, ESC3, ESC4 (split across two separate assessments -- template owner and template ACL), ESC6 (Preview), ESC7, ESC8, ESC11, and ESC15. The product page is explicit: "This assessment is available only to customers who have installed a sensor on an AD CS server." MDI's coverage is *broad and operationally integrated* -- the same SOC console that surfaces Pass-the-Hash detections now surfaces the largest named-ESC posture-assessment suite of any non-Certipy tool in the stack, with the ESC1 and ESC6 assessments shipped in Preview state.
**The KB5014754 strong-mapping track** is Microsoft's runtime mitigation rather than a tool, but operationally it belongs in the stack discussion because it is the largest single thing Microsoft has shipped for this class [@kb5014754]. Strong mapping closes ESC9 and ESC10 (plus Certifried CVE-2022-26923) under Full Enforcement, defaults to Compatibility through February 11, 2025, and removes the legacy-mapping registry override on September 9, 2025. Operationally this is a deployment decision more than a "tool to run", but every defender stack has to plan for it; the Microsoft Tech Community Intune blog is the cross-reference for environments using SCEP or PKCS [@ms-tc-intune].
**The Hacker Recipes AD CS chapter** is a community reference catalog rather than a runnable tool; it serves as the canonical operator-facing summary of every ESC and is worth bookmarking. (Network reachability of the canonical URL has been inconsistent in late 2025 / 2026.)
Here is a single-table comparison of the practical stack. The right answer for a real enterprise is roughly "all of them in parallel"; the table makes the coverage gaps explicit.
| Tool / track | Language | ESC enumeration coverage | Abuse capable | Graph capable | Best deployed for | Source |
|---|---|---|---|---|---|---|
| Certify | C# (Windows) | ESC1 to ESC16 (per docs) | Yes (most) | No | Operator chains, Windows offense | [@certify-gh] |
| Certipy | Python (Linux) | ESC1 to ESC16 (README claim) | Yes | Embedded | Operator chains, Linux offense | [@certipy-gh] |
| BloodHound CE ADCS edges | Cypher | 8 of 16 ESCs (11 edges: ten ADCSESC*N* + CoerceAndRelayNTLMToADCS) | No | Yes | Prioritization, attack-path analysis | [@bh-llms] |
| Locksmith | PowerShell | Published ESC catalog | Identify and fix | No | Operational scans on each CA | [@locksmith-gh] |
| PSPKIAudit | PowerShell | ESC1 to ESC8 plus Explicit Mappings | No (read-only) | No | Defender baseline, audit | [@pspkiaudit-gh] |
| MDI ADCS posture | SaaS | ESC1 (Preview), ESC2, ESC3, ESC4, ESC6 (Preview), ESC7, ESC8, ESC11, ESC15 | No | Inside MDI console | SOC integration, posture scoring | [@mdi-certs] |
| KB5014754 strong mapping | Windows runtime | ESC9, ESC10, Certifried (mitigation) | n/a | n/a | Domain Controllers (deploy) | [@kb5014754] |
> **Note:** For most enterprises the realistic configuration is: Locksmith scheduled monthly on every CA; BloodHound CE with the ADCS collector enabled in SharpHound CE; Microsoft Defender for Identity sensor on every AD CS server (for the nine-ESC SOC visibility surface that now includes ESC1 and ESC6 in Preview); PSPKIAudit run once a quarter as the SpecterOps-blessed baseline; Certipy in the red-team or purple-team kit; and the KB5014754 rollout staged to land at Full Enforcement before February 11, 2025 (legacy-mapping removal September 9, 2025). The remaining gap items -- ESC5, ESC12, ESC14, and ESC16 (neither in BloodHound's principal graph nor in MDI's posture-assessment surface) -- are caught by Locksmith plus PSPKIAudit plus Certipy plus careful template review.
If no single tool covers everything, what is Microsoft actually doing about it?
## 7. What Microsoft Has Actually Shipped
Of sixteen named ESCs, Microsoft has shipped three CVE-class patches. The rest are hardening guidance. The asymmetry is not accidental; it tracks the boundary Microsoft draws in its [Windows Security Servicing Criteria](/blog/windows-security-boundaries-the-document-that-decides-what-g/) between *default-state vulnerabilities* (which receive CVEs and binary patches) and *admin-configurable misconfigurations* (which receive documentation). Most ESCs sit on the configurable side of that boundary.
Four Microsoft mitigation tracks define the response, in order of when they shipped.
**KB5005413 (late July 2021) -- NTLM Web Enrollment hardening.** Published roughly six weeks after *Certified Pre-Owned* in response to PetitPotam plus the SpecterOps ESC8 disclosure [@kb5005413]. Recommends enabling Extended Protection for Authentication, requiring SSL on the `/certsrv/` virtual directories of AD CS Web Enrollment and the Certificate Enrollment Web Service, and disabling NTLM where Kerberos is available. Crucially: KB5005413 is *guidance*, not a binary patch. Environments that never enabled EPA on `/certsrv/` remain exploitable today. The KB closes ESC8 over HTTPS when fully applied; it does not affect ESC11 (RPC), ESC1 through ESC7, or anything in the ESC9-plus range.
**CVE-2022-26923 (May 10, 2022) -- Certifried.** The single MSRC-acknowledged CVE in the original ESC1 through ESC8 design space [@cve-2022-26923-nvd] [@cve-2022-26923-msrc]. Disclosed by Oliver Lyak at IFCR [@lyak-certifried], the vulnerability lets any Authenticated User (because the default `ms-DS-MachineAccountQuota` is 10 [@semperis-cve]) create a computer account, write its `dNSHostName` to match a Domain Controller, request a certificate from the default Machine template, and PKINIT as the DC. Microsoft patched it on the May 10, 2022 Patch Tuesday. Semperis's retrospective documents the chain in detail [@semperis-cve]. The patch closes *that specific path* -- the `dNSHostName` impersonation race -- and is part of the same Patch Tuesday that shipped KB5014754. It does not close any other ESC.
**KB5014754 (May 10, 2022 -- present) -- the strong-mapping rollout.** The largest single Microsoft mitigation in the entire class [@kb5014754]. SpecterOps's own analysis -- "Certificates and Pwnage and Patches, Oh My!" -- remains the canonical walkthrough of how the new behavior interacts with the existing catalog [@specterops-pwnage].
The mechanics: KB5014754 introduces the `szOID_NTDS_CA_SECURITY_EXT` extension (OID 1.3.6.1.4.1.311.25.2), embeds the requester's SID into every issued certificate by default, and redefines which `altSecurityIdentities` mappings the KDC will accept. Deployment is staged across three modes -- Disabled, Compatibility, and Full Enforcement -- with the Full Enforcement transition originally planned for November 2023, then repeatedly delayed in response to customer compatibility issues with SCEP, Intune PKCS, and non-Microsoft PKIs. The KB's current text states that Full Enforcement becomes the default on February 11, 2025, and the legacy compatibility-mode registry override is removed by the September 9, 2025 Windows security update [@kb5014754].
What it closes: ESC9 (because Full Enforcement rejects certificates lacking the SID extension), ESC10 (because weak mappings are rejected), and Certifried even on unpatched templates. It is *bypassed* by ESC16, which disables the SID extension at the CA level.
**CVE-2024-49019 (EKUwu / ESC15) -- November 12, 2024.** Patched thirty-five days after Bollinger's October 8, 2024 disclosure [@bollinger-ekuwu]. The November 12, 2024 Patch Tuesday addressed the V1 WebServer template Application-Policies override [@cve-2024-49019-nvd] [@cve-2024-49019-msrc]. The patch hardens the KDC's interpretation of Application Policies in V1 certificates; it does not close ESC16, ESC11, or anything in the template DACL space.
> **Note:** Microsoft's Windows Security Servicing Criteria reserves CVEs for vulnerabilities in default product state [@msrc-servicing-criteria]. Misconfigurations that require administrator action to introduce are treated as hardening matters and receive documentation rather than CVEs. The 2019 ANSSI altSecurityIdentities report received a "won't fix" response on exactly these grounds [@dedrouas-altsec]. The boundary explains the catalog's CVE asymmetry: ESC1 (template flag) is configuration; Certifried (a default-template behavior on an account-creation-default-permission interaction) is a CVE. ESC15 sat on the boundary -- the affected template is shipped pre-installed and cannot be uninstalled, so its default-state could be argued either way -- and Microsoft chose to issue a CVE. The boundary is operational policy, not technical bound; it can move.
The single most useful table in this article is the cross-reference of which Microsoft mitigation closes which ESC. Read row by row to understand which ESCs are runtime-closed in a hardened environment and which remain dependent on the customer's administrative hardening discipline.
| ESC | KB5005413 (2021) | CVE-2022-26923 (2022) | KB5014754 (2022-2025) | CVE-2024-49019 (2024) | Hardening only |
|---|---|---|---|---|---|
| ESC1 | -- | -- | Partial (SID ext defeats SAN supply for cert-authn) | -- | Primary mitigation |
| ESC2 | -- | -- | -- | -- | Yes |
| ESC3 | -- | -- | Partial (SID ext binds the cert to the agent) | -- | Yes |
| ESC4 | -- | -- | -- | -- | Yes |
| ESC5 | -- | -- | -- | -- | Yes |
| ESC6 | -- | -- | Partial (SID ext defeats requested SAN) | -- | Primary |
| ESC7 | -- | -- | -- | -- | Yes |
| ESC8 (HTTP) | Closed when EPA + SSL deployed | -- | -- | -- | Continues if EPA off |
| ESC9 | -- | -- | Closed at Full Enforcement | -- | Until Feb 2025 |
| ESC10 | -- | -- | Closed at Full Enforcement | -- | Until Feb 2025 |
| ESC11 (RPC) | -- | -- | -- | -- | Primary (`IF_ENFORCEENCRYPTICERTREQUEST` flag) |
| ESC12 | -- | -- | -- | -- | Primary (HSM hardening) |
| ESC13 | -- | -- | -- | -- | Yes |
| ESC14 | -- | -- | -- | -- | Yes |
| ESC15 | -- | -- | -- | Closed (Nov 12, 2024) | -- |
| ESC16 | -- | -- | Bypassed (this attack disables the extension) | -- | Primary |
Of sixteen ESCs, three have CVE-class binary patches (Certifried, EKUwu, and -- if you count it -- the KB5005413 NTLM-relay hardening track), two are runtime-closed under KB5014754 Full Enforcement, and the remaining eleven are administrative hardening matters. If only three of sixteen have CVEs, what stops the catalog from growing forever?
## 8. The Two-Trust-Roots Problem
What stops the catalog from growing forever is the architectural property the catalog enumerates around but cannot eliminate. The catalog grows because the property is structural, not because the engineering is sloppy. Four pieces of theory anchor the limit.
**Two trust roots.** Active Directory's Kerberos KDC will mint a Domain Admin Ticket-Granting Ticket on presentation of any valid certificate signed by a CA in the forest's `NTAuthCertificates` container, provided the certificate maps to the Administrator principal. The `krbtgt` key is the symmetric root of trust for password and TGS authentication; an NTAuth CA's private key is an asymmetric root of trust for PKINIT. There is no architectural relationship between the two. Rotating the `krbtgt` key does not invalidate any certificate. Revoking a CA does not invalidate `krbtgt`-issued tickets. They are *independent authenticator-minting keys*. For a forest with $n$ NTAuth-published CAs, the count of independent keys that can mint a Domain Admin authenticator is $n + 1$.
> **Key idea:** For an Active Directory forest with $n$ Certificate Authorities published into `NTAuthCertificates`, there are exactly $n + 1$ independent keys that can mint a Domain Admin authenticator: the krbtgt account hash, and the private key of every published CA. Rotating krbtgt closes one root. Revoking one CA closes another. The other $n - 1$ remain. The ESC catalog enumerates *how* an attacker can make those keys issue a Domain Admin authenticator with low-privilege materials; the architectural property -- that there are $n + 1$ such keys at all -- is a design property of PKINIT and is not closable by any patch [@rfc4556] [@cpo-whitepaper].
**PKINIT's binding gap.** RFC 4556 specifies how a Kerberos client presents a certificate and receives a TGT [@rfc4556]. The RFC does not bind the certificate to a Microsoft SID; the mapping from certificate to AD principal is a Microsoft extension. The KB5014754 strong-mapping track closes the *mapping ambiguity* by embedding the requester's SID into the certificate and matching the SID on the KDC side [@kb5014754]. It does not close the underlying primitive: a certificate is an alternate identity assertion that the KDC honors as long as the signing CA is trusted. Different ESCs find different ways to get a useful certificate; the authentication step is identical across the catalog.
**The transport-versus-principal split.** The §6 BloodHound Aside develops this in full: BloodHound's principal-graph model now expresses ESC8 as the `CoerceAndRelayNTLMToADCS` edge, but ESC11 remains the open structural case because the RPC transport has no equivalent coercion gadget [@bh-coerce-adcs-edge]. The model limit is partial, not total -- it applies to RPC, not to all transport attacks.
**The configuration-versus-CVE boundary.** The §7 Callout develops this in full. The catalog has accumulated CVEs only when Microsoft judged the configuration was default-state -- Certifried's machine-account-quota path and ESC15's pre-installed V1 templates. The architectural property is policy-driven and movable.
Active Directory has two trust roots that can mint a Domain Admin authenticator: the krbtgt key, and any CA published into NTAuth. Rotating one does not touch the other.
The architectural property reshapes how operators should think about the catalog. The catalog is not an arms race that ends; the catalog is the community mapping the surface of a design property of PKINIT. Each new ESC narrows the description of *what surface remains exposed*; no plausible patch removes the underlying $n + 1$ key count. Until PKINIT itself is replaced -- until PKINIT is deprecated, until the KDC stops accepting certificate-based authentication, until NTAuth-published CAs lose their KDC trust -- every NTAuth-published CA in the forest is a key parallel to krbtgt.
If the architectural limit cannot be closed, what are the open questions in 2026?
flowchart LR
K[krbtgt account hash symmetric KDC key]
CA1[CA #1 private key published in NTAuth]
CA2[CA #2 private key published in NTAuth]
CAN[CA #n private key published in NTAuth]
KDC[Kerberos KDC and PKINIT]
AUTH[Domain Admin authenticator TGT]
K --> KDC
CA1 --> KDC
CA2 --> KDC
CAN --> KDC
KDC --> AUTH
## 9. Open Problems and the Catalog's Closure
The catalog has no published closure principle. Here are the five open frontiers in 2026.
**No closure principle.** The catalog has grown every year since 2021: ESC1 through ESC8 in June 2021; ESC9 and ESC10 in August 2022; ESC11 in November 2022; ESC12 in October 2023 [@knobloch-esc12] [@knobloch-esc12-archive]; ESC13 and ESC14 in February 2024; ESC15 in October 2024; ESC16 named in 2025 against a workaround from 2022 [@specterops-esc16-docs]. ESC15 revealed a twenty-four-year-old default behavior on V1 templates -- behavior that had been quietly present since the role's 2000 shipping date [@bollinger-ekuwu]. The Certify documentation conjectures an upper bound (the six primitive categories times the misconfigurable bits per primitive) but no formal upper bound is published. ESC15 is itself an existence proof that *new categories* still emerge: Application Policies as a parallel to standard EKU was not in the original 2021 catalog at all.
**Detection asymmetry.** Most ESCs leave artifacts on the CA -- specifically Event ID 4886 (certificate request submitted) and Event ID 4887 (certificate issued) -- and no artifact in the standard Active Directory event stream. Most SIEMs do not ingest CA logs, because CA logs were never on the standard Tier-Zero ingest checklist. The result is that the CA's own audit log carries the only reliable forensic primitive for the entire catalog, and that log is in a place the SOC does not look. Locksmith and PSPKIAudit can identify the *misconfigurations* but cannot tell you whether they have been *exploited*; that signal lives in the CA's audit log alone.
**Strong-mapping migration risk.** The KB5014754 staged rollout enters Full Enforcement on February 11, 2025 and removes the legacy compatibility-mode registry override on September 9, 2025 [@kb5014754]. Environments with legacy SCEP gateways, third-party PKI vendors, Intune PKCS profiles without strong mapping, or smart cards issued by non-Microsoft CAs face a real risk that *legitimate* authentication breaks at Full Enforcement. The Microsoft Tech Community Intune guidance is the operational reference for the SCEP/PKCS path [@ms-tc-intune]. The migration is a security upgrade and a deployment minefield in the same package; environments that defer the rollout past September 9, 2025 lose the legacy override and are forced into Full Enforcement by an OS update they did not opt into.
> **Note:** Per the live KB5014754 text on Microsoft Support: "By February 2025, if the StrongCertificateBindingEnforcement registry key is not configured, domain controllers will move to Full Enforcement mode" and "the option to move back to Compatibility mode will remain until the September 9, 2025, Windows security update is installed" [@kb5014754]. Environments that have not finished the strong-mapping rollout by those dates -- particularly those with non-Microsoft PKI in the chain, including legacy SCEP / Intune PKCS / smart-card vendors -- should plan for breakage and have a rollback plan ready.
**Cloud PKI.** Entra-managed Cloud PKI changes the substrate: the issuing CA is Microsoft-operated, the template surface is partially exposed to administrators, and the trust relationship between Cloud PKI and on-premises Active Directory is itself a configurable bridge. The community has not yet published an ESC catalog for Cloud PKI; the on-premises catalog is on-prem-specific and does not transfer directly. The open question is whether the Cloud PKI substrate has its own equivalent primitives (a CA-side "this template is configured with ESS-equivalent behavior") that just have not yet been named.
**The NTLM dependency in ESC8 and ESC11.** Both ESC8 and ESC11 depend on NTLM authentication being available between the coerced computer and the CA host. Microsoft's stated direction is to disable NTLM by default in future Windows releases (the "NTLM disablement" track) [@ms-ntlm-evolution]. If that direction completes, ESC8 and ESC11's relay primitives lose their substrate -- not because the AD CS transport hardens, but because there is no NTLM authentication to relay. The rest of the catalog -- the template, ACL, mapping, and CA-configuration ESCs -- does not depend on NTLM and is unaffected by NTLM disablement.
Taken together, these results suggest the catalog's growth trajectory is structural. The reason ESC15 surfaced a twenty-four-year-old default is not that the SpecterOps team was lazy in 2021; it is that the surface is so large that systematic enumeration of every cross-product (six primitives multiplied by the configurable bits per primitive) is itself a research program. Knowing the architectural limits and the open problems, here is the operational playbook.
## 10. The Four-Lane Playbook
Here is what an enterprise security program actually does, in four lanes. Lane discipline matters because the catalog rewards parallel work: a single quarter spent only on Lane 1 leaves you detection-blind, and a single quarter spent only on Lane 2 leaves you remediation-paralyzed.
### Lane 1: Preventive hygiene
Run Locksmith and PSPKIAudit on every Enterprise CA at least monthly [@locksmith-gh] [@pspkiaudit-gh]. Both tools enumerate the published catalog and produce a triage list. The defender baseline these tools encode is roughly:
- Template ACL audit. Confirm that no non-Tier-Zero principal holds `WriteDacl`, `WriteOwner`, `WriteProperty`, or `GenericAll` on any V2 template.
- CA security descriptor audit. Confirm that `Manage CA` and `Issue and Manage Certificates` are held only by Tier-Zero principals.
- ESS audit. Confirm that no template enrollable by `Authenticated Users` or `Domain Users` has `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` set with Client Authentication EKU and no Manager Approval.
- CA registry audit. Confirm that `EDITF_ATTRIBUTESUBJECTALTNAME2` is *not* set, and `IF_ENFORCEENCRYPTICERTREQUEST` *is* set.
- SID extension audit. Confirm that `szOID_NTDS_CA_SECURITY_EXT` (OID 1.3.6.1.4.1.311.25.2) is *not* present in any CA's `DisableExtensionList` registry value -- closing the ESC16 path.
- Manager Approval on sensitive templates. Confirm that any template with privileged EKU sets has Manager Approval.
- Least-privilege Enroll. Confirm that Domain Users-equivalent groups do not hold Enroll or Autoenroll on sensitive templates.
### Lane 2: Detection deployment
Ingest the CA's own Security event log into the SIEM. The two load-bearing events are 4886 ("Certificate Services received a certificate request") and 4887 ("Certificate Services approved a certificate request and issued a certificate"). These events are what fire when an operator chain like the cold-open in section one executes. They are the only AD CS event stream the SOC needs to detect the entire issuance side of the catalog.
Enable Microsoft Defender for Identity sensors on every AD CS server. MDI now ships nine named ESC posture assessments -- ESC1 (Preview), ESC2, ESC3, ESC4 (template owner and template ACL as two separate assessments), ESC6 (Preview), ESC7, ESC8, ESC11, and ESC15 -- and surfaces them in the same console the SOC uses for the rest of Active Directory [@mdi-certs]. The ADCS-resident sensor is the only MDI sensor that produces these particular assessments; environments running MDI on Domain Controllers only do not get the AD CS surface.
Run SharpHound CE with the AD CS collection options enabled and ingest the resulting graph into BloodHound CE. Tag NTAuth-published CAs and their pre-installed sensitive templates as Tier Zero in BloodHound's Privilege Zones. Run the analysis layer's `Shortest Paths to Tier Zero` query weekly; ESC1, ESC3, ESC4, ESC6a/b, ESC9a/b, ESC10a/b, and ESC13 will surface as edges, along with `CoerceAndRelayNTLMToADCS` paths for any ESC8-vulnerable HTTP enrollment endpoint [@bh-llms] [@bh-coerce-adcs-edge].
Schedule Locksmith on a recurring cadence with output to a triage queue. Locksmith is the lowest-friction defender tool; it identifies and (with mode 1) optionally fixes published-catalog findings with a single cmdlet.
### Lane 3: Confirmed-compromise response
This lane carries the article's load-bearing operational claim. If a CA's private key is suspected compromised -- whether through ESC12 hardware-substrate compromise, through `ntdsutil`-equivalent CA export, or through a vendor compromise of the HSM -- the recovery path is *not* "rotate krbtgt" and *not* "revoke the affected certificates". The recovery path is multi-week:
1. Revoke the CA's published certificate chain.
2. Decommission the CA (remove the role service, delete the CA private key store, retire the host).
3. Build a replacement CA on new hardware with a new key.
4. Publish the new CA into `NTAuthCertificates`.
5. Distrust the old CA's certificates throughout the forest (CRL update, certificate revocation lists pushed via Group Policy, decommissioning all certificates issued by the compromised CA).
6. Re-issue every credential that depended on the compromised CA.
This operation is analogous in scale and duration to a forest rebuild for `krbtgt` compromise -- a multi-week IR project, not a one-day patch. The reason is the two-trust-roots property: revoking the CA closes only one of the $n + 1$ keys; if the operator already minted Golden Certificates against the CA's private key, those certificates outlive the revocation unless every issued serial is on the CRL and every relying party has a fresh CRL fetch policy.
> **Note:** The Lane-3 CA rebuild operation is the single most important *preparatory* deliverable in this entire playbook. Run a tabletop exercise: "the CA private key is compromised; what are the steps to a clean state?" If the answer is unclear in the absence of an incident, the answer will be improvised during one -- typically poorly. Build the runbook, identify the operational owners, pre-stage the replacement CA's hardware, and document the certificate inventory you will need to re-issue. The two-week recovery becomes a one-week recovery if the prep is done; the two-week recovery becomes a four-week recovery if it is not.
### Lane 4: What does not work
Five operator myths that the catalog refutes by construction:
- **"Rotating krbtgt closes AD CS."** Wrong. Rotating krbtgt closes the symmetric KDC key; it does not touch the asymmetric CA private keys in `NTAuthCertificates`. An ESC1 certificate issued against the new krbtgt mints a Domain Admin TGT the same way it would have against the old one.
- **"Credential Guard protects against ESC."** Wrong. [Credential Guard's LSAISO](/blog/the-empty-hash-credential-guard-the-lsaiso-trustlet-and-the-/) isolates LSASS-resident credentials from the rest of the OS. AD CS abuse does not touch LSAISO; the certificate is issued by the CA against a request submitted over a network protocol. The credential never leaves the attacker's machine in a form Credential Guard could isolate.
- **"Disabling Web Enrollment closes AD CS."** Partial. Disabling the AD CS Web Enrollment role service closes ESC8 (the HTTP relay primitive). It does not affect ESC1 through ESC7 (template, ACL, and CA-config attacks), ESC11 (RPC relay), or any of the mapping ESCs. The default RPC enrollment transport on every Enterprise CA is unaffected.
- **"If we patch CVE-2022-26923 we're done."** Wrong. CVE-2022-26923 closes the specific `dNSHostName` machine-account-impersonation chain. It does not close ESC1, ESC4, or any of the configuration ESCs that the same operator chain could have taken.
- **"Reset krbtgt twice and we have evicted the attacker."** Wrong. The double-krbtgt-reset playbook is well-suited for Golden Ticket eviction. It is not effective against an attacker who has issued a long-validity authentication certificate from a CA the attacker controls or has compromised. The issued certificate authenticates against the new krbtgt the same way it did against the old one, because PKINIT does not bind the certificate's authority to the symmetric krbtgt key.
Run Locksmith this week. Tag NTAuth CAs as Tier Zero in BloodHound. Schedule the Lane 3 rebuild playbook before you need it. The catalog grew faster than the patches; the defender's only working strategy is parallel work in all four lanes.
## 11. Frequently Asked Questions
The SID extension is on by default for any CA running an OS that has installed KB5014754 or later. The catch is what the *KDC* does with that extension. Switching the KDC to Full Enforcement breaks every certificate that lacks the SID extension, which is why Microsoft built the three-mode staged rollout: the §7 timeline anchors the compatibility window (mechanics and the Feb 11, 2025 / Sep 9, 2025 milestones), and the §9 Callout carries the verbatim KB5014754 dates and the customer compatibility-friction set (legacy SCEP, Intune PKCS, non-Microsoft PKI, third-party smart cards). ESC16 closes the loop in the other direction: an admin (or a compromised admin) can re-disable the extension at the CA level, recreating the weak-mapping condition KB5014754 was designed to close.
Partially. The on-premises ESC catalog enumerates misconfigurations of the on-premises AD CS role. Entra Cloud PKI is a Microsoft-operated SaaS CA whose substrate is not the on-premises AD CS Windows role at all -- so ESCs that abuse on-premises CA registry flags (ESC6, ESC16), on-premises CA DACLs (ESC5, ESC7), or the on-premises transport (ESC8, ESC11) do not transfer directly. But Cloud PKI still issues authentication certificates, still has a template-equivalent administrative surface, and still maps certificates onto AD or Entra principals. The community has not yet published a Cloud PKI ESC catalog; the open question is whether the cross-product of Cloud PKI's primitive surface and its mapping behavior has its own equivalent class of named misconfigurations.
No. A two-tier hierarchy improves protection of the *root* CA's private key (the root signs only the subordinate's certificate and stays offline) but does nothing for the subordinate. The ESC catalog attacks the issuing subordinate, not the root. The misconfigured Enrollee-Supplies-Subject template, the editable `EDITF_ATTRIBUTESUBJECTALTNAME2` registry flag, the per-template DACL, the NTLM-relayable Web Enrollment endpoint -- all live on the subordinate CA. A two-tier hierarchy is the right architecture and is essentially orthogonal to the ESC discussion.
No. Smart cards are *consumers* of certificates issued by AD CS; the smart-card pipeline reads a certificate off the card, presents it to PKINIT, and receives a TGT. AD CS is the *issuing* substrate. Every ESC attacks the issuance side. A smart-card deployment depends on AD CS being correctly configured; it adds no defense against ESC1 through ESC16 and may add complexity in the strong-mapping migration (smart-card-issued certificates may use legacy mappings that break under Full Enforcement).
No. BloodHound CE does not ship a numbered `ADCSESC8` edge. It ships `CoerceAndRelayNTLMToADCS`, an edge representing "a computer can be SMB-coerced to authenticate to an attacker host, and the attacker host can relay that authentication to an ESC8-vulnerable Web Enrollment endpoint on a CA" [@bh-coerce-adcs-edge]. Look for that edge, not for a numbered ESC8 edge. If `CoerceAndRelayNTLMToADCS` paths exist anywhere in the graph, your Web Enrollment endpoint is ESC8-exposed and the operator chain from any coercible computer to a Domain Admin authenticator runs in eight minutes.
ESC12 is treated in the §5 Aside: Knobloch's October 2023 YubiHSM hardware-substrate disclosure (earliest Wayback snapshot dated October 24, 2023), scoped out of the body because the abuse depends on the specific HSM vendor and on shell access to the CA host [@knobloch-esc12] [@knobloch-esc12-archive]. ESC0 does not exist in the SpecterOps catalog; some operator blogs use "ESC0" informally to describe naive enumeration (no abuse, just "the CA is reachable and the template store is readable") but it is not a community-named technique.