You compromise a service (web, DB, agent, scheduler). You land a shell as a "low privilege" identity like:

  • NT AUTHORITY\LOCAL SERVICE
  • NT AUTHORITY\NETWORK SERVICE
  • or an IIS app pool / service account

And then — somehow — people end up with SYSTEM.

This is where the Potato family lives: attacks that abuse Windows authentication + impersonation design patterns to turn service-context execution into SYSTEM-context execution — especially when SeImpersonatePrivilege is present. GitHub+2Micah Van Deusen+2

The One Idea Behind (Almost) Every Potato

All Potato variants are riffs on the same theme:

  1. You already have code execution as a service context
  2. That context has an impersonation-capable privilege (commonly SeImpersonatePrivilege)
  3. You can trigger (or "coerce") a SYSTEM process to authenticate to something you control
  4. You capture/relay that authentication in a way that lets you impersonate SYSTEM

Different Potatoes differ mainly in how they trigger that privileged authentication and which Windows subsystems they abuse (WPAD/NTLM relay, COM/DCOM, RPC, EFSRPC, Print Spooler, named pipes, etc.). Troopers+3Hack In The Box Security Conference+3Foxglove Security+3

Why SeImpersonatePrivilege Is the "Hidden Superpower"

Windows uses access tokens and impersonation constantly (COM, RPC, service brokers). The privilege exists because many legitimate services must act "on behalf of" clients.

That makes SeImpersonatePrivilege extremely valuable to attackers — because once a privileged identity authenticates into a flow you can man-in-the-middle, Windows will often hand you an impersonation opportunity. Micah Van Deusen+2Hack In The Box Security Conference+2

Even Microsoft's own threat intel categorizes JuicyPotato-type tooling as a local privilege escalation approach tied to COM weaknesses and token abuse. Microsoft

1) Hot Potato (2016): Local network trickery + NTLM relay

Hot Potato is commonly described as combining WPAD/proxy abuse with name resolution spoofing (NBNS/LLMNR) and NTLM relay to elevate locally. Foxglove Security+2Penetration Testing Lab+2

What it taught the community: Windows' legacy discovery/auth flows can be turned into privilege pivots, even without "traditional" memory corruption.

2) Rotten Potato (2016): Service accounts → SYSTEM via COM/DCOM token games

Rotten Potato popularized the "service account token to SYSTEM" story, leaning into COM/DCOM authentication quirks and relaying/negotiating a SYSTEM token after coercion. Foxglove Security+1

What it taught the community: If you can force SYSTEM to authenticate into the right brokered path, impersonation can do the rest.

3) Juicy Potato: Practical reliability on many systems (until hardening/patching raised the bar)

Juicy Potato became the "go-to" in many tradecraft playbooks (and shows up in incident reports), framed around COM abuse to elevate when SeImpersonate/SeAssignPrimaryToken is available. Fortinet+1

What it taught the community: Operational usability matters. The Potatoes that spread were the ones that "just worked" across common estate configs.

4) Rogue Potato: Adapting when older techniques broke on newer server builds

Rogue Potato is often described as a response to JuicyPotato failing on newer systems, shifting the technique to different plumbing (notably involving RPC behavior). GitHub

What it taught the community: Microsoft patching the "one favorite path" doesn't kill the class — attackers move to another subsystem.

5) Lonely Potato / God Potato: DCOM-focused evolutions

These lines keep returning to COM/DCOM as a recurring source of privileged authentication flows and token games. (GodPotato's repo explicitly frames itself as a DCOM-based escalation path when ImpersonatePrivilege exists.) GitHub+1

6) Sweet Potato / Print Spooler angle

The print ecosystem has a long history of security issues; "Sweet Potato" is commonly used as a label for print-related abuse paths in the broader Potato story. GitHub+1

7) Generic Potato / SharpEfsPotato / Local Potato

These names generally describe "same class, different trigger":

  • HTTP + named pipe patterns
  • EFSRPC coercion patterns (SharpEfsPotato label in the repo list) GitHub
  • NTLM challenge/response flows

The pattern remains: coerce privileged auth → leverage impersonation. Hack In The Box Security Conference+1

Snippet 1: Check if the current token has SeImpersonatePrivilege (C/C++)

// Compile (Visual Studio): cl /W4 /EHsc token_privs.c advapi32.lib
#include <windows.h>
#include <stdio.h>
static BOOL HasPrivilege(LPCWSTR privName) {
    HANDLE hToken = NULL;
    if (!OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &hToken)) return FALSE;
    DWORD size = 0;
    GetTokenInformation(hToken, TokenPrivileges, NULL, 0, &size);
    TOKEN_PRIVILEGES* tp = (TOKEN_PRIVILEGES*)HeapAlloc(GetProcessHeap(), 0, size);
    if (!tp) { CloseHandle(hToken); return FALSE; }
    BOOL ok = GetTokenInformation(hToken, TokenPrivileges, tp, size, &size);
    if (!ok) { HeapFree(GetProcessHeap(), 0, tp); CloseHandle(hToken); return FALSE; }
    LUID luid;
    if (!LookupPrivilegeValueW(NULL, privName, &luid)) {
        HeapFree(GetProcessHeap(), 0, tp); CloseHandle(hToken); return FALSE;
    }
    BOOL found = FALSE;
    for (DWORD i = 0; i < tp->PrivilegeCount; i++) {
        if (tp->Privileges[i].Luid.LowPart == luid.LowPart &&
            tp->Privileges[i].Luid.HighPart == luid.HighPart) {
            found = TRUE;
            break;
        }
    }
    HeapFree(GetProcessHeap(), 0, tp);
    CloseHandle(hToken);
    return found;
}
int main() {
    wprintf(L"SeImpersonatePrivilege: %s\n",
        HasPrivilege(L"SeImpersonatePrivilege") ? L"PRESENT" : L"NOT PRESENT");
    wprintf(L"SeAssignPrimaryTokenPrivilege: %s\n",
        HasPrivilege(L"SeAssignPrimaryTokenPrivilege") ? L"PRESENT" : L"NOT PRESENT");
    return 0;
}

Snippet 2: PowerShell quick check (defender/blue-team friendly)

whoami /priv | Select-String -Pattern "SeImpersonatePrivilege|SeAssignPrimaryTokenPrivilege"

Defender's View: How to Reduce the Potato Attack Surface

This family keeps resurfacing because it targets core OS behaviors. Still, defenders can materially reduce risk:

1) Minimize service account privileges

  • Avoid running services under accounts that unnecessarily retain impersonation privileges.
  • Use dedicated service identities with least privilege and careful token rights. Micah Van Deusen+1

2) Reduce NTLM where feasible

NTLM remains pervasive for compatibility, but reducing NTLM usage and tightening relay protections reduces certain classes of coercion/relay chains. Crowe

3) Harden name resolution & proxy discovery (where applicable)

NBNS/LLMNR/WPAD-related weaknesses have long histories; hardening these reduces Hot-Potato-style footholds. Foxglove Security+2nccgroup.com+2

4) Monitor for "service account → SYSTEM" anomalies

Practical SOC wins are often about detection:

  • sudden token/privilege elevation patterns
  • suspicious authentication to local listeners
  • unusual COM/RPC activation patterns in tight windows

(Exact event IDs and EDR queries vary by stack, but the behavioral story is consistent.)

Potato isn't one exploit. It's an abuse class. If you're a red teamer: learn the prerequisite (impersonation) and the forcing function (coerced auth). If you're a defender: minimize impersonation exposure and reduce legacy auth pathways.

None