InfoSec Prep: OSCP VulnhubWalkthrough


The InfoSec Prep Discord server ( ) works closely with the Offensive Security staff. As such, OffSec gave our server an OSCP voucher code to give away.

The voucher code will allow anyone to have 30 days in the labs, receive the course materials (videos + PDF), and most importantly the exam attempt.

The staff for InfoSec Prep wanted to create a challenge for the give away rather than do a typical “click this emoji” and pray to the RNG based gods that you win. No, we decided it would be best to create what we considered to be an easy box. We chose this level to allow entrants of all backgrounds to try to win this voucher.

So we created a box and posted it on VulnHub:,508/

The rules for this box and give away were simple. Perform a boot-to-root penetration test against our box, obtain the root flag, and submit it to our Discord bot: TryHarder.

Once you submitted the flag that’s it you were entered into the give away.

After user’s started pouring into the exclusive channel for proper flag submissions, we learned about some unintended privilege escalation methods for this box we created. In total, there was 1 intended foot hold path, 1 intended root path, and 3 unintended root paths discovered.

In this walkthrough we will cover the intended path and 2 of the 3 unintended paths. The path we will not cover is from a physical access perspective of the VM. Since this is something you wouldn’t have access to in the OSCP Labs or Exam we won’t be covering it.

Intended Path

Foothold / User Access

Upon booting up our VM you should be presented with a login screen and the IP address of the box. The IP is displayed to make things easier for beginners. Normally during a penetration test, you might have to scan for the target unless you are exclusively told to attack a set of targets.

So at this point you would kick off your nmap scan with whatever NSE scripts and options you would want to throw at this box.

You’ll see it’s running a few services. You’ll want to check out the web service its running.

Now at this point depending on what nmap NSE scripts you ran, you may already see something interesting. If not then you may have already kicked off some Nikto, gobuster/dirsearch/dirb/dirbuster scans to look for more interesting things. You might have even visited the webpage (which holds a key piece of information):

The user to the box is oscp per the only hint we gave you for this box.

By now your web based scanning tools should have came back with something interesting. Specifically the robots.txt file or maybe it already found the secret.txt file. Upon visiting this file you will see a bunch of text which was actually base64 encoded:

Throw the base64 encoded text through base64 decoder via cat file.txt | base64 -d and you’ll actually see it’s a private key to the oscp user: (I chose to just curl it for my below example)

Copy this into a file like id_rsa or whatever you choose to name it.

Then simply ssh oscp@IP_ADDRESS -i id_rsa and you are in!

Intended Privilege Escalation: suid bash binary

Once you’re in the system you’ll probably kick off one or many post-exploitation scripts like: Linux Smart Enumeration, LinPEAS, etc.

You might have noticed the permissions on /bin/bash are a bit off. Usually /bin/bash does not have the setuid bit set:

From here you would simply type /bin/bash -p to get root:

Unintended Privilege Escalation #1: ip script

The write up for this method was done by tjc_#5043 on Discord

Gathering Info

Once logged in as the oscp user you can see that the ip script is in the oscp home directory. It is owned by root but we have the ability to read it.

To see how it is called we can run a grep search. The most likely spot to search is the /etc/ directory:

This returns:

We can then check the ip-update service to see exactly how it is called.

Which returns:

Since no user information is present we know that the ip script is run as root. Since the script is in the oscp user directory we can rename the current script and create our own that will be run as root.

Listing /root/ Files

The WordPress post tells us the flag is in the /root/ directory. So the first step is to list all the files in that directory. Rename the current ip script, create a new one and make it executable:

Edit the new ip script with the following:

Now reboot the virtual machine. When it reboots our script will be run and we see the following:

Retrieving the Flag

Now we know the name of the file, we can edit the ip script once again to copy the contents to the oscp user directory:

One more reboot and the flag will be located in the oscp home directory and owned by oscp.

Unintended Privilege Escalation #2: lxd/lxc

The write up for this method was done by TrenchesofIT (JJ)#5548 on Discord — you may view his write up at

oscp user’s groups

Downloading lxd-alpine-builder github repo

Downloading to Victim

Running a simple web service on our Kali

Downloading it on our victim

The LXD Setup

LXC is not in the default bin so lets find out where we need to specify execution from.

/snap/bin/lxc is what I use for LXC commands moving forward. Lets import the image.

Create a storage pool and assign storage location.

Initiate the instance using the name “trenchesofit” or the alias specified during the image import.

Mount the host file system and start the instance.

-bash-5.0$ /snap/bin/lxc start ignite

Now execute bash on the container. You will see we are now root on the container.

We initially mounted the host file system in the /mnt/root of the container.

Now we have permissions to navigate to /mnt/root/root and view the flag.txt

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store