OSCP Prep: Introducing My Runbooks —RCE on Linux

As cliché as it sounds, getting through the OSCP is all about becoming good at enumeration. While going through the certification, I read the phrase “enumerate harder” by many former students, and I’m here to tell you it’s true. This write-up is the second in my series explaining my runbooks for enumerating machines at an OSCP level. If you are wondering “What is a runbook?” or “How do I do the initial enumeration of the machine from the outside?”, have a look at my first write-up on the topic here. I have structured my runbooks such that I start with the runbook from my previous write-up and then dive into OS-specific runbooks depending on whether the machine turns out to be a Linux or Windows box.

This write-up focuses on how to enumerate a Linux machine once you have a shell on the machine. As such, you can follow this runbook once you have reached that point on a Linux box when training for the OSCP or doing a CTF at a similar level. To get a better understanding of how to get remote code execution (RCE) have a look at my initial enumeration runbook linked above.

Manual Enumeration Runbook

While you can get 95% of the way using automated tools to enumerate the machines for you, I prefer to begin the enumeration process of the machines by firing off a few manual commands. Doing it this way reduces my margin of error greatly, as it forces me to look at one thing at a time rather than crawling through an entire LinPeas output in an attempt to find the needle in the haystack that will give me root. The philosophy here is “go slow to go fast”. LinPeas is nice, but sometimes there are quick wins in doing a few simple commands before running your automated tooling.

Shell Stabilization And Getting a Backup shell

Sometimes, we gain initial access through janky exploits that result in unstable shells. This is a hindrance to the workflow when working on the machine. Therefore, it’s best to stabilize the shell straight away. There are a few flavors of this, but I usually just run:

python3 -c 'import pty; pty.spawn("/bin/bash")'

Once I have one stable shell, my next step is to get a backup shell running. Sometimes, even “stable” shells break or get interrupted which can snap me out of where I was about to go next. However, doing the RCE exploit twice is almost as fast as doing it once. So getting a backup shell up and running immediately allows me to focus completely on enumerating the machine and forgetting about the steps before the Linux machine. Once I’m “in”, I want to stay “in”.

Note! This took me way too long to figure out, so here it goes for the rest of you!

When you catch a reverse shell on your Kali Linux machine, e.g. on port 443 with:

nc -nvlp 443

Once the TCP handshake is complete and the connection is established, port 443 is free to be used for the next reverse shell! I see some seasoned CTF players on Youtube etc. choose new ports for their next reverse shells, which is not necessary. Once you find a port that works, keep using it. The added complexity of constantly using new ports just increases the odds of copy/paste errors leading to exploits that don’t work.

Slight tangent, but important to note.

Finding Myself

The first commands I run are usually some combination of:

whoami

ifconfig

hostname

This gives me a basic understanding of “where I am” and what kind of box this is. Remember that both the username and the hostname might be clues to where to look. A lot of boxes will have meaningful names. Can you use that as a clue somehow?

Sudo

The next thing I do, is check if we can anything interesting.

Some boxes will give you an easy win here by allowing sudo on e.g. /bin/bash, but almost anything you find here will be relevant to the box. The command we run to check what we can sudo on is:

sudo -l

For any results this gives, go to gtfobins and look up the binary you can sudo. Are there any exploits?

My next step is checking:

sudo --version

If the output shows sudo is version 1.8.31, the box may be vulnerable to CVE-2021–3156, to which I use this exploit on Github. The first time I did this, I had a few issues with running make on the target box, so I have a version of the exploit in my notes repository, where I have added a compile-flag that makes it possible for you to compile the exploit on your kali machine and transfer the exploit binary to the target so you can try it out. Keep in mind that just because sudo is the given version, this exploit might not work as the system could be patched to avoid the vulnerability. But make sure to try it out.

System Information Gathering

Next, I do this combination of commands to understand a little more about the system information, the system architecture and the kernel:

cat /etc/issue; cat /etc/*-release; uname -r; arch

When running LinPeas later, it might flag several potential kernel exploits we can try out. Correlating them with information from this step can be crucial to find our path to root.

Directory and File Analysis

Look into directories that might contain configuration files or other clues to where an exploit may lie:

• ls /opt; ls /var/mail : These directories sometimes contain software or hints you can use to figure out where to go next.
• cat /etc/passwd: Displays users on the box. To filter out all the machine-users, consider doing something like cat /etc/passwd | grep -e "sh\|bash". This gives you the users set to use either shell or bash.
• ls /home: Lists user home directories. Make sure to check subfolders of any home folders you have access to — including hidden files like .zshrc and similar files that may contain passwords for configuring tools.

Searching with find

• find / -writable -type d 2>/dev/null: Searches for writable directories within the entire filesystem. If you have direct write access to /etc/passwd, this is an escalation factor in itself, because you can add a root user (see how here). But any “interesting” folders you find here may be a route to root.
• find / -type f -name “*.txt” -o -name “*.kdbx” -o -name “*.zip” 2>/dev/null: Identifies files with specific extensions (.txt, .kdbx, .zip). You can add more file extensions to this list if you like. The idea is just to look for “interesting” files across the filesystem.
• find / -perm -u=s -type f 2>/dev/null: Locates files with the setuid (SUID) bit set. For any results you find here, check gtfobins for suid privilege escalations. Keep in mind that each Linux distro comes with a set of binaries that are supposed to have the suid bit set, such as passwd. So not all the binaries in this list will be interesting.

Cronjobs

Commands for checking cronjobs of various privilege levels:

• crontab -l
• sudo crontab -l
• ls -lah /etc/cron*

This is the only part of my manual enumeration that I have removed from my runbook, because the overview of the automated tooling in the next section provides such a great overview. I have included it here for completeness, though.

Automated tooling

Run the following two tools:

LinPeas

The purpose of LinPeas is to automate all the above manual enumeration commands and more. It will give you information about interesting cronjobs, folders you can write to, CVEs and kernel exploits potentially relevant to the machine and so much more. Diving into each section in LinPeas could be an entire write-up in itself (or a series of write-ups, for that matter). The TL;DR here is to check each section carefully.

Pspy

The purpose of pspy is to monitor processes running on the box. It doesn’t require root, but it will pick up processes running as root. This tool is so good that I have stopped spending much time trawling through crontabs manually. Instead, I do something like:

timeout 5m ./pspy64

This starts the pspy64 binary and stops it after five minutes. Otherwise, it will run indefinitely, and most reverse shells won’t survive the SIGINT signal you send when hitting CRTL+C (if you happen to use CRTL+C at some point, use your backup shell as I described above). So rather than burning a shell by running pspy, I set a timeout on the process so it doesn’t run indefinitely.

Also, most machines at the OSCP level are 64-bit. So I usually default to using 64-bit variants of my tools unless I notice I am hacking a 32-bit box during my initial manual enumeration commands.

Final Remarks

As mentioned in my write-up on the initial enumeration of machines, your process will be different from everybody else’s. However, I believe finding your groove with tackling boxes is what will get you through the OSCP and a runbook is one tool to do that. I have found that having something I could always go back to after a deep rabbit hole helped me a lot during my practice. However, it’s not a magic formula. No list of actions will get you from zero to hero overnight. What gets you there is the hard work you put in!

Lastly, if you want to dive into my notes unorganized notes from the OSCP and other red-teaming exercises, feel free to have a look at my Github Repository with my notes here.

Also, I’m not super active on socials but feel free to give me a follow on X (or is it Twitter?)