PWNMI

Guides

Privilege Escalation Fundamentals: From a Foothold to Root or SYSTEM

Updated July 28, 2026 · Written by PWNMI — see About.

Getting a shell on a target is rarely the finish line — it's usually a low-privileged foothold, and the actual objective (reading a database, moving to another host, proving full compromise) needs more access than that foothold has. Privilege escalation is closing that gap. The specific techniques differ wildly between Linux and Windows, but the underlying reason privesc is almost always possible is the same one, regardless of operating system.

Horizontal vs. vertical

Two different things get called "privilege escalation," worth keeping separate:

  • Vertical escalation — going from a lower privilege level to a higher one: a normal user to root, a standard account to NT AUTHORITY\SYSTEM, a low-privileged domain user to Domain Admin. This is what both OS-specific checklists on this site cover.
  • Horizontal escalation — staying at the same privilege level but gaining access to another account or resource at that level, like accessing another regular user's files without becoming root. Less dramatic than vertical escalation, but often just as damaging, and easy to overlook when "privesc" gets used to mean only the vertical case.

Why this is possible on every system

Every privilege escalation bug, regardless of platform, comes down to some version of the same thing: something running with more privilege than you have trusts input, state, or a binary that you can actually influence. That general shape breaks down into a handful of recurring categories:

  • Misconfigured permissions. A file, service, or scheduled task that runs with elevated privilege but is writable, or configurable, by someone without that privilege. This is the majority of what both OS checklists on this site actually check for — SUID binaries and cron jobs on Linux, service ACLs and scheduled tasks on Windows. See the Privilege Escalation Techniques labs to work through this exact category hands-on: SUID abuse, sudo misconfiguration, cron hijacking, capabilities abuse, and a writable /etc/passwd.
  • Exposed credentials. A password, hash, or key sitting somewhere a lower-privileged account can read, that belongs to a higher-privileged one — config files, registry hives, command history, backup files.
  • Trusted-binary abuse. A legitimate, expected binary that can be coerced into doing something beyond its intended use once it's running with elevated privilege — the entire premise behind GTFOBins on Linux and LOLBAS on Windows.
  • Software and kernel exploits. An actual vulnerability in the OS kernel or a privileged piece of software, rather than a configuration mistake. Usually the noisiest, least reliable option, and the one to reach for last, not first — configuration-based routes are more common, more reliable, and less likely to crash something. See CVE-2026-53264 for what this category actually looks like in practice, race window and all.

How this site's privesc content fits together

  • Script Privilege Escalation — a Linux checklist scoped specifically to scripts running as root via cron or sudo, the single most common CTF and real-world pattern.
  • Windows Privilege Escalation — the broader Windows equivalent: service misconfigurations, stored credentials, dangerous token privileges, scheduled tasks.
  • GTFOBins and LOLBAS — the trusted-binary-abuse category on each platform, referenced constantly from both checklists above rather than duplicated into them.
  • Once you've escalated on a single host, domain-level escalation is a different problem with its own guide — see the Active Directory attack chain.

Common mistakes

  • Reaching for a kernel exploit first. It's the loudest, least reliable option and the last thing most experienced testers try, not the first — configuration-based routes above are more common and less likely to crash the box.
  • Stopping at the first automated tool's output. winPEAS, linPEAS, and similar scripts surface candidates; they don't tell you which one is actually exploitable in this specific context. Understanding why a flagged item works is what separates running a script from actually doing privesc.
  • Treating "I have a different shell" as proof of escalation. Confirm the actual privilege level directly (id, whoami /priv) before and after — a shell that feels different isn't the same as a verified privilege change.

Next step

Pick the OS: Script Privilege Escalation for Linux, Windows Privilege Escalation for Windows. For the trusted-binary-abuse technique both reference, see GTFOBins and LOLBAS.