I’ve lost count of how many internal pentests I’ve been on where getting the initial foothold was the easy part, and the real work started the moment I landed on a Windows box with a low-privilege shell. Windows privilege escalation is the skill that separates a report full of “we got a shell” screenshots from a report that shows real business risk: domain admin, access to file shares full of sensitive data, or control over the systems that run the client’s business.
In this guide I’m walking through the practical, repeatable checklist I run every time I land on a Windows host during an authorized engagement. This isn’t theory — it’s the order of operations I actually use, the commands I actually type, and the mistakes I’ve actually made along the way.
What Windows Privilege Escalation Actually Means
Privilege escalation is the process of turning limited access into greater access. On Windows, that usually means going from a standard user (or a service account with restricted rights) to NT AUTHORITY\SYSTEM, a local administrator, or in a domain context, to Domain Admin.
There are two broad categories worth knowing before you touch a keyboard:
- Vertical privilege escalation — moving from a lower privilege level to a higher one (user → admin → SYSTEM).
- Horizontal privilege escalation — moving sideways, gaining access to another account’s resources at the same privilege tier.
Most of what I cover here is vertical escalation on a single Windows host, which is usually the first domino that leads to lateral movement and, eventually, full domain compromise.
Why This Matters
Clients don’t pay for a list of open ports. They pay to understand what happens if an attacker gets a foothold — and on Windows networks, privilege escalation is almost always the pivot point. A single misconfigured service, an unquoted path, or a stored credential can turn a helpdesk-level compromise into a full domain takeover. Understanding these paths isn’t just an offensive skill — it directly informs the hardening recommendations you’ll give the client afterward.
Before You Start: Authorized Lab Environments Only
Everything below assumes you are working inside a scope you’re authorized to test — a signed engagement, a home lab (Windows Server evaluation ISOs are free from Microsoft), or a practice platform like HackTheBox, TryHackMe, or a self-hosted Active Directory lab such as GOAD. Running these techniques against systems you don’t own or have explicit written permission to test is illegal in most jurisdictions. Build a lab, get comfortable there, and only apply this on engagements you’re contracted for.
Initial Situational Awareness
The first thing I do on any new box is figure out who I am and what I’m working with.
whoami /all
This prints your current user, group memberships, and — critically — your token privileges. Some privileges (like SeImpersonatePrivilege or SeBackupPrivilege) are an instant path to SYSTEM if present, so I always check this first before running anything heavier.
systeminfo
This gives you the OS version, build number, and installed hotfixes. It’s slow, and on a modern engagement I usually pipe it into a script or just grab Get-HotFix in PowerShell for something faster, but it’s useful for spotting an unpatched kernel that’s vulnerable to a known local exploit.
net user %username%
net localgroup administrators
These tell you what groups you belong to and who else has admin rights — useful for understanding your ceiling and who to target for credential theft later.
Automated Enumeration Tools
Manual enumeration teaches you the “why,” but on a real engagement, time is limited, so I always run an automated enumeration tool alongside manual checks.
WinPEAS
WinPEAS is one of the most thorough Windows enumeration scripts available. It checks for misconfigured services, weak file permissions, AutoLogon credentials, unattended install files, scheduled tasks, and dozens of other common misconfigurations.
winPEASx64.exe
Run it, then read the output carefully — it color-codes findings by likely severity, but don’t just chase the red text. Some of the most useful findings (like a plaintext password in a config file) show up in yellow or even white.
Seatbelt
Seatbelt is a C# tool built for security assessment and is particularly good at surfacing things like AutoLogon credentials, WSUS misconfigurations, and installed AV products.
Seatbelt.exe -group=all
PowerUp
PowerUp is a PowerShell script focused specifically on privilege escalation vectors — unquoted service paths, weak service permissions, and registry AlwaysInstallElevated settings.
Import-Module .\PowerUp.ps1
Invoke-AllChecks
I usually run more than one of these tools because they don’t all check for the exact same things, and cross-referencing catches more.
Step-by-Step Manual Enumeration Methodology
Automated tools are great, but understanding the manual technique behind each check is what makes you effective when a tool gets flagged by EDR and you have to do it by hand.
1. Check for Unquoted Service Paths
If a service’s binary path contains spaces and isn’t wrapped in quotes, Windows will try each space-separated segment as a potential executable.
wmic service get name,displayname,pathname,startmode | findstr /i /v "C:\Windows\\" | findstr /i /v """
If you find a vulnerable path like C:\Program Files\Some App\service.exe, and you have write access to C:\Program Files\, you can drop a malicious Some.exe and Windows will execute it instead when the service restarts.
2. Check Service Permissions
Even if the path is quoted, the service itself might have weak permissions letting you reconfigure its binary path entirely.
accesschk.exe -uwcqv "Authenticated Users" *
If your user can modify a service that runs as SYSTEM, you can point it at your own payload:
sc config <servicename> binpath= "C:\payload.exe"
sc start <servicename>
3. Check for AlwaysInstallElevated
This registry misconfiguration lets any user install MSI packages with SYSTEM privileges.
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
If both keys return 1, you can build a malicious MSI with msfvenom and install it for an instant SYSTEM shell.
4. Hunt for Stored Credentials
Windows machines are full of forgotten credentials. I check:
- Unattended installation files:
C:\Windows\Panther\Unattend.xml - PowerShell history:
Get-Content (Get-PSReadlineOption).HistorySavePath - Saved RDP credentials via
cmdkey /list - Configuration files for web apps, scheduled tasks, or scripts referencing plaintext credentials
5. Check Scheduled Tasks
schtasks /query /fo LIST /v
Look for tasks running as SYSTEM or an admin account that point to a script or binary in a directory you can write to.
6. Kernel Exploits (Last Resort)
If the box is unpatched and no configuration-based path exists, a kernel exploit like a known CVE for the specific build might work. I treat this as a last resort on real engagements because kernel exploits can crash a production system — always check with the client before attempting one outside a lab.
A Practical Walkthrough Example
Say whoami /priv shows SeImpersonatePrivilege enabled. This is one of the most reliable paths to SYSTEM, exploitable through tools in the “Potato” family (JuicyPotato, PrintSpoofer, RoguePotato depending on the OS build). In a lab environment:
PrintSpoofer64.exe -i -c cmd
This abuses the named pipe impersonation flow to spawn a SYSTEM-level command prompt. It’s fast, reliable on many modern Windows Server builds, and a great example of why checking privileges first — before diving into service misconfigurations — saves time.
Common Mistakes and Troubleshooting
- Skipping
whoami /priv. I’ve seen people spend an hour hunting for unquoted service paths whenSeImpersonatePrivilegewas staring at them the whole time. - Running noisy tools without considering EDR. WinPEAS and PowerUp are heavily signatured. On engagements where evasion matters, expect detections and have a manual fallback plan.
- Not checking architecture. Running the x86 build of a tool on an x64 system (or vice versa) causes silent failures — always confirm with
systeminfofirst. - Forgetting to check for AV/EDR before dropping binaries. Dropping an unmodified WinPEAS binary onto a monitored endpoint will often trigger an alert; that’s a finding in itself, and you should document it.
- Ignoring low-severity findings. A yellow “informational” finding in WinPEAS output is sometimes the missing piece that combines with another weak finding to form a full exploit chain.
Security Risks and Defensive Recommendations
For the blue team side of the report, here’s what I typically recommend after finding these issues:
- Enforce least privilege — remove unnecessary token privileges from service accounts.
- Quote all service binary paths and audit service ACLs regularly.
- Disable
AlwaysInstallElevatedunless there’s a documented business reason. - Rotate and vault credentials rather than storing them in scripts or unattended install files.
- Deploy EDR with behavioral detection for known privilege escalation tool signatures.
- Patch consistently — most kernel exploit paths only work against unpatched builds.
Frequently Asked Questions
1. Is Windows privilege escalation different from Linux privilege escalation? Yes — the underlying concepts (misconfigurations, weak permissions, credential exposure) are similar, but the specific mechanisms differ significantly, since Windows relies on services, tokens, and the registry rather than SUID binaries and cron jobs.
2. Do I need to be an expert in PowerShell to do this well? Not an expert, but comfortable reading and lightly modifying PowerShell scripts will make you far more effective, since most enumeration tooling is PowerShell or C#-based.
3. What’s the fastest single check that often pays off? Checking token privileges with whoami /priv — a SeImpersonatePrivilege finding often means an almost immediate path to SYSTEM.
4. Are these techniques detected by modern EDR? Many are, especially well-known tools like WinPEAS and PowerUp. On engagements focused on evasion, expect to modify or rebuild tooling to avoid signature-based detection.
5. What’s the best way to practice this legally? Build a home lab with Windows Server evaluation licenses, or use legal practice platforms like HackTheBox, TryHackMe, or Proving Grounds.
6. Should I always go for SYSTEM, or is local admin enough? It depends on the engagement goals. SYSTEM gives you full control including access to LSASS memory for credential dumping, which is often needed for further lateral movement.
7. What should I do if none of these checks find anything? Widen the net — check for DLL hijacking opportunities, review third-party software installed on the host, and look for outdated drivers with known local privilege escalation CVEs.
Conclusion
Windows privilege escalation isn’t about memorizing one magic exploit — it’s a methodology. Start with situational awareness, run automated tools alongside manual checks, and work through misconfigurations systematically: token privileges, service permissions, registry settings, stored credentials, and scheduled tasks. Every environment is different, but this checklist has consistently gotten me from a limited shell to SYSTEM across dozens of authorized engagements. Practice it in a lab, document everything, and always test within the bounds of your authorization.
