The hardest part of a CTF box is often after you get a shell — you land as a low-privilege user and need root. These are the notes I keep from TryHackMe privesc rooms.
> For CTF labs and authorized testing only.
First: Enumerate Everything
You can't escalate what you haven't found. The questions I answer first:
whoami; id # who am I, what groups
sudo -l # what can I run as root?
uname -a # kernel version (exploits?)
ls -la /home/* # other users' files
sudo -l is the highest-value single command — it often hands you the answer outright.
The Common Paths
| Vector | What to look for |
| Sudo misconfig | A binary you can run as root that spawns a shell |
| SUID binaries | find / -perm -4000 2>/dev/null |
| Cron jobs | Root-run scripts you can write to |
| Writable PATH | A script calling a command by name, not full path |
| Credentials | Passwords in config files, history, backups |
GTFOBins Is Your Friend
If sudo -l shows you can run something like find or vim as root, GTFOBins documents how to turn that into a root shell. For example, find can execute commands:
sudo find . -exec /bin/sh \; -quit
A "harmless" allowed binary becomes a full shell.
SUID Binaries
A binary with the SUID bit runs as its owner, not the caller. If root owns a SUID binary that can run commands or read files, you inherit root's power for that action. Listing them is step one; checking each against GTFOBins is step two.
Automate, Then Verify by Hand
Tools like LinPEAS dump everything in one run — and that's the trap. They produce so much output that beginners drown. I run LinPEAS for coverage, then manually verify the top hits, because understanding why a path works is what makes it transfer to the next box.