This is a scenario that comes up in interviews and in actual assessments often enough that it's worth having a real process for, instead of improvising it every time: you've landed a low-privilege shell, usually as www-data or a similarly restricted service account, and you need root. sudo -l comes back empty or asks for a password you don't have. What now?
Start with SUID, because it's the cheapest check
find / -perm -4000 -type f 2>/dev/null lists every binary with the setuid bit set, meaning it runs as its owner (often root) regardless of who executes it. This takes seconds and costs nothing. Most boxes have a long, boring list of expected entries: passwd, sudo, su, mount. What you're looking for is anything unexpected in that list, or anything expected that shouldn't have SUID at that path.
Once you have a candidate binary, check it against GTFOBins before trying to reason out an exploit yourself. GTFOBins catalogs the SUID abuse, sudo abuse, and file-read/write primitives for a huge list of standard Unix binaries. find, vim, less, cp, tar and python all have documented privilege escalation primitives when they carry SUID or an unrestricted sudo entry. Checking a name against that list before hand-deriving an exploit will save you real time.
If sudo -l gave you anything, don't skip it
An empty sudo -l is common, but a non-empty one is often solved territory. Any line that allows running a binary as root, even with a restricted argument, is worth cross-referencing against GTFOBins the same way. (root) NOPASSWD: /usr/bin/find is a fully solved escalation, not a partial one. The mistake here is assuming a restricted sudo entry with one allowed binary is safe because it's "just one command" — several single commands are enough on their own.
Capabilities are the modern equivalent of SUID
getcap -r / 2>/dev/null in 2026 finds what SUID enumeration used to catch alone. Linux capabilities let a binary hold a specific root-equivalent permission (cap_setuid, cap_dac_read_search) without the blunt all-or-nothing SUID bit, and a lot of hardening guides that tell you to "remove unnecessary SUID bits" don't mention checking capabilities at all, so this list is frequently longer than the SUID one on a box someone thought they'd locked down.
Cron jobs and writable service files
cat /etc/crontab, then check anything it calls for a script or binary path you can write to. A cron job that runs as root but executes a script in a world-writable directory, or a systemd service file you have write access to that runs as root, both hand you the same outcome: write your payload where the privileged process will read it, wait for the next run.
PATH hijacking, when a script calls a binary by name, not by full path
If a root-run script or cron job calls mysql or python without a full path, and your current directory or a writable directory is earlier in that process's PATH than the real binary, you can plant your own binary with that name and get it executed as root. This is a narrower case but worth checking whenever you've already found something that runs as root without obviously being exploitable another way.
The honest version of this: none of these steps are exotic, and that's the point. The overwhelming majority of real privilege escalation on Linux boxes is one of the five things above, checked in order, not a novel kernel exploit. Codelivly's Linux Privilege Escalation Playbook covers this enumeration workflow through container escape and hardening across 12 labs. The free Privilege Escalation learning path and the SUID Treasure Hunt CTF are a good place to practice the SUID-enumeration step specifically before going deeper.
