Windows Privilege Escalation: A Complete Pentester Guide

Windows privilege escalation is the process of turning a low-privileged foothold on a Windows host into SYSTEM or Domain Admin access, and it is the step that decides whether a single phished laptop stays a contained incident or becomes a full domain compromise. Authorised penetration testers escalate privilege through structured enumeration — whoami /priv, service permissions, scheduled tasks, registry autoruns — followed by exploitation of misconfigurations like unquoted service paths, weak service ACLs, AlwaysInstallElevated, or token impersonation via Potato-family attacks. Nearly every technique below traces back to one root cause: a misconfigured permission that lets a standard user control something SYSTEM trusts.

For Indian enterprises running Windows Server fleets, AD-joined endpoints, and legacy on-prem applications, this is one of the most consistently exploitable weaknesses found during internal penetration tests — and one of the cheapest to fix once identified.

Why Privilege Escalation Matters More Than the Initial Foothold

Attackers rarely land as Administrator. Phishing, a vulnerable web app, or a leaked credential typically grants a low-privileged shell first. What happens next determines the blast radius. A host that resists privilege escalation limits an intruder to whatever that one low-privileged account can touch. A host riddled with misconfigured services, weak file permissions, or unpatched local exploits hands the attacker SYSTEM in minutes — and SYSTEM on a domain-joined machine is frequently the pivot point to Domain Admin via cached credentials, token theft, or lateral movement.

This is why authorised internal penetration tests spend disproportionate time on privilege escalation methodology: initial access gets you in the door, privilege escalation gets you the keys.

Step One: Systematic Enumeration

Privilege escalation is rarely a single exploit — it is the product of patient enumeration across several Windows subsystems. A pentester walks through the same checklist on almost every engagement:

1. whoami /priv — lists the current user's enabled privileges. SeImpersonatePrivilege, SeAssignPrimaryTokenPrivilege, SeBackupPrivilege, and SeDebugPrivilege are all direct escalation paths if present and enabled.
2. whoami /groups — reveals group memberships that grant implicit rights, including nested AD group membership.
3. Service enumeration — sc query, wmic service list, or Get-WmiObject win32_service to list running services, their binary paths, start type, and the account they run as (frequently LocalSystem).
4. Scheduled tasks — schtasks /query /fv to find tasks running as SYSTEM or an elevated service account, and whether the script or binary they invoke is writable.
5. Registry autoruns — HKLM\...\Run keys and AlwaysInstallElevated values, checked via reg query.
6. File and folder permissions — icacls against service binaries, installation directories, and scheduled task scripts to spot where a low-privileged user has Write or FullControl.
7. Installed software and patch level — wmic qfe list and installed application inventory, cross-referenced against known local privilege escalation CVEs for that build.

Common Misconfiguration Classes

Unquoted Service Paths

When a Windows service's binary path contains a space and is not wrapped in quotes, Windows attempts to resolve the path by testing each space-delimited segment as a potential executable, starting from the leftmost. A service configured with C:\Program Files\My App\service.exe (no quotes) causes Windows to first try C:\Program.exe, then C:\Program Files\My.exe, before finally reaching the intended binary. If an attacker has write access to C:\ or any intermediate folder and can drop a malicious Program.exe, restarting that service — or waiting for a reboot — executes attacker code with the service account's privileges, often LocalSystem.

Weak Service Permissions

Even with a correctly quoted path, a service is exploitable if the binary, its folder, or the service configuration itself is writable by a low-privileged user. icacls and accesschk reveal these gaps. Three common variants:

1. Writable binary — replace the service executable directly.
2. Writable service registry key — modify ImagePath in HKLM\SYSTEM\CurrentControlSet\Services\<name> to point at an attacker binary.
3. Weak service DACL — the service object itself grants SERVICE_CHANGE_CONFIG to a low-privileged group, letting an attacker repoint the binary path via sc config without ever touching the filesystem.

AlwaysInstallElevated

If both HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated and the equivalent HKCU key are set to 1, any user can install an .msi package with SYSTEM privileges — no admin consent prompt. An attacker generates a malicious MSI, runs it with msiexec, and receives a SYSTEM shell. It is a legacy Group Policy setting almost never intentionally required, and its presence is close to an automatic finding on any test.

Token Impersonation — SeImpersonatePrivilege and Potato Attacks

Service accounts (IIS application pools, MSSQL, many third-party agents) are frequently granted SeImpersonatePrivilege so they can impersonate a client's security token during legitimate operations like named-pipe communication. The Potato family of exploits (RottenPotato, JuicyPotato, PrintSpoofer, RoguePotato, GodPotato) abuses this privilege by coercing a SYSTEM-level process to authenticate to a local, attacker-controlled listener — typically via NTLM relay over a named pipe or the print spooler RPC interface — and then capturing and impersonating that SYSTEM token. The result is a direct low-privileged-service-account to SYSTEM escalation, without needing any file or registry misconfiguration at all. This is one of the most reliable modern Windows privesc paths because SeImpersonatePrivilege is granted by default to many service accounts and is genuinely required for normal operation, making it hard to simply revoke.

Credential Harvesting on the Host

Once elevated access is achieved, or sometimes before it, pentesters look for stored credentials that extend access further: LSASS memory (via Mimikatz-style dumping, blocked or logged in hardened environments), SAM/SYSTEM registry hive dumps, unattended installation files (unattend.xml, sysprep.inf) left with plaintext credentials, saved RDP credentials, browser-stored passwords, and PowerShell history files. Cached domain credentials on a compromised host are frequently the pivot from a single-machine compromise to broader Active Directory access.

How the Techniques Compare

Defence: Hardening Against Windows Privilege Escalation

No single control stops every technique above — defence is layered:

1. Patch aggressively. Many privesc paths, including several Potato variants and local kernel exploits, are closed by timely Windows updates. Unpatched, internet-facing, or long-uptime servers are disproportionately represented in successful escalation findings.
2. Apply least privilege to service accounts. Audit which accounts genuinely need SeImpersonatePrivilege, SeDebugPrivilege, or local admin rights, and strip what is not required — the principle NIST's access control guidance formalises as AC-6. Not every IIS app pool needs the defaults it ships with.
3. Harden service configuration. Quote every service path containing spaces, lock down icacls on service binaries and folders to admin-only write, and audit SERVICE_CHANGE_CONFIG grants with accesschk or equivalent.
4. Disable AlwaysInstallElevated unless there is a documented, current business reason — there rarely is.
5. Deploy LAPS (Local Administrator Password Solution). Unique, automatically rotated local admin passwords per machine prevent a single cracked local admin credential from becoming a domain-wide pivot — one of the highest-impact, lowest-effort controls available for Windows fleets of any size.
6. Protect LSASS and enable Credential Guard where hardware and edition support it, to blunt credential-dumping post-exploitation.
7. Monitor for anomalous named-pipe, RPC, and service-configuration-change activity, since Potato-family attacks and service reconfiguration both leave detectable event log signatures if logging is properly tuned.

Building Privesc Resistance Into Your Security Programme

Fixing individual findings after a single pentest report is necessary but not sufficient — the same misconfiguration classes reappear as new servers are provisioned. Baking service-permission audits, LAPS deployment, and patch cadence into standard build processes closes the gap for good, rather than for one test cycle. Under India's DPDP Act 2023, a privilege escalation that leads to unauthorised access of personal data is a reportable incident with real compliance consequences, making proactive hardening a governance issue as much as a technical one.

Regular authorised internal penetration testing — ideally combining automated configuration scanning with manual escalation testing, delivered with a CERT-In empanelled partner for regulated engagements — is what catches these misconfigurations before an attacker does. Bachao.AI, built by Dhisattva AI Pvt Ltd, walks this enumeration-to-escalation chain across Windows estates of any size as part of its testing methodology. See the Bachao.AI blog for more pentesting methodology writeups, our DPDP compliance guide for the regulatory angle, or book a free VAPT scan to see where your Windows environment stands.