Windows privilege escalation makes sense only once you understand how Windows decides what a process is allowed to do. That decision is carried by an access token, shaped by integrity levels and privileges, and moderated at the surface by User Account Control. This page is the general mechanism; the specific attacks — UAC bypass, service misconfigurations, token impersonation — live in the Vulns & Misconfigs section under Privilege Escalation.
The access token
When a user logs on, Windows builds an access token that every process they start carries. The token is the answer to "who is this, and what may it do." It contains the user's SID, the SIDs of every group they belong to, an integrity level, and a list of privileges. Every time a process touches a securable object, Windows compares the token against the object's ACL.
Two token types matter for attacks. A primary token is attached to a process. An impersonation token lets a thread temporarily act as another identity — the legitimate mechanism a server uses to do work "as" a connecting client, and the mechanism the Potato attacks abuse.
Integrity levels
Every token (and every securable object) has a mandatory integrity level, a coarse trust band that sits above normal permissions — a lower-integrity process cannot write to a higher-integrity object even if the DACL would otherwise allow it.
| Level | Who runs here |
|---|---|
| System | SYSTEM and core OS services — the goal of local escalation |
| High | Elevated (UAC-approved) administrator processes |
| Medium | Standard user processes — including an admin who has not elevated |
| Low | Sandboxed processes (e.g. browser renderers) |
The key insight for escalation: an administrator logged in normally runs at Medium integrity with a filtered token. They are an admin on paper but cannot perform admin actions until a process is elevated to High. Getting from Medium to High without a prompt is exactly what a UAC bypass does; getting to System is what service abuse and token impersonation do.
Privileges
Beyond group membership, a token holds named privileges — specific
rights that are dangerous enough to be listed individually. Several are escalation
primitives in their own right, which is why whoami /priv is one of the
first commands run on a new host.
| Privilege | Why it matters |
|---|---|
| SeImpersonatePrivilege | Impersonate a token you receive — the basis of the Potato attacks (service account → SYSTEM) |
| SeAssignPrimaryTokenPrivilege | Assign a primary token to a new process — similar escalation potential |
| SeDebugPrivilege | Open any process — read LSASS memory, inject code |
| SeBackupPrivilege / SeRestorePrivilege | Read/write any file regardless of DACL — dump the SAM, overwrite binaries |
| SeTakeOwnershipPrivilege | Take ownership of any object, then rewrite its ACL |
| SeLoadDriverPrivilege | Load a driver — kernel-level code execution |
What UAC actually is
User Account Control exists because, before it, everyone ran as administrator all the time and malware inherited that power. UAC splits an administrator into two tokens: a filtered medium-integrity token for everyday use and a full high-integrity token that is only attached when the user explicitly consents to elevation (the "Do you want to allow this app to make changes?" prompt).
Crucially, Microsoft is explicit that UAC is not a security boundary. It is a convenience feature to encourage running with least privilege — not a wall that is guaranteed to stop a determined local attacker. That single sentence explains why UAC bypasses are numerous and unpatched.
Auto-elevation — the reason bypasses exist
To avoid prompting users constantly, Windows lets certain signed Microsoft binaries
auto-elevate: they receive a high-integrity token with no prompt.
The elevation service (via RAiLaunchAdminProcess) checks the binary's
manifest (autoElevate=true), its signature, and its path. Bypasses work
by finding an auto-elevating binary that then does something attacker-influenceable:
| Weakness | How a bypass uses it |
|---|---|
| Reads a handler from HKCU | A medium process writes the key; the elevated binary runs the attacker's command (fodhelper, eventvwr, sdclt) |
| Loads a DLL from a writable path | Drop a malicious DLL the elevated binary loads (DLL hijack) |
| Path-normalization trust check | A "mock" trusted directory (trailing space) satisfies the check while pointing elsewhere |
The escalation landscape
Put together, the token model explains every local-escalation route:
- Medium → High (same admin user): abuse an auto-elevating binary — a UAC bypass.
- Standard user → SYSTEM: find something that runs as SYSTEM and that you can influence — a weak service, an unquoted path, a writable binary, or
AlwaysInstallElevated. - Service account → SYSTEM: if the token holds
SeImpersonatePrivilege, coerce and impersonate a SYSTEM token (the Potato family). - Any → more: a dangerous privilege (SeDebug, SeBackup, SeLoadDriver) is often a direct primitive on its own.
The takeaway
Windows authorises on a token: an identity, an integrity level, and a set of
privileges, checked against every object's ACL. UAC is a usability layer over that
model — it filters an admin's token by default and hands back the full one only on
consent, but it is explicitly not a security boundary, which is why auto-elevating
binaries can be turned into silent escalations. Read a host's exposure by reading
its tokens: whoami /groups for integrity, whoami /priv for
the dangerous privileges, and the service/registry ACLs for what a low-priv user can
influence. The concrete techniques are in the
Vulns & Misconfigs section.