Windows Privilege Escalation 2026 — WinPEAS, AlwaysInstallElevated, Token Impersonation | Hacking Course Day 32

Day 31 covered Linux privilege escalation — SUID exploitation, sudo misconfigurations, writable cron jobs. Day 32 is the Windows equivalent. The philosophy is identical: default configurations, legacy software, and administrator convenience settings create persistent escalation paths that survive undetected for years. This is core curriculum in the 100-Day Ethical Hacking Course. Every professional penetration tester must be fluent in both Linux and Windows privilege escalation — most real-world environments are mixed, and your escalation methodology must be too.

WinPEAS — Automated Windows Privilege Escalation Enumeration

WinPEAS (Windows Privilege Escalation Awesome Script) is the first tool you run the moment you establish code execution on a Windows target. Before manually checking anything, before chasing hunches, run WinPEAS. It checks over 300 enumeration points simultaneously and produces colour-coded output that shows you exactly which misconfigurations are present. Red and yellow highlights are your action items. Everything else is context. A full WinPEAS run takes under sixty seconds on most systems and tells you more than an hour of manual enumeration would.

What WinPEAS actually checks spans the entire Windows security model: registry policies that grant elevated installer rights, service executable paths and their access control lists, file system permissions on directories in the system path, stored credentials in the Windows Credential Manager and browser profiles, scheduled tasks that run as SYSTEM with writable script files, installed software versions cross-referenced against a local CVE database, token privileges enabled on the current account, and network configuration revealing additional lateral movement paths. Each check maps to a known escalation technique. When WinPEAS highlights something in red, that technique is viable with high confidence. Yellow means the finding warrants manual verification before exploitation.

AlwaysInstallElevated — Registry Misconfiguration to SYSTEM

AlwaysInstallElevated is the Windows privilege escalation misconfiguration I encounter most frequently in enterprise environments. The setting exists for a legitimate operational reason — enabling it in Group Policy allows helpdesk staff to push MSI packages to user machines without the user needing administrator rights for each installation. IT teams enable it to solve a software deployment problem, solve that problem, and never revisit the setting. Three years later a penetration tester runs WinPEAS and it lights up in red.

The mechanism is straightforward. When AlwaysInstallElevated is active — both the HKLM and HKCU registry keys set to 0x1 — the Windows Installer service (which runs as NT AUTHORITY\SYSTEM) executes all MSI packages with SYSTEM privileges regardless of who launched the installer. This means any user on the system can craft a malicious MSI and achieve arbitrary code execution as SYSTEM. Generating the malicious MSI takes one msfvenom command. Executing it takes one msiexec command. The entire exploitation chain from “I see AlwaysInstallElevated in WinPEAS” to “SYSTEM shell on Netcat listener” takes under two minutes.

The critical prerequisite that many beginners miss: both the HKLM and HKCU registry keys must be set to 0x1. HKLM alone is not sufficient. The Windows documentation is clear on this, and WinPEAS checks both explicitly. If you see only the HKLM key set, move on to a different vector. Spending time generating and executing a malicious MSI when only one key is set will result in a standard user-privilege MSI execution — no escalation, wasted time, and potential detection from the msiexec call.

Unquoted Service Path Exploitation

Unquoted service paths exploit a documented Windows path resolution behaviour. When a Windows service is configured with an executable path that contains spaces but no surrounding quotation marks — such as C:\Program Files\My Application\bin\app.exe — the Service Control Manager does not know where the path ends. Windows resolves the ambiguity by making multiple sequential attempts. It first tries to execute C:\Program.exe, then C:\Program Files\My.exe, then C:\Program Files\My Application\bin\app.exe. If a malicious executable exists at any of the earlier positions, Windows executes it with the service account’s privileges before ever reaching the legitimate binary.

The exploitability of an unquoted path depends entirely on whether you can write a file to one of those intermediate positions. Writing to C:\ typically requires administrative rights. Writing to C:\Program Files\ is usually restricted to administrators. But writing to a specific third-party application’s subdirectory — C:\Program Files\MyApp\ — is sometimes permitted due to the application vendor setting permissive ACLs during installation. The icacls command lets you verify write access at each intermediate directory. Find one you can write to, place your payload there with the correct filename, and wait for the service to restart.

Weak Service Permissions — Hijacking Service Binary Paths

Every Windows service has an access control list defining which users and groups can query, start, stop, and configure the service. The most dangerous permission is SERVICE_CHANGE_CONFIG or SERVICE_ALL_ACCESS granted to a non-administrative group. With these permissions, a low-privilege user can directly modify the service’s executable path — redirecting it to run any file they specify. The modification takes effect on the next service start, at which point the service account (typically SYSTEM or LocalSystem) executes the attacker’s payload.

The accesschk utility from Microsoft Sysinternals is the standard tool for auditing service ACLs. It reports exactly which users and groups have which permissions on each service, including the granular Windows service permission flags. WinPEAS also checks this automatically and flags services where the current user’s context has modification rights. The exploitation steps are then identical regardless of discovery method: use sc config to point the service binary path at your payload, restart the service, collect the SYSTEM shell.

SeImpersonatePrivilege — Token Impersonation with GodPotato

SeImpersonatePrivilege is the privilege escalation vector I rely on most reliably in web application penetration tests on Windows. Here is why: when you gain code execution through a web vulnerability — a deserialization exploit, a file upload to webshell, a remote code execution CVE in a web framework — your shell runs as the IIS application pool identity or a dedicated service account. These accounts have SeImpersonatePrivilege enabled by Windows design. It is not a misconfiguration. It is the default. And it means that every Windows web application compromise comes with a built-in privilege escalation path.

The technical mechanism behind token impersonation exploits involves Windows COM infrastructure. GodPotato coerces a privileged COM server to authenticate over a named pipe controlled by the attacker. When the SYSTEM-level process connects, GodPotato captures its authentication token. Using SeImpersonatePrivilege, GodPotato then impersonates that token and spawns a new process — your payload — running as NT AUTHORITY\SYSTEM. The entire chain is automated in a single GodPotato command. It supports all Windows versions from Server 2012 to Server 2022, making it the most universally applicable token impersonation tool currently available.

Additional Windows Privilege Escalation Vectors

The four techniques above cover the vast majority of Windows privilege escalation findings in real assessments. WinPEAS checks dozens more, and several are worth knowing for specific environments. Stored credentials in the Windows Credential Manager are accessible via cmdkey /list — if an admin account credential is stored, runas /savecred lets you spawn a shell as that user without knowing the password. Scheduled tasks running as SYSTEM with writable script files allow command injection into the task’s script, achieving SYSTEM execution on the next scheduled run time. DLL hijacking works when a privileged process loads DLLs from directories where you have write access — placing a malicious DLL with the right name in the right location causes the privileged process to load and execute your code.

Kernel exploits deserve a specific note. When the Windows kernel version is outdated and a local privilege escalation CVE applies — PrintNightmare (CVE-2021-34527), HiveNightmare (CVE-2021-36934), or others — the escalation path may be more direct. Tools like Windows Exploit Suggester cross-reference the target’s missing patches against a CVE database and surface applicable kernel exploits. However, kernel exploits carry a risk of system instability and blue screens, and should only be used when authorised and when other escalation paths have been exhausted or verified as non-viable.

Post-Escalation — Verification, Impact, and Cleanup

Gaining SYSTEM access is the technical milestone. Proving it definitively and documenting it professionally is what produces a valuable penetration test report. The verification commands are fast. The discipline of capturing clean screenshots at each escalation step — before and after — is what separates a report that drives remediation from one that gets filed away. Every command in the chain, every output showing the privilege transition, every piece of evidence that the escalation was complete and reproducible belongs in the report appendix.