Privilege escalation

Authorization first: this is a defender’s autopsy

Everything below assumes a signed engagement with explicit scope — a deliberately vulnerable lab, a CTF box, a machine you own, or a system named in a bug-bounty program. Running enumeration tooling against a host you have no authorization for, or pivoting from a low account to root on someone else’s infrastructure, is unauthorized access in nearly every jurisdiction, full stop. We study the attacker’s enumeration for exactly one reason: you cannot reliably close an escalation path you only understand as a checklist item. Read this as the autopsy a defender runs on their own host — learning to see the SUID bit and the sudo rule the way the attacker does, so the rung is gone from the design before any tester finds it. No weaponized payloads here, only the mechanism that tells you which rung to remove.

The shape of the attack: foothold, enumerate, abuse, persist

Privilege escalation is not a single exploit; it is a phase. The attacker already has code execution as some low-privilege principal — a web user like www-data or IIS APPPOOL, a compromised service account, a CI runner. The goal is vertical movement: from that principal to a higher one (root, SYSTEM, Administrator, a domain admin), which unlocks reading every file, installing persistence, and pivoting to other hosts. The loop is always the same: enumerate the local environment for anything misconfigured, find a primitive that crosses a trust boundary, abuse it to execute code as the higher principal, then establish persistence so the foothold survives a reboot or a password reset.

The crucial mental model is that escalation lives in the gap between who runs a thing and who controls its inputs. Every rung is some component that executes with high privilege but takes an input — a path, a file, a binary, an environment variable — that a low-privilege user can influence. The attacker’s whole job in this phase is to enumerate where those two facts diverge.

Linux: the four rungs that recur

On Linux the same handful of misconfigurations appear over and over, and a senior defender learns to spot each in their own fleet before a tester does.

SUID/SGID binaries. A file with the SUID bit runs as its owner regardless of who launches it — so a SUID-root binary executes as root even when www-data runs it. That is by design for tools like passwd that need a privileged moment. The danger is a SUID binary that does something it shouldn’t: shells out to a helper by relative name (so the attacker prepends a malicious directory to PATH), reads or writes a file the caller names, or is a general-purpose interpreter that should never be SUID at all. A SUID-root program that calls system("tar ...") hands the attacker root the moment they put a fake tar earlier in PATH. The fix is least privilege on the binary: drop the SUID bit unless it is genuinely required, and if it is, the binary must use absolute paths, sanitize the environment, and expose no file or command the caller can steer.

sudo misconfiguration. sudo is meant to grant narrow elevation, but a sloppy /etc/sudoers grants wide. Allowing a low account to run an editor, a pager, or a scripting interpreter as root is effectively granting a root shell, because those programs can spawn subshells or read arbitrary files. NOPASSWD on a binary with a shell-escape is the classic gift. The defender’s reflex: every sudo rule is an exception to deny-by-default, so audit each one by asking “can this exact command, as configured, be turned into arbitrary code execution?” — and if yes, it is a root grant in disguise.

Writable privileged jobs and services. A cron job, systemd unit, or service script that runs as root but lives in a world-writable file (or calls a script in a world-writable directory) lets any user rewrite what root will execute next. The misconfig is the file permission, not the scheduler. The fix is to lock ownership and permissions on everything a privileged scheduler touches, so a low account can never edit the next thing root runs.

Kernel and stale-component exploits. When configuration is clean, the attacker falls back to a known vulnerability in the kernel or a privileged daemon — a CVE in a setuid helper, a kernel bug that grants a local user root. This is the rung you close not with permissions but with patching: an unpatched, end-of-life kernel is a standing local-root primitive for anyone who already has a shell. Kernel exploits are noisier and can crash the box, so a careful attacker tries them last — which is exactly why they signal a host that fell behind on updates.

Windows: same gap, different names

Windows escalation rhymes with Linux — the same “runs high, trusts low” gap — under different mechanisms. Unquoted service paths are the textbook example: a service registered as C:\Program Files\My App\svc.exe without quotes, running as SYSTEM, makes Windows try C:\Program.exe first; if a low user can write to C:\, their binary runs as SYSTEM. Weak service permissions let a low user reconfigure the binary a SYSTEM service launches. DLL hijacking plants a malicious library where a privileged process loads it by an unsafe search order. Token impersonation abuses certain privileges (held by some service accounts) to impersonate a SYSTEM token. AlwaysInstallElevated — a policy that runs MSI installers as SYSTEM — turns any user-supplied installer into a root grant. Different surface, identical root cause: a high-privilege component trusts a path, a permission, or a token that a low-privilege user can influence.

How a defender removes the staircase

The unifying defense is least privilege at every layer, because every rung is a place where privilege was granted more broadly than the task required. Assume a foothold will happen — phishing, a leaked credential, an app bug — and design so the foothold is a dead end. Audit SUID/SGID inventory and strip the bit from anything that doesn’t earn it; treat each sudo rule as an explicit exception and reject any program with a shell-escape; lock ownership and permissions on every file a privileged scheduler or service touches; keep kernels and privileged daemons patched so there is no standing local-root CVE; on Windows, quote service paths, tighten service ACLs, and disable AlwaysInstallElevated. Then add detection for the climb itself — alert on new SUID files, on edits to privileged units, on a service account spawning a shell — so even a rung you missed gets caught. The senior reflex across all of it is the same as everywhere in security: deny by default, grant the minimum, and assume the lower boundary will be breached.