miscrevised January 30, 20265 min read

Windows privilege escalation: tokens, SIDs, and the impersonation shortcut

Windows boot2root boxes escalate differently from Linux. The access-token model that decides what you can do, the privileges worth having, and the service-account impersonation trick that turns SeImpersonate into SYSTEM.

Windows challenges that drop you on a box work like their Linux cousins - you land as a low-privileged account and the flag is in the Administrator's profile - but the escalation model is entirely different. There are no SUID bits and no sudo. Instead, everything hinges on the access token: a structure Windows attaches to every process that says who you are and what you are allowed to do. Understand the token, and Windows privesc stops being a grab-bag of tricks.

The mental model: your identity on Windows is not just your username. It is a set of security identifiers, and what the defender sees you do with them is the subject of endpoint telemetry (SIDs) - one for you, several for your groups - plus a list of privileges, all bundled into the token. When a process tries something, the kernel checks the token. Escalation is the art of getting a token with more in it than yours, or abusing a privilege yours already has.

First: read your own token

whoami /all           # your SID, every group SID, and - crucially - your privileges
whoami /priv          # just the privilege list; look for anything "Enabled"
systeminfo            # OS version and, importantly, the installed hotfixes

whoami /priv is the Windows equivalent of sudo -l: it lists the special powers your token holds, and one of them is often the whole path up.

A SID looks like S-1-5-21-...-1001. The ones worth recognising on sight: S-1-5-18 is SYSTEM (the goal), S-1-5-32-544 is the built-in Administrators group, and a SID ending in -500 is the real Administrator account. If your token contains the Administrators group SID but you are not elevated, you are one UAC bypass away; if it does not, you need a genuine escalation.

The privileges that are secretly game over

Several Windows privileges look mundane and are actually equivalent to full compromise, because they let you touch something that controls the whole system. If whoami /priv shows any of these enabled, that is your route.

Privilege	Why it wins
SeImpersonate / SeAssignPrimaryToken	Impersonate a token handed to you - the basis of the 'Potato' attacks below. Common on service accounts.
SeDebug	Open any process, including SYSTEM ones - inject into one or steal its token.
SeBackup / SeRestore	Read or write any file regardless of its ACL - read SAM/SYSTEM hives, or overwrite a system binary.
SeTakeOwnership	Take ownership of any object, then grant yourself access to it.
SeLoadDriver	Load a driver - load a vulnerable one and pivot to the kernel.

The impersonation shortcut: Potato attacks

SeImpersonate lets a process impersonate a token that is presented to it. The Potato family of exploits abuses this by tricking a SYSTEM-level service into authenticating to a listener the attacker controls, capturing that SYSTEM token, and impersonating it. You do not need to understand the RPC/COM plumbing to use them - you need to recognise when the preconditions hold.

PrintSpoofer - abuses the print spooler; the go-to when SeImpersonate is present on modern Windows.
RoguePotato / GodPotato - COM-based variants that work across a wide range of versions.
JuicyPotato - the classic, effective on older Windows where the COM defences were weaker.

# The shape of the win, given SeImpersonate:
PrintSpoofer.exe -i -c "cmd"      # spawns a SYSTEM shell
# or
GodPotato.exe -cmd "cmd /c whoami"  # -> nt authority\system

One binary, one flag, a SYSTEM shell. The prerequisite is always the same: an enabled SeImpersonate or SeAssignPrimaryToken in your token.

When the token is clean: the other classics

No juicy privilege? Fall back to the misconfiguration checks, which mirror the Linux ones in spirit.

Unquoted service paths. A service whose path is C:\Program Files\My App\svc.exe without quotes lets you drop C:\Program.exe if you can write there - Windows tries each space-split prefix.
Weak service permissions. A service you can reconfigure (via sc config) lets you set its binary to yours; it runs as SYSTEM on restart.
Writable service binaries or AutoRuns. If you can overwrite the executable a SYSTEM service or a scheduled task runs, you inherit its privileges.
AlwaysInstallElevated. If this policy is set, any .msi you build installs as SYSTEM - a one-line registry check confirms it.
Stored credentials. Unattend.xml, the registry (Winlogon autologon), saved RDP/PowerShell creds, and the SAM/SYSTEM hives you can read with SeBackup.

As on Linux, an enumeration script runs all of this at once. WinPEAS and PowerUp encode the whole catalogue and flag the anomalies; run one, read its highlights, and match a finding to the techniques above. And when nothing is misconfigured, systeminfo's hotfix list against a kernel-exploit suggester is the last resort - but token abuse solves most boxes first.

The order

whoami /all and /priv - read your SIDs and privileges.
Any juicy privilege enabled? Use it: SeImpersonate → Potato, SeBackup → read the hives, SeDebug → steal a token.
On a service account from a web/db shell, assume SeImpersonate and go straight to PrintSpoofer/GodPotato.
Otherwise: unquoted paths, weak service perms, writable binaries, AlwaysInstallElevated, stored creds.
Run WinPEAS to surface all of it; match findings to techniques.
Last resort: match the build to a kernel exploit.