journey // user to root

that reel is dramatic but the truth is boring: a "normal user becomes root" walkthrough almost always ends with one tiny, unglamorous misconfiguration. no matrix code, no magic. just a system that trusted the wrong file, the wrong permission, or the wrong cron job. let's break down what's actually happening and how you check your own machines before someone else does it for you.

what "privilege escalation" really means

privilege escalation is just going from a low-permission account to a high-permission one, usually root. root can read, write, and execute anything on the system. it's not a single exploit, it's a category of "the system gave more trust than it meant to." on linux, that trust leak usually hides in one of four places: suid binaries, sudo rules, scheduled jobs, or a broken path.

why the video opens with whoami

whoami is the first command in almost every privesc demo because it's the checkpoint. you run it before you start poking around to confirm you're a regular user, and you run it again at the end to confirm you're root. it's not doing any hacking, it's just telling you who the system currently thinks you are.

whoami

on a healthy system this should always return your actual username, unless you deliberately elevated with sudo. if you ever run it mid session and it silently says "root" without you asking for that, something upstream already escalated for you, and that's your cue to go find out what.

the usual suspects on your own machine

these are the four places attackers check, and the four places you should audit first, because fixing them closes most of the common paths.

find / -perm -4000 -type f 2>/dev/null

that lists every suid binary on the box, meaning any program that runs with the file owner's permissions instead of yours. if you see anything unfamiliar in that list, especially something writable or something you didn't install on purpose, that's a red flag.

sudo -l

this shows what your current user is allowed to run as another user, usually root. a lot of real world escalations happen because someone gave a user sudo rights to a script or binary that can be abused to spawn a shell. review every line here and ask "does this account actually need this?"

cat /etc/crontab
ls -la /etc/cron.d/
crontab -l

scheduled jobs that run as root but call scripts owned or writable by a regular user are a classic escalation path. if a cron job runs as root and points to a file you or any low privilege user can edit, that file is effectively a root shell waiting to happen.

echo $PATH

a misconfigured path, especially one where a writable directory comes before the system directories, lets a malicious binary with a common name get executed instead of the real one. check your path order and make sure nothing user writable sits ahead of /usr/bin or /usr/sbin.

how to actually lock this down

audits are useless without follow through, so here's the short version of fixing what you find. remove the suid bit on anything that doesn't need it with chmod u-s. tighten sudoers entries to specific commands with full paths instead of blanket access, and use visudo to edit that file safely. lock down cron scripts so they're owned by root and not writable by anyone else, chmod 700 and chown root:root are your friends here. and clean up your path so nothing user controlled comes before the trusted system directories.

the takeaway

privilege escalation demos look flashy in a reel, but on real systems it's just careful checking, not clever tricks. run these audits on your own boxes on a schedule, not just after something feels off. the goal isn't to memorize an attacker's playbook, it's to make sure that when you run whoami, the answer never surprises you.