JuicyPotato. RoguePotato. PrintSpoofer. SweetPotato. GodPotato. The naming convention makes it sound like there are dozens of different privilege escalation techniques. There aren't. They all do the exact same thing with minor variations in how they trigger the connection.
Every single potato exploit follows the same three-step pattern: create a named pipe, trick a SYSTEM process into connecting to it, then impersonate the connected client to steal their token. The only difference between them is step two. Understanding this pattern means you can write your own.
Named Pipes in 30 Seconds
A named pipe is an inter-process communication (IPC) mechanism in Windows. A server creates a pipe with CreateNamedPipe(), a client connects to it, and they can send data back and forth. The interesting part: when a client connects, the server can call ImpersonateNamedPipeClient() to assume the client's security context.
If the client is running as SYSTEM, you are now running as SYSTEM. That's the entire exploit. Everything else is just convincing SYSTEM to connect.
Step 2 is the only part that changes between potato variants. Everything else is identical Win32 API plumbing. Once you understand this, the "different" potato tools stop being mysterious.
The Trigger: Where Potatoes Differ
The hard part is step 2: making a privileged process connect to your pipe. You need a Windows service running as SYSTEM or NETWORK SERVICE to authenticate to your named pipe. Each potato variant found a different service to abuse.
| Potato | Trigger Service | Mechanism | Patched? |
|---|---|---|---|
| JuicyPotato | COM/DCOM (BITS, etc.) | CLSID activation with custom port | YES |
| PrintSpoofer | Print Spooler | OpenPrinterW with pipe UNC path | PARTIAL |
| EfsPotato | EFS (LSASS) | EfsRpcOpenFileRaw with pipe path | PARTIAL |
| GodPotato | RPCSS/DCOM Activator | IStorage unmarshaling via IMarshal | NO |
The Prerequisite: SeImpersonatePrivilege
None of this works without SeImpersonatePrivilege. This privilege allows a process to impersonate another user's token after they authenticate. Without it, ImpersonateNamedPipeClient() silently fails.
The good news: service accounts almost always have it. If you land on a box as an IIS AppPool identity, a SQL Server service account, or any Windows service, you have this privilege. Run whoami /priv and check.
Walking Through a Trigger: PrintSpoofer
PrintSpoofer is the simplest trigger to understand. The Print Spooler service (spoolsv.exe) runs as SYSTEM. When you call OpenPrinterW() with a UNC path pointing to your named pipe, the Spooler service connects to that pipe to check if a printer exists there.
That's the entire exploit. The Spooler connects because it's trying to resolve a printer path. It doesn't find a printer, but it doesn't matter. The connection already happened. The impersonation already succeeded.
Why GodPotato is Different
Most potato exploits depend on a specific Windows service being enabled. PrintSpoofer needs the Print Spooler. EfsPotato needs EFS. JuicyPotato needs specific COM CLSIDs that Microsoft has been quietly removing.
GodPotato doesn't depend on any optional service. It abuses RPCSS (the RPC Endpoint Mapper), which is a core Windows component that cannot be disabled. It uses a custom IMarshal implementation to intercept the DCOM activation process, capturing a SYSTEM token during the standard COM object creation flow.
The Takeaway
Stop treating potato exploits as separate tools that you run when one fails and try the next. They're all the same exploit with different triggers. Understand the pattern, pick the trigger that works for your target's configuration, and move on.
Named pipe impersonation has been around since Windows NT. Microsoft can patch individual trigger services, but they can't remove ImpersonateNamedPipeClient() without breaking half of Windows. As long as services run as SYSTEM and service accounts have SeImpersonate, potatoes will keep working. The only question is which service you trick into connecting.
This post reflects research and testing as of early 2026. Potato variants and their viability change with Windows patches. Test accordingly.