# SYSTEM in Ten Seconds: How the Potato Family Survived Every Microsoft Mitigation
> A decade of Windows local privilege escalation -- HotPotato through FakePotato -- rests on one architectural decision Microsoft has refused to revisit.
*Published: 2026-05-31*
*Canonical: https://paragmali.com/blog/system-in-ten-seconds-how-the-potato-family-survived-every-m*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
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](/blog/windows-security-boundaries-the-document-that-decides-what-g/) [@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.)
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](/blog/ntlmless-the-death-of-ntlm-in-windows/) 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.
### 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].
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](/blog/certified-pre-owned-ad-cs-and-active-directorys-second-trust/) 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:")` 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].
{`
// Verbatim from Decoder's August 2, 2024 writeup -- one cross-session call into
// the admin's session via the misconfigured ShellWindows DCOM ACL.
const line1 = '$obj = [System.Runtime.InteropServices.Marshal]::BindToMoniker("session:2!new:9BA05972-F6A8-11CF-A442-00A0C90A8F39")';
const line2 = '$p = $obj.item(0).document.application';
const line3 = '$p.ShellExecute("c:\\\\temp\\\\reverse.bat", "", "c:\\\\windows", $null, 0)';
console.log("PowerShell line 1:", line1);
console.log("PowerShell line 2:", line2);
console.log("PowerShell line 3:", line3);
console.log("Patched in the July 2024 Patch Tuesday cumulative updates as CVE-2024-38100.");
`}
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.
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](/blog/adminless-how-windows-finally-made-elevation-a-security-boun/) 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](/blog/the-empty-hash-credential-guard-the-lsaiso-trustlet-and-the-/) isolates LSASS secrets in a [Virtualization-Based Security Trustlet](/blog/vbs-trustlets-what-actually-runs-in-the-secure-kernel/) -- which protects NTLM hashes from extraction but does not gate `ImpersonateNamedPipeClient` or `SeImpersonatePrivilege` [@ms-credential-guard]. [Smart App Control](/blog/living-off-the-land-on-windows-the-lolbin-catalog-and-the-st/) 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].
## 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](/blog/wdac--hvci-code-integrity-at-every-layer-in-windows/) [@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.
flowchart TD
A[Target OS in support?] -->|"No"| Z1[JuicyPotato on pre-2020 builds, or RoguePotato on 2020-2022 builds]
A -->|"Yes"| B[Operator privilege?]
B -->|"SeImpersonate or SeAssignPrimaryToken"| C[Spooler running?]
B -->|"Standard user, cross-session victim present"| Z2[FakePotato technique illustrative -- patched in KB5040434]
B -->|"DCOM-group member on a DC"| Z3[SilverPotato with ntlmrelayx to AD CS]
C -->|"Yes"| D[SweetPotato -e PrintSpoofer default]
C -->|"No"| E[EFS RPC reachable?]
E -->|"Yes"| F[SharpEfsPotato]
E -->|"No"| G[GodPotato as fallback]
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\\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).