low priv shell to root, the usual privesc path

the reel says "offense" but this post is about closing the door

you've probably seen the clip: low priv shell, a few commands, suddenly you're root. it looks like magic. it's not magic, it's just a checklist that attackers run on autopilot because most systems never bother to lock down the basics. if you run linux boxes, this is the exact checklist you should run against yourself before someone else does.

the goal here isn't "how to pop root on a machine you don't own." it's "here's the well known path attackers walk, so you can go find it on your own servers first and shut it down."

step one: know what you're allowed to run as root

the first move on any freshly landed shell is figuring out who you are and what you're allowed to do.

id
sudo -l

id tells you your user and group memberships. sudo -l lists everything the current user is permitted to run as another user, usually root, without needing the root password again.

the danger isn't sudo itself, sudo is a normal admin tool. the danger is overly broad sudo rules. things like letting a user run an entire scripting interpreter, a text editor, or a file manager as root with no restrictions. gtfobins.github.io keeps a running list of common binaries (vim, less, find, python, tar, and dozens more) that can be abused to break out into a full root shell if sudo access to them is granted. one loose line in /etc/sudoers and a "low priv" account is functionally root.

defend it: audit your sudoers file and every account's sudo -l output. never grant sudo on an interpreter, editor, or archive tool unless you truly need it, and if you do, use command restrictions or wrapper scripts instead of a blanket allow.

step two: suid binaries, programs that run as someone else

next on the checklist is hunting for suid binaries, programs that execute with the permissions of their owner instead of the user who launched them:

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

if a binary is owned by root and has the suid bit set, running it means you briefly get root's privileges for that program's execution. that's fine for things like passwd, which is designed for it. it's a disaster when it's an unnecessary, custom, or outdated binary that can be tricked into spawning a shell or reading arbitrary files.

defend it: periodically run that same find command on your own machines. anything unexpected on that list is a red flag. strip the suid bit (chmod -s) from anything that doesn't absolutely need it, and keep the binaries that do need it patched.

step three: cron jobs that anyone can edit

cron jobs running as root are gold for an attacker if the underlying script is writable by a lower privileged user. the pattern is simple: root's cron runs a script every few minutes, that script lives in a directory with loose permissions, and the low priv account edits it to include their own commands. next time cron fires, it runs as root.

cat /etc/crontab
ls -la /etc/cron.d/
find / -writable -path "*cron*" 2>/dev/null

defend it: make sure any script called by a root cron job is owned by root and not writable by group or other. this is one of the most common, most overlooked misconfigurations because it's usually created by accident, someone chmod 777'd a folder to stop fighting permission errors and forgot about it.

the tool that automates all of this: linpeas

linpeas is an enumeration script that runs all of the above checks, plus a lot more, and highlights the risky findings in color. attackers use it to save time. defenders should use it the exact same way, run it against your own servers as a routine health check.

curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh -o linpeas.sh
sh linpeas.sh

read the output like a to-do list. anything flagged in red or yellow is something an attacker with a foothold would go straight for.

the takeaway

privesc paths aren't exotic zero days, they're almost always leftover misconfigurations: a sudo rule that's too generous, a suid binary nobody remembers granting, a cron script with the wrong permissions. run sudo -l, check for suid binaries, check your cron jobs, and run linpeas on your own boxes on a schedule, not just after something goes wrong. the whole point of knowing the attacker's checklist is so you can cross every item off it before they get the chance.