Parag Mali - tag: red-team

SYSTEM in Ten Seconds: How the Potato Family Survived Every Microsoft Mitigation

noreply@paragmali.com (Parag Mali) — Sun, 31 May 2026 00:00:00 GMT

The Potato family is a decade of Windows local privilege escalation, eleven named variants disclosed between January 2016 (HotPotato) and August 2024 (FakePotato), all pivoting on the same primitive: `SeImpersonatePrivilege` (introduced as a defined user right in the Windows 2000 SP4 / XP SP2 / Server 2003 hardening cycle [@msrc-token-kidnapping; @ms-impersonate-policy]) plus `ImpersonateNamedPipeClient` (a Win32 primitive documented as supported since Windows XP for clients and Windows Server 2003 for servers [@ms-impersonate-api]). Each variant -- HotPotato (January 2016), RottenPotato, JuicyPotato, RoguePotato, PrintSpoofer, RemotePotato0, JuicyPotatoNG, GodPotato (the 2026 default), LocalPotato (CVE-2023-21746), SilverPotato, FakePotato (CVE-2024-38100) -- defeats a specific Microsoft mitigation, but no mitigation closes the family. The structural reason is the MSRC Windows Security Servicing Criteria, which treats the `SeImpersonatePrivilege`-to-SYSTEM transition as a safety boundary, not a security boundary. The Potato class is therefore an architectural decision, not a bug.

1. A Web Shell, Ten Seconds, SYSTEM

A red teamer drops a web shell on an Internet Information Services server running as IIS APPPOOL\DefaultAppPool. Ten seconds later, the shell prints nt authority\system. The operator did not exploit a memory-corruption bug, did not bypass a kernel security boundary, did not even use an undocumented API. They invoked CoCreateInstance against a Distributed COM (DCOM) class identifier, waited for the SYSTEM-context RPCSS service to authenticate to a named pipe they owned, and called ImpersonateNamedPipeClient [@ms-impersonate-api]. Every step was documented Win32 behaviour. The exploit is that Microsoft has spent a decade refusing to call any of those steps a security boundary [@msrc-servicing-criteria; @troopers24].

The artefact in the operator's hand is one of several. In May 2026 it is most likely GodPotato.exe -cmd "cmd /c whoami" -- a single Apache 2.0-licensed binary that BeichenDream published on GitHub on December 23, 2022 [@beichendream-god]. The README says it works on every supported Windows release from Windows 8 through Windows 11, and from Server 2012 through Server 2022 [@beichendream-god]. Community testing has since extended the working range to Server 2025 with default Distributed COM hardening enabled [@compass-three-headed].

A Windows user-rights assignment that lets a thread substitute another user's security context for its own (typically via `ImpersonateNamedPipeClient` or `ImpersonateLoggedOnUser`). Granted by default to `LOCAL SERVICE`, `NETWORK SERVICE`, every Internet Information Services application-pool identity, and most service accounts [@ms-impersonate-policy]. Introduced as a defined user right in the Windows 2000 SP4 / XP SP2 / Server 2003 service-hardening cycle that MSRC discusses in its 2009 Token Kidnapping retrospective [@msrc-token-kidnapping], after which possessing it has been one named-pipe round-trip away from being SYSTEM.

The IIS context matters. The default application-pool identity holds SeImpersonatePrivilege because IIS depends on it for legitimate request-scoped impersonation [@itm4n-printspoofer]. So does the default SQL Server service account, the Background Intelligent Transfer Service (BITS) account, the Spooler service account, and every account that hosts a Windows service that may need to "act as" a calling user. Anyone who can run code inside one of those accounts can run code as SYSTEM in seconds.

Note: Every step the operator takes -- CoCreateInstance, the SYSTEM-context RPCSS authentication, ImpersonateNamedPipeClient, the subsequent CreateProcessWithToken -- is in Microsoft's published Win32 contract [@ms-impersonate-api; @ms-dcom-spec]. None of them is a memory-corruption bug. The "exploit" is the existence of a documented call sequence that turns a service account into SYSTEM, on a fully-patched Windows 11 box, in 2026.

This is the puzzle the rest of the article is here to solve. The technique has been a one-binary operation for nearly a decade [@troopers24]. Microsoft has shipped three named hardening waves against it (a 2019-2020 OXID-resolver fix [@forshaw-pz-2021]; the three-phase CVE-2021-26414 Distributed COM hardening rollout from June 2021 to March 2023 [@ms-kb5004442]; and per-variant CVE patches in 2023 and 2024 [@nvd-cve-2023-21746; @nvd-cve-2024-38100]). None of those waves closed the family. Why?

2. The Architectural Primitive

The answer is in a Microsoft document called the Windows Security Servicing Criteria [@msrc-servicing-criteria]. It defines what Microsoft will and will not service as a security vulnerability. Quoting the document directly: "A security boundary provides a logical separation between the code and data of security domains with different levels of trust" [@msrc-servicing-criteria]. The page then lists the boundaries Microsoft has defined for Windows -- kernel mode versus user mode, virtual machine versus host, session versus session, and so on. The list is the enumeration that decides which bug classes get CVEs and which do not.

The Potato family pivots on a transition that is conspicuously not on the list: a service account that holds SeImpersonatePrivilege becoming SYSTEM. As Andrea Pierini and Antonio Cocomazzi articulated in the Troopers 24 retrospective, Microsoft's published position is that the Windows Service Hardening boundary is a safety boundary rather than a security boundary, which is why so many Potato exploits continue to work on fully updated Windows systems [@troopers24]. WSH is Microsoft's own shorthand for Windows Service Hardening -- the family of post-XP-SP2 protections that isolate service accounts from one another. The position is consistent with everything Microsoft has shipped: per-variant patches when a specific vehicle becomes too embarrassing, and silence on the underlying primitive. (The verbatim Troopers 24 articulation appears in §13.)

The boundary *definition* on `microsoft.com/en-us/msrc/windows-security-servicing-criteria` is rendered in static HTML and can be fetched directly [@msrc-servicing-criteria]. The boundary *enumeration table* immediately below it, which lists the bug classes that do and do not get CVEs, is JavaScript-rendered and does not appear in static fetches. The community-canonical secondary source for what is on that list is the Troopers 24 talk by Pierini and Cocomazzi [@troopers24], cross-referenced against James Forshaw's Project Zero retrospective from October 2021 [@forshaw-pz-2021] and Mark Russinovich's `aka.ms/win-security-boundaries` paraphrase. This article cites the primary for the definition and the Troopers retrospective for the enumeration.

Three primitives, taken together, mechanically determine the entire family. Once they are stated, the only remaining question is which SYSTEM-context service is cheapest to coerce.

Primitive one: SeImpersonatePrivilege

SeImpersonatePrivilege is a Windows user-rights assignment that permits a thread to call ImpersonateNamedPipeClient, ImpersonateLoggedOnUser, and the related impersonation APIs [@ms-impersonate-policy]. By Windows default, it is granted to LOCAL SERVICE, NETWORK SERVICE, every Internet Information Services application-pool identity, and most service accounts that need to act on behalf of clients [@itm4n-printspoofer]. (For when the right was introduced and a working definition, see §1; Decoder's one-sentence summary of what the grant means in practice is the climactic PullQuote in §6.3.)

Primitive two: ImpersonateNamedPipeClient

A Win32 API that lets the server end of a named pipe adopt the security context of whoever just connected to that pipe. After the call, the calling thread holds an impersonation token for the client identity, and any subsequent system call (including `CreateProcessWithToken`) executes as that identity. The function has been part of `namedpipeapi.h` since Windows XP for clients and Windows Server 2003 for servers, with no deprecation notice as of the 2025-07-01 documentation revision [@ms-impersonate-api].

The mechanism is exactly the one a SYSTEM-context service uses for legitimate request-scoped impersonation. The Potato class subverts it by getting a SYSTEM-context service to connect to a pipe the attacker owns. No memory corruption, no kernel exploit, no undocumented API. The Win32 reference describes the call as the standard way for a pipe server to "impersonate the client end" [@ms-impersonate-api].

Primitive three: the MSRC servicing-criteria carve-out

The third primitive is policy, not code. The MSRC document distinguishes a security boundary (whose violation gets a CVE and a security update) from a safety boundary (where Microsoft will patch when convenient but does not commit to a service-level objective). The defensible reading, articulated explicitly by Pierini and Cocomazzi at Troopers 24, is that the SYSTEM-from-SeImpersonate transition lives on the safety side [@troopers24]. The implication is structural: a service account holding SeImpersonatePrivilege "is already privileged" in Microsoft's policy view. Promoting it to SYSTEM is therefore not a privilege escalation that requires a security update.

flowchart LR A[Service account with SeImpersonatePrivilege] --> B[Coerce SYSTEM-context service to connect to attacker-owned named pipe] B --> C[Call ImpersonateNamedPipeClient on server thread] C --> D[Thread now holds SYSTEM impersonation token] D --> E[CreateProcessWithToken spawns SYSTEM process] F[MSRC servicing criteria carve-out] -.->|"Allows step A to remain a default grant"| A F -.->|"Allows step C to remain a documented Win32 API"| C

Taken together, the three primitives reduce the entire Potato family to a single problem statement: find the cheapest SYSTEM-context service to coerce into a callback. Every named variant since 2016 is an answer to that problem.

Key idea: Microsoft does not consider the SeImpersonatePrivilege-to-SYSTEM transition a security boundary; it considers it a safety boundary. The Potato family is the consequence. Variants change vehicles -- NetBIOS spoofing, BITS DCOM, Print Spooler RPC, EFS RPC, RPCSS OXID, ShellWindows -- but every one of them lives on the same architectural carve-out [@troopers24; @msrc-servicing-criteria].

The phrase aka.ms/win-security-boundaries was popularised by Mark Russinovich's Channel 9 talks of the late 2010s. Channel 9 was retired on December 1, 2021, so the link is now mostly cited as a memorable handle for the boundary list rather than as a clickable URL. The live equivalent is the MSRC servicing criteria document itself [@msrc-servicing-criteria].

Given primitives this old and this widely default-granted -- both the named-pipe impersonation API and the SeImpersonatePrivilege user right have been in their current form since the Windows 2000 SP4 / Server 2003 / XP SP2 service-hardening cycle [@msrc-token-kidnapping; @ms-impersonate-policy; @ms-impersonate-api] -- the natural question is why the named Potato family did not appear until 2016. The next section is the answer.

3. The Long Pre-Potato Era, 2001-2015

In March 2008, Cesar Cerrudo stood on a stage in Dubai at Hack-in-the-Box and demonstrated that a SYSTEM-context Windows service holding SeImpersonatePrivilege was, in effect, one named-pipe call away from SYSTEM [@cerrudo-hitb-slides; @msrc-token-kidnapping]. Microsoft acknowledged the technique on the MSRC blog on April 14, 2009, and shipped MS09-012 -- the patch Cerrudo later nicknamed "Chimichurri" in his Black Hat USA 2010 follow-up [@msrc-token-kidnapping; @blackhat-2010-cerrudo]. Cerrudo extended the work two years later at Black Hat USA 2010 in a paper titled "Token Kidnapping's Revenge" [@blackhat-2010-cerrudo]. Microsoft patched the specific NetworkService-to-SYSTEM vehicle. They did not revoke the privilege from the service accounts that held it [@msrc-token-kidnapping].

That pattern -- patch the vehicle, leave the primitive -- is the family's bequest from Cerrudo.

NTLM **relay** forwards an NTLM authentication captured from victim A to a different server B, where the attacker authenticates as A. NTLM **reflection** is the special case where B is the same machine (often the same protocol) as A. Microsoft fixed the most obvious same-protocol case with MS08-068 in 2008 [@ms-ms08-068]. Cross-protocol reflection (HTTP-to-SMB, DCOM-to-RPC) was not closed by that patch and became the doorway through which the Potato family entered.

Seven years before Cerrudo, on March 31, 2001, Sir Dystic of the Cult of the Dead Cow stood on a different stage at @lanta.con in Atlanta and released SMBRelay, the first public same-protocol NTLM relay tool [@cultdeadcow-smbrelay]. Microsoft eventually responded with MS08-068, a same-protocol-only fix [@ms-ms08-068]. Cross-protocol relay -- HTTP to SMB, DCOM to local RPC -- remained open.

That opening was the canvas James Forshaw painted on. In December 2014, then at Google Project Zero, Forshaw filed Issue 222 ("Windows: Local WebDAV NTLM Reflection EoP") demonstrating that the WebClient service performs NTLM authentication when asked to open a WebDAV URL, and that the resulting NTLM session can be reflected cross-protocol to the local SMB service [@forshaw-pz-2021]. A few months later Forshaw filed Issue 325, showing that CoGetInstanceFromIStorage could coerce a DCOM activation into authenticating to an attacker-controlled TCP endpoint. Microsoft patched the 2015 issue as CVE-2015-2370 [@nvd-cve-2015-2370]. In his October 2021 retrospective Forshaw wrote, with the laconic precision of a researcher whose contributions are still being weaponised seven years later:

The technique to locally relay authentication for DCOM was something I originally reported back in 2015 (issue 325). This issue was fixed as CVE-2015-2370, however the underlying authentication relay using DCOM remained. This was repurposed and expanded upon by various others for local and remote privilege escalation in the RottenPotato series of exploits. -- James Forshaw, Project Zero, October 2021 [@forshaw-pz-2021]

Cerrudo nicknamed the MS09-012 patch "Chimichurri" after the Argentine green sauce, and used the name when he reprised the work at Black Hat USA 2010 [@blackhat-2010-cerrudo]. Cerrudo was at Argeniss and later IOActive when he developed the technique [@msrc-token-kidnapping; @blackhat-2010-cerrudo].

The primary artefact for Cerrudo's March 2008 Hack-in-the-Box Dubai talk (slides, video, abstract) is no longer reachable on the conference site; the MSRC blog's retrospective is the canonical secondary that anchors the date and venue [@msrc-token-kidnapping]. The Black Hat USA 2010 "Token Kidnapping's Revenge" whitepaper [@blackhat-2010-cerrudo] is the durable primary for the underlying technique.

gantt title Pre-Potato lineage 2001-2015 dateFormat YYYY-MM section NTLM relay SMBRelay (Sir Dystic) :a1, 2001-03, 1M MS08-068 same-protocol fix :a2, 2008-10, 1M section Token escalation Token Kidnapping HITB Dubai (Cerrudo) :b1, 2008-03, 1M MS09-012 Chimichurri :b2, 2009-04, 1M Token Kidnapping's Revenge (Cerrudo) :b3, 2010-07, 1M section DCOM primitive Project Zero Issue 222 (Forshaw) :c1, 2014-12, 1M Project Zero Issue 325 (Forshaw) :c2, 2015-04, 1M CVE-2015-2370 patch :c3, 2015-07, 1M

By the end of 2015 the three pieces were on the table. A long-standing default privilege grant (Cerrudo's "SeImpersonate equals SYSTEM" thesis). A specific cross-protocol reflection technique (Forshaw's WebDAV-to-SMB Issue 222). A specific DCOM-activation coercion primitive (Forshaw's CoGetInstanceFromIStorage Issue 325). Microsoft had patched the literal bug in the third piece and explicitly declined to revoke the privilege in the first. The technique was published, the proof-of-concept code was on GitHub, and the family was a binary release away. The next chapter is the moment someone shipped the binary.

4. HotPotato, January 16, 2016

On January 16, 2016, Stephen Breen of Foxglove Security published a blog post titled "Hot Potato" [@foxglove-hotpotato]. He had just spoken at ShmooCon. The repository, foxglovesec/Potato, would land on GitHub three weeks later, on February 9, 2016 [@foxglove-potato-repo]. The post's opening sentence is the family's birth certificate:

Hot Potato (aka: Potato) takes advantage of known issues in Windows to gain local privilege escalation in default configurations, namely NTLM relay (specifically HTTP->SMB relay) and NBNS spoofing. -- Stephen Breen, Foxglove Security, January 16, 2016 [@foxglove-hotpotato]

Breen had not invented NTLM reflection. He had combined three existing primitives into a single-binary, one-click privilege escalation that worked on every default Windows install from Windows 7 through Server 2012 [@foxglove-hotpotato]. The Foxglove post acknowledges the lineage explicitly: "a similar technique was disclosed by the guys at Google Project Zero ... In fact, some of our code was shamelessly borrowed from their PoC" [@foxglove-hotpotato].

How HotPotato works

The exploit chains three independent tricks. Step one is UDP-port exhaustion. The tool opens enough UDP sockets that the local NetBIOS Name Service (NBNS) name lookups fail, forcing Windows to fall back to broadcast-based name resolution [@foxglove-hotpotato]. Step two is NBNS spoofing of the WPAD hostname, pointed at 127.0.0.1. Step three is the actual reflection: when Windows Update or Windows Defender polls for an update, it consults the WPAD URL, gets the attacker's proxy auto-configuration script, and routes its HTTP requests through the attacker's local listener -- which then relays the SYSTEM-context NTLM negotiation to the local SMB service [@foxglove-hotpotato].

sequenceDiagram participant Atk as Hot Potato tool participant NBNS as NetBIOS Name Service participant WU as Windows Update (SYSTEM) participant WPAD as WPAD HTTP listener (attacker) participant SMB as Local SMB service Atk->>NBNS: UDP-flood to exhaust ports and force broadcast Atk->>NBNS: Spoof WPAD hostname pointing at 127.0.0.1 WU->>WPAD: GET wpad.dat over HTTP WPAD-->>WU: Attacker-supplied proxy auto-config WU->>WPAD: HTTP request with SYSTEM-context NTLM negotiate WPAD->>SMB: Reflect the NTLM exchange to local SMB SMB-->>Atk: SMB session authenticated as SYSTEM Atk->>Atk: ImpersonateNamedPipeClient and spawn SYSTEM shell

The result was a single binary that produced a SYSTEM shell from any local user account on the target host -- because on a default Windows install every authenticated local user can run code, open UDP sockets, and bind a loopback HTTP listener, which is all HotPotato needs to bootstrap.

Note: HotPotato does not use Distributed COM activation at all. It uses NetBIOS spoofing, WPAD hijacking, and HTTP-to-SMB cross-protocol relay. The family is named for HotPotato but the defining primitive of every later variant -- DCOM activation -- is absent. HotPotato is in the family because it pivots through the same SeImpersonatePrivilege plus named-pipe-impersonation core, which is the actual definition of the family. The repository name Potato and the family naming convention are both Breen's [@foxglove-potato-repo].

The naming pattern that has now produced eleven variants started with the GitHub repository name foxglovesec/Potato [@foxglove-potato-repo]. Breen later wrote that "Hot" was a riff on the fact that the SYSTEM token was passed around like a hot potato; the suffix convention spread from there organically.

Why HotPotato did not last

HotPotato had three structural weaknesses. NetBIOS spoofing is unreliable: the UDP-port exhaustion can fail under load, group policy can pin a real WPAD URL, and a legitimate WPAD response can win the race. NetBIOS is disabled in security-hardened environments as a matter of routine. And the HTTP-to-SMB cross-protocol path was the very thing Extended Protection for Authentication and SMB channel-binding tokens were designed to close [@crowdstrike-drop-mic]. On a Windows 10 1607 host with EPA on the SMB server, HotPotato failed.

Researchers needed a coercion vehicle that was deterministic, did not rely on broadcast spoofing, and used a protocol Microsoft had not yet hardened end-to-end. Forshaw's Project Zero Issue 325 -- the CoGetInstanceFromIStorage DCOM trigger -- met all three criteria [@forshaw-pz-2021]. The next variant weaponised it.

5. The DCOM-Activation Breakthrough, 2016-2018

5.1 RottenPotato (DerbyCon 6, September 2016)

Eight months after HotPotato, Stephen Breen returned with a co-author and a new vehicle. The talk was on September 23, 2016 -- the Friday of DerbyCon 6 -- and the blog post followed three days later [@foxglove-rottenpotato]. The Foxglove post identifies the co-author by name: "myself and my partner in crime, Chris Mallz (@vvalien1) spoke at DerbyCon about a project we've been working on for the last few months" [@foxglove-rottenpotato].

Many secondary sources credit Andrea Pierini (Decoder) as the RottenPotato co-author. The Foxglove primary disproves this verbatim [@foxglove-rottenpotato]. Decoder enters the family lineage two years later, with JuicyPotato in 2018 [@ohpe-juicy]. Chris Mallz is the actual RottenPotato co-author.

RottenPotato replaced HotPotato's NetBIOS-and-WPAD chain with Forshaw's DCOM-activation primitive. The hard-coded target was the Background Intelligent Transfer Service (BITS) Distributed COM server, class identifier {4991d34b-80a1-4291-83b6-3328366b9097}, and the hard-coded listener port was 127.0.0.1:6666 [@foxglove-rottenpotato; @foxglove-rotten-repo].

A Win32 OLE function that instantiates a Distributed COM object using a marshalled `IStorage` interface pointer as the activation source. By marshalling an `IStorage` whose object exporter identifier (OXID) resolves to an attacker-controlled TCP endpoint, the activator can redirect the resulting authentication callback to a listener it owns. Forshaw filed this as Project Zero Issue 325 in 2015 [@forshaw-pz-2021]; RottenPotato weaponised it. sequenceDiagram participant Atk as RottenPotato (service account) participant Pipe as Local listener on 127.0.0.1:6666 participant DCOM as DCOM activation (RPCSS) participant BITS as BITS COM server (SYSTEM) participant RPC as Local RPC on port 135 Atk->>Pipe: Start TCP listener on 127.0.0.1:6666 Atk->>DCOM: CoGetInstanceFromIStorage with BITS CLSID and marshalled IStorage DCOM->>BITS: Spawn BITS under SYSTEM context BITS->>Pipe: Callback to the marshalled endpoint Pipe->>RPC: Forward COM packets to local RPC on port 135 RPC-->>Pipe: Reply containing SYSTEM-context NTLM exchange Pipe-->>Atk: SYSTEM authentication captured Atk->>Atk: ImpersonateNamedPipeClient and CreateProcessWithToken

The technique was 100% reliable on Windows 7 through Windows 10 1803 and Server 2008 R2 through Server 2016 [@foxglove-rottenpotato]. There was no broadcast spoofing on the wire, no race condition, and no dependence on Windows Update polling. The price was rigidity: the hard-coded BITS class identifier and port 6666 made the tool brittle to BITS being disabled, and the original release depended on the Metasploit framework.

5.2 RottenPotatoNG and lonelypotato

In December 2017, the user breenmachine published RottenPotatoNG, a C++ port that removed the Metasploit dependency: "New version of RottenPotato as a C++ DLL and standalone C++ binary - no need for meterpreter or other tools" [@breenmachine-rottenng]. The codebase that JuicyPotato would later generalise was now in place.

Many surveys date the `decoder-it/lonelypotato` variant to "early 2018" and place it as the link between RottenPotatoNG and JuicyPotato. The GitHub REST API reports `created_at: 2020-02-08T16:30:00Z` for the repository [@decoder-lonely], a full two years later. Decoder's first appearance in the Potato lineage is actually the December 6, 2019 post "We thought they were Potatoes but they were Beans" [@decoder-beans], with `lonelypotato` arriving in February 2020 as a post-OXID-hardening cleanup variant adjacent to RoguePotato [@decoder-lonely]. The 2017-2018 attribution is a citation error that has propagated across several survey papers.

5.3 JuicyPotato (Pierini + Trotta, July-August 2018)

What if any class identifier, not just the BITS one, could be the activation target? On July 27, 2018, Andrea Pierini and Giuseppe Trotta published the answer. The repository ohpe/juicy-potato was created that day per the GitHub REST API; the blog post followed on August 10, 2018 [@ohpe-juicy]. The repository description reads: "Juicy Potato (abusing the golden privileges) -- A sugared version of RottenPotatoNG, with a bit of juice" [@ohpe-juicy].

The original JuicyPotato blog post at decoder.cloud/2018/08/10/juicy-potato-abusing-the-golden-privileges/ returns HTTP 404 in 2026, and no Wayback Machine snapshot exists for that exact URL. The ohpe/juicy-potato README is the live verbatim mirror of the title and the technique walkthrough [@ohpe-juicy]. Pierini's blog has reorganised several times; older posts that survive elsewhere on decoder.cloud include the October 2018 "No more Rotten/Juicy Potato" [@decoder-no-more-rotten] and the December 2019 "We thought they were Potatoes" [@decoder-beans].

JuicyPotato turned RottenPotato into a search engine. The README ships a per-Windows-version class identifier matrix: each row a Windows release, each column a CLSID that activates under SYSTEM context and implements the IMarshal interface [@ohpe-juicy]. The tool accepts a tunable listener port (replacing the hard-coded 6666), a tunable process-creation mode (CreateProcessWithToken for SeImpersonate holders, CreateProcessAsUser for SeAssignPrimaryToken holders, or both), and a TEST mode for class-identifier discovery [@ohpe-juicy].

Microsoft does not freeze the set of registered Distributed COM class identifiers across Windows builds. Default COM-server registrations change between releases as components are added, removed, or refactored. A class identifier that activates under SYSTEM on Windows 10 1709 may not exist on Server 2019. JuicyPotato's CLSID matrix is therefore not a static lookup table -- it is the precomputed result of an empirical per-build search [@ohpe-juicy]. Every red-team handbook published between 2018 and 2020 references this matrix; subsequent variants (RoguePotato, JuicyPotatoNG) inherit and update it. flowchart TD A[Enumerate registered DCOM CLSIDs on target build] --> B{"For each CLSID"} B --> C[Attempt CoGetInstanceFromIStorage with marshalled IStorage] C --> D{"Activation reaches attacker listener?"} D -->|No| B D -->|Yes| E{"Callback authenticates as SYSTEM?"} E -->|No| B E -->|Yes| F[Log CLSID into per-OS matrix] F --> B B --> G[Output: working CLSID for this Windows build]

The Potato class was now universal. From mid-2018 through 2019 it was the default tool in every red-team handbook, every Metasploit-adjacent post-exploitation cheat-sheet, and every penetration-testing certification's lab. Microsoft had noticed.

6. The Mitigation Arms Race, 2020-2024

Every subsection below is the same shape: Microsoft ships a mitigation, researchers find a counter-move, MSRC produces an artifact (a CVE, a "Won't Fix" decision, or silence), and the architectural reading gets one more empirical confirmation.

6.1 The first Distributed COM mitigation, 2019-2020

In late 2018, Windows 10 1809 and Server 2019 began shipping a change to RPCSS. JuicyPotato stopped working. Researchers who reverse-engineered the change discovered that the OXID resolver address on the local Distributed COM activation path was now hard-coded to 127.0.0.1:135. The marshalled IStorage callback could no longer be redirected to an arbitrary loopback port. Forshaw described it bluntly three years later:

Being able to redirect the OXID resolver RPC connection locally to a different TCP port was not by design and Microsoft eventually fixed this in Windows 10 1809/Server 2019. -- James Forshaw, October 2021 [@forshaw-pz-2021]

No CVE was assigned. The change shipped silently as part of the regular Patch Tuesday cycle [@forshaw-pz-2021]. Pierini and Cocomazzi tested it on their own workloads and confirmed the failure mode publicly in October 2018: "Recently I downloaded the new Windows server 2019 and upgraded my Win10 box to 1809 ... the juicy/rotten exploit ... did not work on both OS" [@decoder-no-more-rotten].

Note: The 2019-2020 OXID-resolver change is the first Microsoft response to the Potato family. It does not declare Distributed COM activation a security boundary. It narrows the resolver port to 135 and leaves the underlying primitive (coerce SYSTEM context via OXID resolver, then impersonate the resulting token) intact. The mitigation defines exactly one specific bypass; researchers had to discover that themselves [@forshaw-pz-2021; @decoder-no-more-rotten].

6.2 RoguePotato (Cocomazzi + Pierini, May 2020)

On May 10, 2020, Antonio Cocomazzi published the RoguePotato repository on GitHub [@antonio-rogue]. The disclosure post appeared the next day, May 11. The README banner is "RoguePotato @splinter_code & @decoder_it" -- the same Pierini-and-Cocomazzi team that goes on to author RemotePotato0, JuicyPotatoNG, LocalPotato, and SilverPotato [@antonio-rogue].

The counter-move accepts the hard-coded port-135 constraint and works around it. RoguePotato is two pieces. On an attacker-controlled remote host, run a port forwarder that listens on TCP 135 and redirects to a chosen attacker port. On the target, run RoguePotato.exe pointing the OXID resolver at the remote forwarder. RPCSS dutifully sends the resolution request to the remote host on port 135 (since Microsoft hard-coded the port, not the host); the forwarder bounces the traffic back to the target on the attacker-chosen port; RoguePotato impersonates the OXID resolver and steers the activation back to a SYSTEM-context COM server [@antonio-rogue]. Standard NTLM relay and named-pipe impersonation finish the job.

flowchart LR A[RoguePotato.exe on target] --> B[RPCSS sends OXID resolution to remote-host port 135] B --> C[Remote port forwarder on attacker VPS] C --> D[Forward to target on attacker-chosen port] D --> E[Fake OXID resolver inside RoguePotato] E --> F[Steer activation to SYSTEM-context COM server] F --> G[Named-pipe impersonation, CreateProcessWithToken, SYSTEM shell]

{// Step 1 -- on an attacker-controlled remote host (any internet-reachable VPS): const forwarder = "socat tcp-listen:135,reuseaddr,fork tcp:10.0.0.3:9999"; // Step 2 -- on the target with SeImpersonatePrivilege: const exploit = 'RoguePotato.exe -r 10.0.0.3 -e "C:\\\\windows\\\\system32\\\\cmd.exe" -l 9999'; console.log("Remote forwarder:", forwarder); console.log("Target exploit :", exploit); console.log("Expected output : nt authority\\\\system");}

RoguePotato proved that the mitigation Microsoft chose did not break the underlying primitive. It only forced the attack to phone home. Two failure modes followed: in egress-filtered networks where outbound TCP 135 is blocked, the technique cannot run, and the remote forwarder is operationally noisy. Researchers needed a workaround that lived entirely on the target.

6.3 PrintSpoofer (Clément Labro, early May 2020)

Around the same time as RoguePotato, in early May 2020 (GitHub repository itm4n/PrintSpoofer created April 28, 2020; blog post first archived in the Wayback Machine on May 3, 2020), Clément Labro -- writing as itm4n -- published "PrintSpoofer -- Abusing Impersonation Privileges on Windows 10 and Server 2019" [@itm4n-printspoofer]. The mechanism uses no Distributed COM at all.

The Print Spooler service exposes an RPC call, RpcRemoteFindFirstPrinterChangeNotificationEx, that accepts a UNC path; the Spooler -- running as SYSTEM -- connects to that path to deliver printer-change notifications. Point the path at an attacker-owned named pipe; the Spooler connects; call ImpersonateNamedPipeClient; done [@itm4n-printspoofer]. Labro articulated the family's thesis statement in the post, attributing it to Decoder:

If you have SeAssignPrimaryToken or SeImpersonate privilege, you are SYSTEM. -- attributed to Andrea Pierini (@decoder_it), quoted by Clément Labro in the PrintSpoofer writeup, May 2020 [@itm4n-printspoofer] sequenceDiagram participant Atk as PrintSpoofer (SeImpersonate holder) participant Pipe as Attacker-owned named pipe participant Spooler as Print Spooler (SYSTEM) Atk->>Pipe: Create named pipe and start accept loop Atk->>Spooler: RpcRemoteFindFirstPrinterChangeNotificationEx with attacker UNC Spooler->>Pipe: Connect to UNC path under SYSTEM context Pipe->>Atk: ImpersonateNamedPipeClient on server thread Atk->>Atk: CreateProcessWithToken spawns SYSTEM shell

This is the moment the architectural reading clicks. The family is not about Distributed COM activation. Closing DCOM would not close the family. The next variant would use Spooler RPC, the one after that would use the Encrypting File System RPC, and the one after that would use Microsoft Distributed Transaction Coordinator RPC. Forshaw's contemporaneous April 2020 tiraniddo.dev post on shared logon sessions makes the same architectural point from a different angle [@forshaw-tiraniddo-2020].

Key idea: The Potato family is about the primitive, not the vehicle. SeImpersonatePrivilege plus ImpersonateNamedPipeClient plus any SYSTEM-context Windows service with a callback-style API equals SYSTEM. Closing one vehicle (Distributed COM activation) leaves every other vehicle (Spooler RPC, EFS RPC, the next service that gets a callback interface) wide open [@itm4n-printspoofer; @forshaw-tiraniddo-2020].

6.4 RemotePotato0 and the "Won't Fix"

In April 2021, Cocomazzi and Pierini pushed the technique across the network in a SentinelLabs post titled "Relaying Potatoes: DCE/RPC NTLM Relay EoP" [@sentinellabs-relaying]. The repository tagline names the outcome bluntly: "Just another 'Won't Fix' Windows Privilege Escalation from User to Domain Admin" [@antonio-remote].

The mechanism is cross-session NTLM relay over Distributed COM and RPC. An unprivileged local user triggers the Distributed COM activation service to make another user logged on the same machine (typically an administrator in an interactive RDP session) authenticate via NTLM. The captured NTLM exchange is then cross-protocol relayed (RPC to LDAP, with a port forwarder bridging the gap) to a domain controller with LDAP signing disabled. The attacker writes their own account into a privileged group or registers resource-based constrained delegation, and the engagement is over [@sentinellabs-relaying].

Microsoft's response is the most quoted sentence in the family's history:

The current status of this vulnerability is 'won't fix' ... Although Microsoft considers the vulnerability an important privilege escalation, it has been classified as 'Won't Fix'. -- SentinelLabs disclosure of RemotePotato0, April 2021 [@sentinellabs-relaying]

Note: RemotePotato0 was a fully working exploit chain that promoted any local low-privilege user to Domain Admin. Microsoft was given the disclosure, replicated the technique, and declined to issue a CVE. This is the moment the architectural reading stops being a researcher narrative and becomes a documented MSRC decision [@sentinellabs-relaying]. Microsoft eventually shipped a partial mitigation in October 2022 that broke the RPC-to-LDAP scenario specifically, but the underlying primitive survives in adjacent variants [@antonio-remote].

6.5 The CVE-2021-26414 Distributed COM hardening rollout

Two months after the RemotePotato0 disclosure, Microsoft began the only DCOM-side hardening it would ship under a CVE. KB5004442 documents a three-phase rollout, quoted verbatim from the article: "The first phase of DCOM updates was released on June 8, 2021. In that update, DCOM hardening was disabled by default. ... The second phase of DCOM updates was released on June 14, 2022. ... The final phase of DCOM updates will be released in March 2023. It will keep the DCOM hardening enabled and remove the ability to disable it" [@ms-kb5004442].

Phase	Date	Behaviour
Phase 1	June 8, 2021	DCOM hardening shipped, disabled by default. Administrators may opt in via registry.
Phase 2	June 14, 2022	Hardening enabled by default. Registry opt-out still available.
Phase 3	March 14, 2023	Hardening enforced with no opt-out. The `RPC_C_AUTHN_LEVEL_PKT_INTEGRITY` minimum is mandatory.

The RPC authentication-level constant that requires every packet of an RPC exchange to be signed for integrity (level 5 of 6). CVE-2021-26414 raises the *minimum* DCOM activation authentication level to this constant, rejecting legacy Distributed COM clients that activate at lower levels. The full rejection appears in Windows Event ID 10036 as "The server-side authentication level policy does not allow the user %1\\%2 SID (%3) from address %4 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application" [@ms-kb5004442].

The hardening raised the bar for legacy Distributed COM client authentication. It did not declare Distributed COM activation a security boundary [@ms-kb5004442; @ms-techcommunity-dcom]. The "Manage changes" framing in the KB title is deliberate: this is a compatibility migration with telemetry events (10036 server-side, 10037 and 10038 client-side) so enterprises can find legacy clients before the final cut [@ms-kb5004442].

Note: Distributed COM is everywhere in Windows. Removing the ability to activate at a lower authentication level breaks legacy Distributed COM applications that have not been updated since at least 2014. Microsoft's 21-month rollout window between Phase 1 (June 2021) and Phase 3 (March 2023) was a compatibility migration -- the telemetry events let enterprise IT find and fix the legacy clients before the final cut [@ms-kb5004442; @ms-techcommunity-dcom]. The hardening is the most aggressive Distributed COM mitigation Microsoft has ever shipped, and even so it does not declare Distributed COM activation a security boundary.

Researchers had 21 months to find a way around it. They took 18.

6.6 JuicyPotatoNG (Pierini + Cocomazzi, September 21, 2022)

Pierini and Cocomazzi returned on September 21, 2022, with JuicyPotatoNG -- the last pre-Phase-3 Distributed COM activation variant [@decoder-juicyng]. The blog post is titled "Giving JuicyPotato a second chance: JuicyPotatoNG" and walks through three counter-moves combined into a single binary [@decoder-juicyng; @antonio-juicyng].

First, the tool embeds Forshaw's October 2021 local-OXID trick. Forshaw had shown that an OXID resolution request could be answered by a local Distributed COM server on a randomly selected port, dropping the need for an external forwarder [@forshaw-pz-2021]. JuicyPotatoNG ships that trick as a default. Second, it falls back to a tight set of usable class identifiers; the default is {854A20FB-2D44-457D-992F-EF13785D2B51}, the PrintNotify class [@antonio-juicyng]. Third, it calls LogonUser with LOGON32_LOGON_NEW_CREDENTIALS to sidestep the INTERACTIVE-group restriction that constrained earlier post-RoguePotato attempts [@decoder-juicyng].

The cross-pollination is worth marking. Forshaw's October 2021 Project Zero post on relaying Distributed COM authentication described the local-OXID trick as a research result [@forshaw-pz-2021]. Pierini and Cocomazzi picked it up eleven months later and shipped it as the default mode of JuicyPotatoNG [@decoder-juicyng]. SilverPotato (April 2024) and the Compass Security follow-on (September 2024) cite the same trick [@compass-three-headed]. Forshaw's blog has been the unofficial reference implementation for the lineage's offensive primitives for half its lifetime.

JuicyPotatoNG also implements a Security Support Provider Interface (SSPI) hook on AcceptSecurityContext to capture the SYSTEM token without requiring RpcImpersonateClient. The effect is to make the tool work for both SeImpersonate and SeAssignPrimaryToken holders [@decoder-juicyng]. The result is a clean, single-binary, no-external-infrastructure local-DCOM-activation exploit -- which is the version that worked between Phase 2 (June 14, 2022, enabled by default) and Phase 3 (March 14, 2023, enforced with no opt-out) of the CVE-2021-26414 rollout [@ms-kb5004442].

The next variant would need to survive Phase 3.

6.7 GodPotato (BeichenDream, December 23, 2022)

Three months after JuicyPotatoNG, on December 23, 2022, the Chinese-speaking researcher BeichenDream published GodPotato to GitHub [@beichendream-god]. The README is bilingual English and Chinese, and it opens with a precise summary of where the variant fits in the lineage:

Based on the history of Potato privilege escalation for 6 years, from the beginning of RottenPotato to the end of JuicyPotatoNG, I discovered a new technology by researching DCOM, which enables privilege escalation in Windows 2012 - Windows 2022 ... There are some defects in rpcss when dealing with oxid, and rpcss is a service that must be opened by the system, so it can run on almost any Windows OS, I named it GodPotato. -- BeichenDream, GodPotato README, December 2022 [@beichendream-god]

The mechanism manipulates the OXID-handling flow inside RPCSS so the activated Distributed COM server's authentication callback returns to a tool-controlled endpoint without requiring the OXID resolver to be redirected. Because the redirect itself is what the CVE-2021-26414 hardening rejects, GodPotato sidesteps the hardening entirely [@beichendream-god]. RPCSS is a mandatory Windows service -- it cannot be disabled without breaking the operating system -- so the technique works on every supported Windows release as of disclosure.

{// On a target host where the calling account holds SeImpersonatePrivilege // (default for every IIS app-pool identity, MSSQL service account, BITS account, etc.) const command = 'GodPotato -cmd "cmd /c whoami"'; console.log("Run:", command); console.log("Expected output: nt authority\\\\system"); console.log("Working OS coverage: Windows 8 through Windows 11; Server 2012 through Server 2025"); console.log("Underlying primitive: RPCSS OXID-handling defect, no external infra, single binary");}

Microsoft has not assigned a CVE to the underlying RPCSS defect [@beichendream-god; @compass-three-headed].Apache 2.0 licensing matters here: red-team operators routinely recompile GodPotato from source to bypass binary-hash signatures, and the permissive license makes redistribution unproblematic [@beichendream-god]. The pattern is consistent with the servicing-criteria reading. GodPotato is in May 2026 the practitioner default on every in-support Windows release: single binary, no external infrastructure, no separate OXID resolver, Apache-2.0-licensed and freely re-buildable when EDR vendors signature the public binary [@beichendream-god].

Key idea: GodPotato survives every Microsoft mitigation because Microsoft has not declared the underlying primitive a security boundary. Three named hardening waves (the 2019-2020 OXID-resolver change, the three-phase CVE-2021-26414 rollout from June 2021 to March 2023, and the per-variant CVE patches in 2023 and 2024) leave GodPotato working on Server 2025 and Windows 11 24H2 as of this writing [@beichendream-god; @ms-kb5004442; @compass-three-headed].

6.8 LocalPotato and CVE-2023-21746

Three weeks after GodPotato landed, Microsoft assigned the first-ever CVE in the local Potato lineage. The variant was LocalPotato, the CVE was CVE-2023-21746, and the patch shipped in the January 2023 Patch Tuesday [@nvd-cve-2023-21746; @msrc-cve-2023-21746]. The Decoder writeup, published February 13, 2023, walks through the timeline:

"We reported our findings to the Microsoft Security Response Center (MSRC) on September 9, 2022, and it was resolved with the release of the January 2023 patch Tuesday and assigned the CVE number CVE-2023-21746." -- Andrea Pierini, "LocalPotato" writeup, February 2023 [@decoder-localpotato]

LocalPotato is not a Distributed COM activation Potato. It attacks the local NTLM authentication protocol itself. During a local NTLM exchange, the Type 2 (Challenge) message carries a "Reserved" field that, in the local-NTLM case, encodes the upper bytes of the local server context handle the client should associate with. By racing two simultaneous local NTLM authentications -- one privileged client to attacker server, one attacker client to a real local server -- and swapping the Reserved fields in the two Type 2 messages, LSASS binds the privileged identity to the attacker's low-privilege context [@decoder-localpotato; @localpotato-com]. The result is an arbitrary file-read and file-write primitive that chains cleanly to SYSTEM.

Note: Pierini and Cocomazzi had been pushing on the architectural carve-out for seven years before they got a CVE. The boundary that made the difference: LocalPotato attacks the local user-to-local-user NTLM authentication context, which is on the servicing-criteria boundary list. The underlying SeImpersonate-to-SYSTEM primitive is not. Microsoft will service the parts of the protocol that are inside the boundary; it will not service the parts that are outside [@decoder-localpotato; @msrc-servicing-criteria].

The LocalPotato writeup credits Elad Shamir for the original hint that started the research [@decoder-localpotato]. The dedicated companion site localpotato.com carries the canonical title "LocalPotato -- When swapping the context leads you to SYSTEM" and links the CVE [@localpotato-com].

6.9 SilverPotato (Pierini + Cocomazzi, April 24, 2024)

A year later, on April 24, 2024, Pierini and Cocomazzi extended the cross-session Distributed COM activation primitive that RemotePotato0 had pioneered into a fully practical domain attack. The blog post title is "Hello, I'm your domain admin and I want to authenticate against you" [@decoder-silverpotato]. The Troopers 24 abstract refers to the technique by its other name, ADCSCoercePotato [@troopers24; @decoder-adcs-coerce-repo]; both names refer to the same primitive.

The mechanism: members of the Distributed COM Users or Performance Log Users built-in groups can remotely trigger an NTLM authentication from any user currently logged on the target server -- including a Domain Administrator on a Domain Controller -- and relay it. The specific vehicle is the sppui Distributed COM application (class identifier F87B28F1-DA9A-4F35-8EC0-800EFCF26B83, "SPPUIObjectInteractive Class", hosted in slui.exe), which runs under the Interactive User identity [@decoder-silverpotato]. Pierini's wording in the post is unsparing:

"Members of Distributed COM Users or Performance Log Users Groups can trigger from remote and relay the authentication of users connected on the target server, including Domain Controllers." -- Andrea Pierini, "SilverPotato" writeup, April 2024 [@decoder-silverpotato]

The captured authentication is relayed via ntlmrelayx to AD CS Web Enrollment or LDAP, then chained with ForgeCert and Rubeus into a full Domain Admin Kerberos TGT [@decoder-silverpotato]. The Compass Security follow-on from September 2024 extends the chain further by modifying the KrbRelay project to make it remote and cross-session capable: "I modified the KrbRelay project to make it remote and cross-session capable, because Andrea did not release his PoC code ... DCOM hardening only allows relay to HTTP or unprotected LDAP" [@compass-three-headed]. Tianze Ding's Black Hat Asia 2024 talk on "CertifiedDCOM" landed in the same window [@blackhat-asia-2024]. Pierini's February 2024 post on the ADCS server side of the same surface foreshadowed the chain a few weeks earlier [@decoder-adcs-server].

flowchart LR A[Member of Distributed COM Users on target DC] --> B[Cross-session DCOM activation against sppui CLSID] B --> C[Logged-on Domain Admin session authenticates via NTLM] C --> D[ntlmrelayx forwards NTLM to AD CS Web Enrollment] D --> E[Computer-template certificate issued] E --> F[ForgeCert and Rubeus mint Domain Admin Kerberos TGT] F --> G[Domain compromise]

Note: The Troopers 24 abstract describes SilverPotato as "still in review by MSRC" as of June 2024 [@troopers24]. The Compass Security follow-on demonstrates a working end-to-end chain four months later [@compass-three-headed]. The default Distributed COM group memberships on Domain Controllers that grant the activation rights SilverPotato weaponises have not changed in any shipping Windows release as of May 2026. No CVE has been assigned [@decoder-silverpotato; @troopers24].

6.10 FakePotato and CVE-2024-38100

Four months after SilverPotato, on August 2, 2024, Pierini published the most recent named variant. He called it FakePotato, and he was up front about the name:

"You might be wondering why I called it the 'Fake' Potato. Initially, I thought it could be exploited using the same techniques as the *Potato families, but it turned out to be different and much simpler in this case." -- Andrea Pierini, "The Fake Potato" writeup, August 2024 [@decoder-fakepotato]

FakePotato abuses the ShellWindows Distributed COM application (AppID {9BA05972-F6A8-11CF-A442-00A0C90A8F39}), hosted in explorer.exe and registered to run under the Interactive User identity. Cross-session activation via BindToMoniker("session:N!new:<CLSID>") invokes ShellExecute in the target session. There is no NTLM relay, no token impersonation, no SeImpersonatePrivilege requirement -- any Authenticated User suffices because explorer.exe in High Integrity Level (UAC-disabled administrator) granted the Authenticated Users group execute permission via the DCOM Access Security ACL [@decoder-fakepotato].

{$obj = [System.Runtime.InteropServices.Marshal]::BindToMoniker("session:2!new:9BA05972-F6A8-11CF-A442-00A0C90A8F39") $p = $obj.item(0).document.application $p.ShellExecute("c:\\temp\\reverse.bat", "", "c:\\windows", $null, 0)}

Microsoft assigned CVE-2024-38100 and shipped the patch in the July 2024 Patch Tuesday cumulative updates on July 9, 2024 (KB5040434 for Windows 10 1607 / Windows Server 2016; equivalent KBs for Windows 11, Server 2019, Server 2022, and Server 2025) -- four weeks before the public disclosure [@decoder-fakepotato; @nvd-cve-2024-38100; @msrc-cve-2024-38100]. The patch corrects the explorer.exe ACL in High Integrity Level contexts so the Authenticated Users permission required for activation is no longer granted. The underlying cross-session Distributed COM activation primitive that SilverPotato and FakePotato share is untouched [@decoder-silverpotato; @decoder-fakepotato].

FakePotato is not, in the relay sense, a Potato at all. It is a misconfiguration of the ShellWindows Distributed COM application's permissions in High Integrity Level contexts [@decoder-fakepotato]. Pierini's "Fake" framing acknowledges the divergence from the NTLM-reflection pattern that defined the family from RottenPotato through GodPotato. The naming choice is itself a small piece of taxonomy: not every member of the family is a token-relay exploit, even if every member exploits the same architectural carve-out.

After nearly a decade of patching specific vehicles and refusing to declare the underlying primitive a boundary, Microsoft's pattern is hard to miss.

7. Eleven Variants at a Glance

Nine years of named-variant disclosures, eleven named variants, one architectural argument. The table below is sourced cell by cell from the preceding sections.

Variant	Date	Authors	Coercion vehicle	Mitigation it bypassed	Microsoft response	Still works in 2026?
HotPotato [@foxglove-hotpotato]	Jan 16, 2016	Stephen Breen	NBNS spoof + WPAD + HTTP-to-SMB relay	MS08-068 same-protocol-only fix	None named; EPA/SMB hardening eventually closed the vehicle	Only on pre-1607 builds
RottenPotato [@foxglove-rottenpotato]	Sep 23, 2016	Stephen Breen + Chris Mallz	DCOM activation via BITS CLSID on 127.0.0.1:6666	(none yet)	None	Only pre-1809 builds
RottenPotatoNG [@breenmachine-rottenng]	Dec 29, 2017	breenmachine	Same as RottenPotato (C++ port; no Metasploit)	(none yet)	None	Only pre-1809 builds
JuicyPotato [@ohpe-juicy]	Jul 27, 2018	Andrea Pierini + Giuseppe Trotta	Generalised DCOM activation; CLSID matrix	(none yet)	OXID-resolver hard-coding in Win10 1809 / Server 2019 [@forshaw-pz-2021]	Only pre-1809 builds
RoguePotato [@antonio-rogue]	May 10, 2020	Antonio Cocomazzi + Andrea Pierini	DCOM activation through remote TCP-135 forwarder	2019-2020 OXID-resolver hardening	None (no CVE)	Only pre-Phase-3 builds
PrintSpoofer [@itm4n-printspoofer]	Early May 2020	Clément Labro	Print Spooler RPC `RpcRemoteFindFirstPrinterChangeNotificationEx`	All DCOM-side hardening (irrelevant)	None (no CVE)	Yes, when Spooler is running
RemotePotato0 [@sentinellabs-relaying]	Apr 2021	Antonio Cocomazzi + Andrea Pierini	Cross-session DCOM/RPC NTLM relay	(defines a new threat surface)	"Won't Fix"; partial Oct 2022 RPC-to-LDAP mitigation	Partially (primitive intact)
JuicyPotatoNG [@antonio-juicyng; @decoder-juicyng]	Sep 21, 2022	Andrea Pierini + Antonio Cocomazzi	Local-OXID trick + LogonUser NewCredentials	CVE-2021-26414 Phase 1 and Phase 2	None (no CVE)	Only pre-Phase-3 builds
GodPotato [@beichendream-god]	Dec 23, 2022	BeichenDream	RPCSS OXID-handling defect (no resolver redirect)	All three CVE-2021-26414 phases	None (no CVE)	Yes -- the 2026 default
LocalPotato / CVE-2023-21746 [@decoder-localpotato; @nvd-cve-2023-21746]	Patched Jan 10, 2023	Andrea Pierini + Antonio Cocomazzi	NTLM Type-2 "Reserved" field context swap	(orthogonal -- attacks LSASS)	CVE-2023-21746 (first local-Potato CVE)	No -- patched
SilverPotato / ADCSCoercePotato [@decoder-silverpotato; @troopers24]	Apr 24, 2024	Andrea Pierini + Antonio Cocomazzi	Cross-session DCOM against `sppui` AppID	Post-RemotePotato0 partial mitigations	Still in review by MSRC as of mid-2026	Yes -- unpatched
FakePotato / CVE-2024-38100 [@decoder-fakepotato; @nvd-cve-2024-38100]	Disclosed Aug 2, 2024	Andrea Pierini	Cross-session DCOM against `ShellWindows` AppID (ACL bug)	(orthogonal)	CVE-2024-38100 in the July 2024 Patch Tuesday (KB5040434 for 1607/Server 2016; per-build KBs elsewhere)	No -- patched

Two CVEs in nine years of named-variant disclosures. One "Won't Fix" decision on a working Domain Admin escalation. Zero declarations of SeImpersonatePrivilege or Distributed COM activation as a security boundary. The pattern is consistent across every column [@troopers24; @msrc-servicing-criteria].

Key idea: Two CVEs in a decade, against a family with eleven named variants. The first CVE was for a piece of the local NTLM protocol that is on the servicing-criteria list, not for the underlying SeImpersonate-to-SYSTEM primitive. The second was for a Distributed COM access-control list misconfiguration, not for cross-session activation as a class. Microsoft will assign CVEs to specific vehicles when forced. It will not declare the architectural primitive a security boundary [@nvd-cve-2023-21746; @nvd-cve-2024-38100; @troopers24].

8. The 2026 Decision Surface

In May 2026, an operator with SeImpersonatePrivilege on a default Windows 11 box has a small menu of working tools, plus three legacy variants that remain useful on unpatched fleets. The current toolkit:

Method	Coercion vehicle	OS coverage	When to use it
GodPotato [@beichendream-god]	RPCSS OXID defect	Win 8 to Win 11; Server 2012 to Server 2025	Default first try on any in-support Windows
SweetPotato [@ccob-sweet]	Selectable: PrintSpoofer (default), DCOM, EfsRpc, WinRM	Win 7+ depending on selected mode	When GodPotato's binary signature is blocked
SharpEfsPotato [@bugch3ck-efs]	EFS RPC (`EfsRpcOpenFileRaw`)	Server 2019+, Win 10/11 with EFS RPC enabled	DCOM locked down and Spooler disabled
PrintSpoofer [@itm4n-printspoofer]	Print Spooler RPC	Any host with Spooler running	The lowest-noise option on Spooler-enabled hosts
JuicyPotatoNG [@antonio-juicyng]	Local-OXID + legacy CLSID	Pre-Phase-3 DCOM hardening only	Corporate fleets with delayed CVE-2021-26414 rollout
RoguePotato [@antonio-rogue]	Remote TCP-135 forwarder	Pre-Phase-3 DCOM hardening	Pre-2022 hardened-OXID-only systems with attacker remote infra
SilverPotato [@decoder-silverpotato]	Cross-session DCOM against DC	Default DCs with `Distributed COM Users` or `Performance Log Users` membership	Domain-tier escalation -- the only currently-unpatched cross-session variant

Plus three legacy variants worth knowing about: JuicyPotato on pre-1809 builds, RottenPotato on Server 2008 R2 / Windows 7 ESU-eligible builds, and HotPotato as the canonical naming origin and the source of the family's "documented Win32 calls" framing [@ohpe-juicy; @foxglove-rotten-repo; @foxglove-hotpotato]. Embedded Windows builds (Windows 10 IoT LTSC 2019, some industrial controllers, ATM images) frequently fall behind the OXID-resolver mitigation and remain JuicyPotato-vulnerable through 2026.

SharpEfsPotato's canonical repository is `github.com/bugch3ck/SharpEfsPotato` [@bugch3ck-efs]. A widely shared `ly4k/SharpEfsPotato` fork exists and is referenced in some red-team writeups, but the upstream is the `bugch3ck` repo per the README's own credit chain ("Built from SweetPotato by @\_EthicalChaos\_ and SharpSystemTriggers/SharpEfsTrigger by @cube0x0") [@bugch3ck-efs]. Operators citing the `ly4k` URL are pointing at a fork.

Every one of these tools has a Microsoft mitigation in its history. None of those mitigations closed the family. The next section asks what mitigation could.

9. What Would It Take To Close the Family?

A counterfactual sharpens the question. Suppose Microsoft decided in 2026 that the family must end. Three closure options exist, and each carries a compatibility cost.

Closure option	Mechanism	Compatibility cost
1. Declare `SeImpersonatePrivilege` a security boundary	Revoke the privilege from default service accounts (IIS app pools, SQL Server, BITS, Task Scheduler, the Spooler)	Operationally prohibitive: thousands of third-party services depend on the default grant
2. Declare Distributed COM activation a security boundary	Validate the activator's identity against the activated CLSID's registered identity on every activation	Breaks 25 years of legacy Distributed COM applications written between 1996 and 2021 [@ms-dcom-spec]
3. Deprecate `ImpersonateNamedPipeClient` as a Win32 primitive	Remove the call from `namedpipeapi.h` or gate it behind a Trustlet validation	Breaks parts of CSRSS, the console subsystem, and LSASS itself; no deprecation notice exists in the API reference as of mid-2026 [@ms-impersonate-api]

The CVE-2021-26414 hardening creeps toward option 2 for remote Distributed COM but explicitly does not for local Distributed COM [@ms-kb5004442]. The Adminless direction in Windows 11 24H2 -- Microsoft's "Administrator protection" platform feature, currently a preview shipped first via Windows Insider builds and not yet generally available [@ms-administrator-protection] -- introduces a per-application admin-elevation gate, but operates above the SYSTEM-impersonation primitive, not below it. Credential Guard isolates LSASS secrets in a Virtualization-Based Security Trustlet -- which protects NTLM hashes from extraction but does not gate ImpersonateNamedPipeClient or SeImpersonatePrivilege [@ms-credential-guard]. Smart App Control restricts arbitrary binary execution but does not block in-process exploitation by a SYSTEM-running service [@ms-smart-app-control].

The lower bound on attack cost is therefore O(1) per invocation, and it stays O(1) as long as the servicing-criteria carve-out holds. No combination of currently-shipping mitigations moves it.

Key idea: The Potato family is a fixed point of the current Windows architecture. Every closure option carries a compatibility cost that no currently-announced Microsoft release accepts. Until the MSRC Windows Security Servicing Criteria changes the position on SeImpersonatePrivilege and Distributed COM activation, the family's lower attack cost is O(1) and no servicing patch can move it [@msrc-servicing-criteria; @troopers24].

The claim is empirical, not formal. A "fixed point" in the algorithmic sense is a value where a function returns its own input. For the Potato family the analogue is: every Microsoft mitigation that does not change the servicing-criteria document returns a family that is still alive. The fixed-point status is consistent with eleven variants over nine years of named-variant disclosures (HotPotato January 2016 -> FakePotato August 2024) against three named hardening waves. It would be invalidated by a major-version Windows release that explicitly revoked the default `SeImpersonatePrivilege` grant on service accounts. No such release is on the public roadmap as of May 2026 [@msrc-servicing-criteria].

10. Open Problems

Five questions sit at the research frontier in 2026.

The next coercion vehicle. Each Potato variant is one SYSTEM-context service with a callback-style API. As the family has matured, researchers have mapped a growing surface of candidates: EFS RPC (which SharpEfsPotato already weaponises [@bugch3ck-efs]), Print Spooler async RPC (MS-PAR), Windows Search remote protocol (MS-WSP), and Microsoft Distributed Transaction Coordinator RPC. The community-empirical conjecture, repeated across Troopers 24 [@troopers24] and the Compass Security retrospective [@compass-three-headed], is that any SYSTEM-context Windows service with a callback-style API becomes a Potato vehicle within roughly eighteen months of operational need.

The "eighteen-month vehicle cadence" is an informal community claim, not a measured statistic. It originates in the Troopers 24 retrospective by Pierini and Cocomazzi [@troopers24] and is reinforced by the Compass Security follow-on documenting how the SilverPotato chain was productised within months of Pierini's February 2024 ADCS-server post [@decoder-adcs-server; @compass-three-headed]. The number should be read as a rule of thumb, not a benchmark.

Linux and Windows Subsystem for Linux extension. No Linux analogue of SeImpersonatePrivilege exists. There are partial precedents in the impacket cross-protocol relay work, but no Potato-class primitive that produces a SYSTEM token on a Linux host. Open.

Will defence-in-depth combine to close the family without ever declaring a new boundary? Microsoft has shipped Credential Guard [@ms-credential-guard], Hypervisor-Protected Code Integrity [@ms-hvci], Smart App Control [@ms-smart-app-control], and the experimental Administrator-protection direction in Windows 11 24H2 [@ms-administrator-protection]. Each changes the runtime trust model in some way. No combination of currently-shipping technologies closes the family as of May 2026 -- the Potato primitives live below the layer those technologies operate on [@troopers24; @compass-three-headed].

A defensive detection primitive that catches every variant. The unifying invariant is ImpersonateNamedPipeClient being called from a thread that holds SeImpersonatePrivilege against a named pipe that has just received a SYSTEM-context authentication originating from a service the calling process did not initiate. Per-variant detection rules exist for each named tool (GodPotato, PrintSpoofer, JuicyPotato). A generalising rule has not been published [@ms-impersonate-api]. The informal community position is that the family is non-detectable as a class because the primitive is in the legitimate hot path of nearly every Windows service.

MSRC servicing-criteria position on cross-session Distributed COM activation. LocalPotato (CVE-2023-21746) received a CVE for a piece of the local NTLM protocol [@nvd-cve-2023-21746]. FakePotato (CVE-2024-38100) received a CVE for an access-control list misconfiguration on the ShellWindows AppID [@nvd-cve-2024-38100]. SilverPotato is still unpatched [@decoder-silverpotato; @troopers24]. The boundary that distinguishes these three is unclear: why was the ShellWindows cross-session activation patched while the sppui cross-session activation has not been? The answer determines the next decade of the family. The defensible reading is that Microsoft will service variants that look like permission misconfigurations on a single AppID but not the underlying cross-session Distributed COM activation primitive itself.

11. How to Use a Potato in 2026

The practitioner question is operational. Given a foothold and a goal, which Potato variant does the job? The decision tree below walks through the path researchers settle into on red-team engagements.

The first-try heuristic is short. GodPotato first, because it is the single binary that works on every in-support Windows release [@beichendream-god]. If the GodPotato binary signature is blocked by Endpoint Detection and Response, SweetPotato with -e PrintSpoofer (or -e EfsRpc on a Domain Controller where Spooler is off) [@ccob-sweet]. If both are blocked, SharpEfsPotato as the lower-public-exposure third choice [@bugch3ck-efs]. For pre-2023 unpatched fleets, JuicyPotatoNG during the Phase-2 hardening window and JuicyPotato on pre-1809 builds [@antonio-juicyng; @ohpe-juicy]. For domain escalation against a DC, SilverPotato with the Compass Security KrbRelay modifications [@decoder-silverpotato; @compass-three-headed].

Note: GodPotato. If signature-blocked, SweetPotato with -e PrintSpoofer. If both blocked, SharpEfsPotato. The rest of the family is for situations the first three do not cover (legacy fleets, DC escalation, technique illustration of patched variants) [@beichendream-god; @ccob-sweet; @bugch3ck-efs].

Several implementation pitfalls catch new operators. The named-pipe path that GodPotato uses (\pipe\<token>\pipe\epmapper) is widely signatured by EDR vendors -- see the detection-engineering Spoiler below for the specific Sigma and Elastic rules [@sigma-potato-hktl; @elastic-rogue-pipe] -- and recompiling from source with a different pipe template is the standard countermeasure. A token holding SeImpersonatePrivilege does not necessarily enable it -- explicit AdjustTokenPrivileges with SE_PRIVILEGE_ENABLED is required, and custom adaptations frequently miss the step [@ms-adjusttokenprivileges]. SweetPotato's default -e PrintSpoofer mode fails silently on a Domain Controller where Spooler is disabled per the PrintNightmare aftermath; the correct DC default is GodPotato or SharpEfsPotato. RoguePotato's outbound TCP 135 to attacker infrastructure is blocked by default in most enterprise networks. FakePotato and SilverPotato both require the victim identity to be actively logged in, since both depend on a live cross-session activation surface [@itm4n-printspoofer; @antonio-rogue; @decoder-silverpotato; @decoder-fakepotato].

If you defend Windows rather than attack it, the detection target is the conjunction of (a) named-pipe creation by an IIS or SQL or service account, (b) a SYSTEM-context process connecting to that pipe shortly after, and (c) `CreateProcessWithToken` from the original service-account process. None of the three events alone is anomalous. The conjunction is. Sysmon Event ID 1 (Process Create) paired with Event IDs 17 and 18 (PipeEvent: Pipe Created and Pipe Connected) plus ETW providers `Microsoft-Windows-COM` and `Microsoft-Windows-RPC` cover the activation-plus-pipe half [@ms-sysmon]; Sysmon Event ID 10 (ProcessAccess) on `lsass.exe` from the originating service account is the third pillar that surfaces the impersonation handle acquisition [@ms-sysmon]. Per-variant signatures are published as Sigma rules for the public LocalPotato, CoercedPotato, JuicyPotato, RottenPotato, and EfsPotato binaries [@sigma-potato-hktl; @sigma-localpotato], and Elastic's `privilege_escalation_via_rogue_named_pipe` rule fires on the PrintSpoofer / EfsPotato pipe-path pattern that GodPotato shares [@elastic-rogue-pipe]. A class-generalising rule that fires on the *primitive* (rather than per-binary) has not been published.

Library and framework support follows the same shape as any post-exploitation primitive (the picture here is community-empirical, drawn from public BOF and module repositories rather than vendor reference architectures). Cobalt Strike Beacon Object Files wrapping GodPotato, PrintSpoofer, and SweetPotato are widely shared in the red-team community -- incursi0n/GodPotatoBOF is one publicly published example that integrates with BeaconUseToken() for in-Beacon SYSTEM-token application [@godpotato-bof] -- and the same wrappers load into Sliver. PowerShell wrappers around PrintSpoofer and JuicyPotato are integrated into Empire and Starkiller. The Metasploit incognito post-exploitation module handles token impersonation as a primitive but does not wrap GodPotato directly [@msf-incognito]. The impacket toolkit's ntlmrelayx is the canonical relay engine for the tail of SilverPotato [@fortra-impacket], and OleViewDotNet -- Forshaw's tool -- is the discovery oracle that surfaced the sppui and ShellWindows AppIDs in the first place [@tyranid-oleview; @decoder-silverpotato; @decoder-fakepotato].

12. Frequently Asked Questions

The name `Potato` originates with Stephen Breen's `foxglovesec/Potato` repository, created February 9, 2016, three weeks after the January 16, 2016 HotPotato blog post [@foxglove-potato-repo; @foxglove-hotpotato]. HotPotato is in the family because it pivots through the same `SeImpersonatePrivilege` plus named-pipe-impersonation primitive that every later variant exploits -- the vehicle is different (NetBIOS spoofing + WPAD + HTTP-to-SMB rather than Distributed COM) but the architectural carve-out is the same. See §4 for the bracketing-variant framing. Because every Internet Information Services application-pool identity is granted the privilege by Windows default [@itm4n-printspoofer]. The grant exists for legitimate request-scoped impersonation -- it is the mechanism IIS uses to "act as" a calling user during authenticated request handling. The same default grant is the entire vulnerability surface for the Potato family. The Microsoft Security Servicing Criteria document treats the resulting `SeImpersonate`-to-SYSTEM transition as a safety boundary rather than a security boundary [@msrc-servicing-criteria; @troopers24]. No. CVE-2021-26414 hardening raises the *authentication* bar for Distributed COM clients to `RPC_C_AUTHN_LEVEL_PKT_INTEGRITY` and was fully enforced on March 14, 2023 in Phase 3 of the rollout [@ms-kb5004442]. It does not declare Distributed COM activation a security boundary. The proof is that GodPotato, which exploits an RPCSS OXID-handling defect rather than the activation authentication level, survives all three phases of the rollout and remains the practitioner default in 2026 [@beichendream-god]. Open question, with a defensible reading. LocalPotato attacks the local-user-to-local-user NTLM authentication context handle, which *is* on the servicing-criteria boundary list [@decoder-localpotato; @msrc-servicing-criteria]. RemotePotato0 attacks the `SeImpersonate`-to-SYSTEM transition via cross-session Distributed COM activation, which is *not* on the list and was therefore deemed an extension of the existing carve-out [@sentinellabs-relaying; @troopers24]. The two boundaries (local NTLM authentication context vs cross-session Distributed COM activation) are not equivalent in Microsoft's published servicing position. Yes, on every patched Windows 11 / Server 2025 build as of this writing [@beichendream-god]. The RPCSS OXID-handling defect that GodPotato weaponises survives all three CVE-2021-26414 hardening phases [@ms-kb5004442; @compass-three-headed]. Microsoft has not assigned a CVE to the underlying defect, consistent with the servicing-criteria reading. Operationally, the only thing that changes between releases is the binary signature -- EDR vendors signature the public Apache-2.0 binary by hash, and operators recompile from source with cosmetic changes to evade [@beichendream-god]. Does not exist as of May 2026. If a 2025-2026 variant appears under an unfamiliar name -- French or otherwise -- verify against the canonical sources before citing: `decoder.cloud` for the Pierini and Cocomazzi line, `github.com/antonioCoco/*` for the Cocomazzi-authored repositories, `github.com/BeichenDream/*` for the BeichenDream line, and `itm4n.github.io` for the PrintSpoofer / SweetPotato line [@decoder-silverpotato; @antonio-rogue; @beichendream-god; @itm4n-printspoofer]. The Troopers 24 retrospective is the community-canonical lineage list as of the most recent consolidated talk [@troopers24]. Informally, no. The primitive `ImpersonateNamedPipeClient` is in the legitimate hot path of nearly every Windows service [@ms-impersonate-api]. Per-variant signatures exist for the public binaries (GodPotato, PrintSpoofer, JuicyPotato), and ETW providers `Microsoft-Windows-COM` and `Microsoft-Windows-RPC` surface the activation-and-RPC events that the Distributed COM variants generate. A class-generalising detection rule has not been published as of May 2026, and the false-positive rate on legitimate Windows services is high for any rule that fires on `ImpersonateNamedPipeClient` alone [@troopers24].

13. The Architectural Decision

Return to the opening scene. The same Internet Information Services web shell, the same GodPotato.exe, the same ten-second SYSTEM shell. The reader now knows this is not a zero-day. It has been a single-binary operation for the better part of a decade. Every step is documented Win32 behaviour. And every step is permitted by Microsoft's published servicing position [@beichendream-god; @msrc-servicing-criteria; @troopers24].

Nine years of named-variant disclosures. Eleven named variants. Three Microsoft hardening waves. Two CVEs -- LocalPotato in January 2023, FakePotato in July 2024 [@nvd-cve-2023-21746; @nvd-cve-2024-38100]. One "Won't Fix" decision on a working Domain Admin escalation in April 2021 [@sentinellabs-relaying]. Zero declarations of SeImpersonatePrivilege or Distributed COM activation as a security boundary [@troopers24; @msrc-servicing-criteria]. The MSRC Windows Security Servicing Criteria document, the one whose boundary definition fetches in static HTML and whose enumeration table is JavaScript-rendered, is the through-line [@msrc-servicing-criteria]. Pierini and Cocomazzi say it bluntly in the Troopers 24 abstract:

Microsoft does not consider WSH a security boundary but rather a safety boundary; for this reason, many Potato exploits work (and have been working) on fully updated Windows systems. -- Pierini and Cocomazzi, Troopers 24 abstract [@troopers24]

Microsoft will never fix the Potato class because fixing it requires declaring Distributed COM activation a security boundary, and they have spent twenty-five years insisting it is not. What would change that? A major-version Windows release that explicitly revokes the default SeImpersonatePrivilege grant from service accounts -- a compatibility-breaking change that breaks IIS, SQL Server, BITS, the Spooler, and most third-party services that depend on the legitimate impersonation contract. No such release is on the public roadmap as of May 2026 [@msrc-servicing-criteria; @ms-kb5004442; @beichendream-god].

Until then, the family is alive, and the ten-second SYSTEM shell is the default outcome of any IIS or service-account foothold on a fully-patched Windows machine. That is not the unintended consequence of an unpatched bug. That is the intended consequence of a published architectural decision.

Key idea: The Potato family is not a stack of bugs Microsoft is slowly working through. It is the long-running consequence of a published architectural decision: that the SeImpersonatePrivilege-to-SYSTEM transition is a safety boundary, not a security boundary. Eleven variants over nine years of named-variant disclosures (HotPotato January 2016 -> FakePotato August 2024) are the empirical proof of how stable that decision is [@troopers24; @msrc-servicing-criteria].

The following retention block summarises the six key terms above. Citations for each definition live in §2.1, §2.2, §6.5, §6.1, §3, and §2 of the body respectively (the StudyGuide MDX wrapper does not render @ref-id links inline).

Certified Pre-Owned: AD CS and Active Directory's Second Trust Root

noreply@paragmali.com (Parag Mali) — Mon, 25 May 2026 00:00:00 GMT

**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 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.

You will see both anchor dates in the literature. Semperis's CVE-2022-26923 retrospective writes that "In Windows Server 2008, Microsoft introduced AD CS" [@semperis-cve]. The Microsoft Learn current overview describes AD CS as a "Windows Server role for issuing and managing public key infrastructure (PKI) certificates" [@msl-adcs-current] without distinguishing the ship date from the rename date. This article uses the dual anchor: the role *shipped* in 2000 as Microsoft Certificate Services, and was *renamed* Active Directory Certificate Services in 2008. The misconfigurations the ESC catalog enumerates were enabled by Windows Server 2003's V2 templates and have not been default-off since.

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; 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, 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.

ESC12 lives in a different primitive category from every other ESC: it attacks the CA's HSM, not its software configuration. Hans-Joachim Knobloch's October 2023 disclosure (earliest Wayback snapshot dated October 24, 2023) observes that the YubiHSM2 Key Storage Provider on AD CS stores the HSM authentication key in cleartext under `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` [@knobloch-esc12] [@knobloch-esc12-archive]. A non-administrative user with shell access to the CA and read on that registry key can recover the HSM password and forge certificates against the HSM-backed CA key. Out of body scope for this article; readers running YubiHSM-backed CAs should read Knobloch's primary source.

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.

The principal-graph model treats each AD object as a node and each access right or trust as an edge. The graph then path-finds from a starting principal to a Tier-Zero target. This model works elegantly for template DACLs (ESC4) and CA DACLs (ESC7) and for issuance-policy group linkage (ESC13). It struggles with attacks where the abuse is a transport-level interaction rather than a principal-to-principal relationship.

ESC8 used to be considered uncatchable in this model. The CoerceAndRelayNTLMToADCS edge solved that: BloodHound CE now models the SMB-coercion-plus-NTLM-relay-to-ESC8 chain as a Group-to-Computer edge whose source is Authenticated Users and whose destination is the coerced target computer; the relay target CA and the template are encoded in the edge's metadata, not as graph nodes [@bh-coerce-adcs-edge]. The edge exists because coercion has a stable shape -- an unauthenticated principal class, a target computer, and an ESC8-vulnerable CA endpoint reachable on the network -- that the graph can express.

ESC11 remains harder. The RPC enrollment transport does not have a stable coercion model (the trigger is ICertPassage packet privacy not being enforced, not a coercion gadget like MS-EFSR), and the BloodHound graph today does not ship an ADCSESC11 edge. The model limit is partial, not total. The conventional "BloodHound cannot graph transport attacks" framing -- which was the prevailing folklore through 2024 -- is wrong; ESC8 is in the graph. ESC11 is the open structural case.

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 ADCSESCN + 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 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:

Revoke the CA's published certificate chain.
Decommission the CA (remove the role service, delete the CA private key store, retire the host).
Build a replacement CA on new hardware with a new key.
Publish the new CA into NTAuthCertificates.
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).
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 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.