Linux — The Privesc Puzzle

Category: Linux/Privesc · Difficulty: Medium

Scenario

You have low-privileged SSH access to a training box as user analyst. Your goal, as in a real privilege escalation scenario, is to find a path from this limited account to root — and read the flag sitting in /root/flag.txt, which only root can access.

Provided data

The very first thing any privesc checklist tells you to run — and exactly what you did:

analyst@kashsec-box:~$ sudo -l
Matching Defaults entries for analyst on kashsec-box:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User analyst may run the following commands on kashsec-box:
    (root) NOPASSWD: /usr/bin/find

analyst@kashsec-box:~$ cat /root/flag.txt
cat: /root/flag.txt: Permission denied

Your task

You're allowed to run exactly one binary as root, with no password required: /usr/bin/find. find is not an obvious "hacking tool" — but it has a well-documented feature that turns this into full root access.

Hint 1

This exact scenario — a seemingly harmless binary allowed via passwordless sudo that turns out to grant full root access — is common enough in real environments that there's an entire public database cataloging which common Unix binaries can be abused this way, and exactly how. Path 16's Linux privesc lesson mentions this resource by name.

Hint 2

find supports an -exec flag, letting it run an arbitrary command against every file it matches. Since you're allowed to run find itself as root via sudo, any command you chain onto it with -exec also runs as root.

Hint 3

You don't need to actually search for anything meaningful — find just needs *a* starting point to search from before its -exec clause fires. A common pattern is pointing it at a small, guaranteed-to-exist location, then using -exec to spawn a shell instead of doing anything with the found files.

Show full answer

The classic GTFOBins technique for find is:

sudo find /etc/hostname -exec /bin/sh \; -quit

This tells find to "search" starting at /etc/hostname (a file guaranteed to exist on virtually any Linux system, used here purely as a valid starting argument) and, for the match it finds, -exec a shell (/bin/sh) instead of doing anything file-related — -quit stops after the first result so it doesn't loop. Because the entire find process (including everything it spawns via -exec) is running as root thanks to the passwordless sudo rule, the spawned shell is also root. From that root shell, cat /root/flag.txt now succeeds.

The flag

KASHSEC{f1nd_3xec_1s_a_r00t_sh3ll}

Why this matters beyond the CTF

This is not a contrived puzzle — find, vim, less, awk, python, and dozens of other everyday Unix binaries have documented sudo-abuse techniques exactly like this one, catalogued publicly on GTFOBins, a resource you'll see referenced repeatedly throughout Path 03 and Path 16. The underlying lesson generalizes far beyond find specifically: any binary granted elevated privilege inherits the full power of every feature that binary has — including features (like arbitrary command execution via -exec) that have nothing to do with the reason it was granted sudo access in the first place. Real system hardening means auditing sudo -l output against GTFOBins during every privilege review, not just trusting that a "safe-sounding" binary is actually safe in a privileged context.

Running sudo -l the moment you land on any Linux box — as this challenge opened with — is one of the single highest-value, lowest-effort privilege escalation checks that exists. Automated enumeration tools like LinPEAS (covered in Path 03's Advanced Terminal Lab) run this check automatically alongside dozens of others, but understanding what to do with the result manually, as you just did, is the skill that actually matters.

Bonus round — a second sudo rule, no GTFOBins entry needed

Suppose the box instead gave you this sudo -l output:

User analyst may run the following commands on kashsec-box:
    (root) NOPASSWD: /usr/bin/systemctl restart backup-agent.service

No file-search flags, no obvious -exec-style feature — systemctl restarting one specific service doesn't look like an escalation path at all.

Hint

What determines what actually runs when that service restarts? Is that something the sudo rule controls, or something defined somewhere else entirely — somewhere analyst might have write access to?

Show answer

It depends entirely on who can write to the service's unit file (typically under /etc/systemd/system/) or whatever script/binary that unit file points to. sudo only restricts which command analyst can run as root — it says nothing about the contents of backup-agent.service itself. If analyst can write to that unit file (check with ls -la /etc/systemd/system/backup-agent.service) or to the script it executes, they can point it at anything — including ExecStart=/bin/sh -c "chmod u+s /bin/bash" — then trigger it with the permitted sudo systemctl restart command, and it runs as root. This is exactly the same underlying lesson as the main challenge, generalized: a narrowly-scoped sudo rule is only as safe as everything that command's execution actually depends on — file permissions, environment variables, config file contents — not just the command name itself. Real privesc enumeration checks all of these layers, not just the sudoers entry in isolation.

🎓 Section complete

You've now worked through all seven challenges in the CTF Zone — Web (IDOR and JWT forgery), Crypto (layered encoding and known-plaintext XOR cryptanalysis), Forensics (log analysis), Misc (hidden data), and Linux privilege escalation. This is genuinely representative of what a real CTF competition or authorized penetration test day-to-day looks like: methodical enumeration, hypothesis testing, and applying concrete technical knowledge under uncertainty. When you're ready for the next level, TryHackMe and Hack The Box (referenced throughout this course) offer hundreds more challenges across exactly these same categories.

References

GTFOBins — the definitive, community-maintained database of Unix binary privesc techniques.
CryptoPals — the gold-standard free cryptography challenge set, including the exact known-plaintext XOR technique used in this section.
PicoCTF and TryHackMe — continue practicing across all of these categories and more.

Next up → API — The Order Number That Wasn't Yours