Windows Privilege Escalation Vulnerability Discovery
This page focuses on confirming specific misconfigurations before exploiting them. Run these checks from a low-privileged shell — a standard user or service account. The goal is to prove what is exploitable, not to use it yet.
Automated Enumeration
Run an automated tool first to surface everything quickly, then manually confirm high-confidence findings.
winPEAS is the most comprehensive Windows privilege escalation scanner. Run it and redirect output to a file — the terminal output is too fast to read:
On Kali: /usr/share/peass/winpeas/winPEASx64.exe
winPEAS writes color codes to console — redirect with > file.txt to read cleanly. Focus on the red and yellow findings.
PowerUp (PowerSploit) performs checks specifically for service, registry, and path misconfigurations that lead to SYSTEM:
On Kali: /usr/share/windows-resources/powersploit/Privesc/PowerUp.ps1
Weak Service Permissions
A service running as SYSTEM that a low-privileged user can reconfigure or whose binary they can overwrite is a direct path to privilege escalation.
Check service binary permissions — can you write to the executable the service runs?
Use accesschk from Sysinternals to verify actual ACLs:
SERVICE_ALL_ACCESS or SERVICE_CHANGE_CONFIG returned for a service your user owns = exploitable. Cross-check the service account — if it runs as LocalSystem or a privileged account, that service is the target.
Check service binary file ACLs directly:
(F) (Full) or (W) (Write) for BUILTIN\Users, Everyone, or your user on a service binary running as SYSTEM = binary replacement attack.
Unquoted Service Paths
When a service ImagePath contains spaces and is not quoted, Windows tries each space-delimited prefix as an executable. If you can write to any of those paths, you can place a binary there.
Or with PowerShell:
For a path like C:\Program Files\My App\service.exe, Windows tries:
C:\Program.exeC:\Program Files\My.exeC:\Program Files\My App\service.exe
If you can write to C:\Program Files\My App\, place a My.exe there. Confirm write access first:
AlwaysInstallElevated
If both the HKLM and HKCU AlwaysInstallElevated keys are set to 1, any .msi package runs with SYSTEM privileges — regardless of who executes it.
Both must return 0x1 for the vulnerability to be present. If only one is set, it does not apply.
Both returning 1 = generate a malicious MSI with msfvenom and execute it as a low-privileged user to get SYSTEM. See AlwaysInstallElevated exploitation.
Token Privileges
High-value token privileges on your current session can lead to SYSTEM even without other misconfigs. Check which privileges your token holds:
Exploitable privileges:
Privilege | Attack |
|---|---|
| Potato attacks (GodPotato, PrintSpoofer) |
| Same as SeImpersonatePrivilege |
| Read any file including SAM/NTDS.dit |
| Write any file, DLL hijack into SYSTEM paths |
| Dump LSASS memory, inject into SYSTEM processes |
| Take ownership of any file or registry key |
| Load a malicious driver |
SeImpersonatePrivilege is the most common high-value finding. It is granted by default to IIS AppPool accounts, SQL Server service accounts, and many other service identities.
See the exploitation pages: Token Impersonation and SeImpersonatePrivilege, SeBackupPrivilege Abuse.
UAC Status
UAC controls whether privileged operations require an elevation prompt. If UAC is enabled but misconfigured, a standard user process can auto-elevate without prompting. Check current UAC configuration:
EnableLUA = 0— UAC completely disabled. Any process runs as admin without prompting.ConsentPromptBehaviorAdmin = 0— Elevation happens silently for admin accounts.ConsentPromptBehaviorAdmin = 5— Default: prompt on secure desktop.
Also check if you are already in the local Administrators group but running as a medium-integrity token:
If that SID appears with Group used for deny only, you have admin group membership but a filtered token — a UAC bypass can elevate you to high integrity. See UAC Bypass.
Writable PATH Directories
If a directory writable by your user appears early in the %PATH%, placing an executable there that shadows a system binary is a privilege escalation path when a privileged process calls that binary without a full path.
Check write access on each directory:
If any PATH entry allows user writes and a scheduled task or service runs with an unqualified command (e.g. python script.py without full path), you can replace python.exe in that directory.
Weak Registry Permissions on Service Keys
Service configuration is stored in the registry. If you can write to a service's registry key, you can change its binary path.
Or with PowerShell:
FullControl or SetValue for a non-admin user on a service key that runs as SYSTEM = change the ImagePath to your payload.
Scheduled Tasks
Scheduled tasks running as SYSTEM or a privileged account with a writable binary or script are escalation paths.
For each high-privilege task, check if you can write to the binary or script it executes:
DLL Search Order Hijacking
Processes that load DLLs without a full path search directories in a predictable order. If the application directory or another early search path is writable by your user, place a malicious DLL there.
Check for missing DLLs loaded by running processes using Process Monitor (Sysinternals) on a Windows lab host. In the field, check application directories for write access:
If writable, check what DLLs the application loads by examining imports:
DLL hijacking requires restarting the service or application — confirm you have a way to trigger a restart before placing the DLL.
Stored Credentials
Saved credentials in the Windows Credential Manager, unattend files, and registry can give you plaintext passwords for privileged accounts without any exploitation.
Plaintext credentials in any of these = direct privilege escalation via runas or Impacket tools. See Stored Credential Abuse.
Was this helpful?
Your feedback helps improve this page.