Metasploitable — From Web Enumeration to Database Access and Admin Control

Introduction

When you’re working on a deliberately vulnerable machine, one of the biggest mistakes you can make is looking for a single vulnerability and stopping there.

Sometimes, one small piece of information leads to another.

A version number leads to an exploit.

An exploit leads to credentials.

Those credentials lead to a database.

And that database may eventually give you administrative access to an entire application.

That’s exactly what happened during my exploration of Metasploitable.

Metasploitable is a well-known intentionally vulnerable machine designed for practicing penetration testing techniques in a safe environment.

When I started the machine, I knew one thing:

There were probably many vulnerabilities waiting to be discovered.

The challenge was deciding:

Where should I start?

For this walkthrough, I decided to focus on one interesting attack path involving:

• Network discovery
• Aggressive Nmap scanning
• Web enumeration
• Nikto
• TikiWiki
• Version identification
• Metasploit
• Remote Code Execution
• Database credential discovery
• MySQL access
• Database enumeration
• Administrative access

Let’s get started.

Disclaimer: This walkthrough was performed against the intentionally vulnerable Metasploitable machine in a controlled lab environment for educational purposes.

Step 1 — Discovering the Target Machine

Before attacking anything, I first needed to identify the target machine on my local network.

For that, I used:

arp-scan -l

Why arp-scan?

ARP Scan allows us to discover devices connected to the local network.

It works by sending ARP requests across the network and identifying devices that respond.

Conceptually:

My Machine
    ↓
Who is connected to this network?
    ↓
ARP Requests
    ↓
Available Devices

After running the scan, I identified the IP address of the Metasploitable machine:

192.168.170.130

Now that I had the target IP address, it was time to start reconnaissance.

Step 2 — Aggressive Nmap Scan

The next question was:

What services are running on this machine?

To answer that, I used an aggressive Nmap scan:

nmap -A 192.168.170.130

Why -A?

The -A option enables aggressive scanning features, including:

• Service detection
• Version detection
• OS detection
• Default NSE scripts
• Traceroute

For a deliberately vulnerable lab machine like Metasploitable, this can give us a broad overview of the available attack surface.

The results were interesting.

Very interesting. 👀

21/tcp   open  ftp         ProFTPD 1.3.1
22/tcp   open  ssh         OpenSSH 4.7p1 Debian 8ubuntu1
23/tcp   open  telnet      Linux telnetd
25/tcp   open  smtp        Postfix smtpd
53/tcp   open  domain      ISC BIND 9.4.2
80/tcp   open  http        Apache httpd 2.2.8
139/tcp  open  netbios-ssn Samba smbd
445/tcp  open  netbios-ssn Samba smbd
3306/tcp open  mysql       MySQL 5.0.51a
5432/tcp open  postgresql  PostgreSQL DB
8009/tcp open  ajp13       Apache Jserv
8180/tcp open  http        Apache Tomcat/Coyote JSP engine

That’s a lot of exposed services.

And every open port represents a potential attack surface.

Understanding the Attack Surface

From the Nmap results, we can immediately see several interesting services.

For example:

21   → FTP
22   → SSH
23   → Telnet
80   → HTTP
139  → SMB
445  → SMB
3306 → MySQL
5432 → PostgreSQL
8180 → Tomcat

One service immediately caught my attention:

3306 → MySQL

Why?

Because MySQL is a database service.

If we could somehow obtain valid credentials, we might be able to connect directly to the database.

But at this stage, we didn’t have any credentials.

So instead of randomly guessing passwords, I continued with enumeration.

And that’s an important habit:

Don’t guess when you can enumerate.

Step 3 — Web Enumeration With Nikto

Since port 80 was open, I decided to investigate the web server.

Instead of immediately opening the website and manually clicking around, I also used Nikto:

nikto -h http://192.168.170.130

Why Nikto?

Nikto is a web server scanner.

It can help identify:

• Interesting files
• Dangerous directories
• Known vulnerable software
• Server misconfigurations
• Information disclosure
• Default files

Nikto is not a replacement for manual testing.

But it can provide useful clues during reconnaissance.

And in this case…

It did.

One of the results caught my attention:

/tikiwiki/tiki-graph_formula.php:
Output from the phpinfo() function was found.

There were two important things here.

First:

/tikiwiki/

This suggested that the server was running TikiWiki.

Second:

tiki-graph_formula.php

This file name might become useful later.

I didn’t know exactly how yet.

But I made a mental note of it.

Step 4 — Exploring TikiWiki

I opened:

http://192.168.170.130/tikiwiki

The website loaded successfully.

📸 Screenshot — TikiWiki login page

The page contained a login section.

At this point, I technically could have started trying common credentials such as:

admin : admin
root  : root
root  : toor

But I decided not to.

Why?

Because guessing credentials is not always the best first step.

I wanted to understand the application first.

And then I noticed something important.

The application revealed its version:

TikiWiki 1.9.5

And that was a much better lead.

Step 5 — Why Software Versions Matter

Version numbers are extremely valuable during penetration testing.

Imagine discovering:

Software: XYZ
Version: 1.2.3

Now you can investigate:

• Known vulnerabilities
• Public exploits
• CVEs
• Metasploit modules
• Exploit-DB entries

This process is called version-based enumeration.

So I started searching for vulnerabilities related to:

TikiWiki 1.9.5

I didn’t immediately find what I was looking for.

So I slightly broadened my search.

Instead of searching for:

TikiWiki 1.9.5

I searched for:

TikiWiki 1.9

And that’s when something interesting appeared.

Step 6 — Discovering the TikiWiki Vulnerability

I found a public vulnerability related to:

TikiWiki tiki-graph_formula Remote PHP Code Execution

This immediately caught my attention.

Why?

Because earlier, Nikto had already revealed:

/tikiwiki/tiki-graph_formula.php

Remember that file?

Now the pieces started connecting.

Nikto Scan
    ↓
tiki-graph_formula.php
    ↓
TikiWiki Application
    ↓
Version 1.9.x
    ↓
Known Remote Code Execution

This is one of the things I enjoy most about penetration testing.

You don’t always find the complete answer immediately.

Sometimes, you find a small clue.

Later, another clue appears.

And suddenly…

Everything starts making sense.

Step 7 — Searching Metasploit

Since this was a known Remote Code Execution vulnerability, I opened Metasploit:

msfconsole

Then I searched for TikiWiki-related modules:

search tikiwiki

The search returned multiple results.

One of them was relevant to the vulnerability I had discovered.

I selected the appropriate module.

After selecting the module, the next thing I always recommend checking is:

options

Why Check options?

Every Metasploit module may require different configuration values.

Common examples include:

RHOSTS
RPORT
LHOST
LPORT

It’s very important not to blindly run:

exploit

before understanding what the module requires.

In this case, the important configuration was the target address.

I configured:

RHOSTS → 192.168.170.130

Then I attempted to run the exploit.

However…

It didn’t work.

And that’s completely normal during penetration testing.

When an Exploit Doesn’t Work

A failed exploit doesn’t always mean:

The vulnerability doesn’t exist.

There are several possible reasons:

• Wrong target configuration
• Incorrect payload
• Network issues
• Architecture differences
• Firewall restrictions
• Unstable exploit code

So instead of immediately giving up, I investigated the available payloads.

I used:

show payloads

Metasploit displayed several payload options.

I selected another compatible payload and checked its configuration again using:

options

This is a habit I always recommend.

Even if two payloads look similar:

Always verify the configuration.

After configuring the payload correctly, I ran:

exploit

This time…

Get Yussif Selim’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

It worked. 🎯

Step 8 — An Unexpected Discovery

After successfully exploiting the vulnerability, something extremely interesting appeared in the output.

The application configuration revealed:

db_tiki   : mysql
dbversion : 1.9
host_tiki : localhost
user_tiki : root
pass_tiki : root
dbs_tiki  : tikiwiki195

Stop for a second.

Let’s look at what we just found.

Database Type → MySQL
Username      → root
Password      → root
Database       → tikiwiki195

And remember what Nmap discovered at the beginning?

3306/tcp open mysql

Now another attack path appeared.

Nmap
 ↓
MySQL Port 3306
 ↓
Web Enumeration
 ↓
TikiWiki
 ↓
Remote Code Execution
 ↓
Configuration Disclosure
 ↓
MySQL Credentials

And now we had something very valuable:

Valid database credentials.

Step 9 — Connecting to MySQL

Since MySQL was exposed on port 3306, I attempted to connect using:

mysql --host=192.168.170.130 -u root -p

The command asks for the password.

I entered:

root

However, I encountered the following error:

ERROR 2026 (HY000):
TLS/SSL error: wrong version number

This happens because the target is running an old version of MySQL.

Modern MySQL clients may attempt to negotiate SSL/TLS in a way that older services don’t support correctly.

So I disabled SSL for this connection:

mysql --host=192.168.170.130 -u root -p --skip-ssl

After entering the password:

root

I successfully connected.🎯

Now we were inside the database server.

Step 10 — Enumerating Databases

Once connected to MySQL, I could start using normal SQL commands.

The first thing I wanted to know was:

What databases exist?

So I used:

SHOW DATABASES;

The server returned several databases.

The one I was most interested in was:

tikiwiki195

Why?

Because the application configuration had already told us:

dbs_tiki : tikiwiki195

So I selected it:

USE tikiwiki195;

Now I wanted to see the tables inside it:

SHOW TABLES;

Step 11 — Finding the Users Table

Whenever you’re investigating an application’s database, certain table names immediately become interesting.

For example:

users
accounts
admins
members
credentials

Among the available tables, I found:

users_users

That was exactly the kind of table I was looking for.

So I queried its contents:

SELECT * FROM users_users;

And there it was.

The information I needed.

Among the users was:

Username: admin
Password: admin

Interestingly, this was one of the credentials I considered trying at the very beginning.

But I deliberately didn’t guess it.

Instead, I followed the attack path step by step.

And eventually, I discovered the credentials directly from the database.

Step 12 — Logging in as Administrator

I returned to the TikiWiki login page.

This time, I used:

Username: admin
Password: admin

And the login was successful.

🎯 Administrator access obtained.

After logging in, the application prompted me to change the password.

I changed it successfully.

And this is where the impact of the vulnerability becomes much more interesting.

Understanding the Impact

At this point, the attacker doesn’t just have access to a database.

They may have access to sensitive application data.

Depending on permissions, an attacker could potentially:

• Read user information
• Modify records
• Delete data
• Add new users
• Change application credentials
• Modify administrator accounts

And in this case, the database information allowed me to gain access to the application’s administrator account.

The attack chain was complete.

Complete Attack Chain

Let’s put everything together.

ARP Scan
    ↓
Target IP Discovery
    ↓
Nmap Aggressive Scan
    ↓
Multiple Open Services
    ↓
HTTP Enumeration
    ↓
Nikto
    ↓
TikiWiki Discovery
    ↓
Version Identification
    ↓
Public RCE Vulnerability
    ↓
Metasploit
    ↓
Successful Exploitation
    ↓
Database Credentials Discovered
    ↓
MySQL Port 3306
    ↓
Database Access
    ↓
Database Enumeration
    ↓
users_users Table
    ↓
Admin Credentials
    ↓
Administrator Login

What Did I Learn From This Machine?

1 — Enumeration Is Everything

The attack didn’t start with exploitation.

It started with:

arp-scan -l

Then:

nmap -A

Then:

nikto

Each step gave me new information.

And each piece of information influenced the next decision.

2 — Open Ports Can Become Important Later

At the beginning, I noticed:

3306 → MySQL

But I didn’t have credentials.

Later, after exploiting TikiWiki, I discovered:

root : root

Suddenly, that open MySQL port became extremely valuable.

This teaches an important lesson:

Don’t forget information you discover early. It may become useful later.

3 — Software Versions Matter

The TikiWiki version:

1.9.5

became a key part of the attack.

Always pay attention to:

• Application versions
• Service versions
• Plugin versions
• Framework versions

Then research them.

A version number can sometimes lead directly to a known vulnerability.

4 — Automated Scanners Can Give You Clues

Nikto didn’t solve the machine for me.

But it revealed:

tiki-graph_formula.php

Later, that exact file name connected directly to the Remote Code Execution vulnerability.

Tools don’t always give you the answer.

Sometimes they simply give you:

A clue worth investigating.

5 — Don’t Give Up After a Failed Exploit

My first attempt didn’t work.

Instead of stopping, I checked:

show payloads

Then selected another payload and verified the options.

This is important.

Exploitation is not always:

Select module
↓
Exploit
↓
Success

Sometimes you need to troubleshoot.

6 — Always Check Exploit Output Carefully

The exploit didn’t just provide access.

It also exposed configuration information:

Database type
Database username
Database password
Database name

Always read the output carefully.

You may discover:

• Credentials
• File paths
• Internal IP addresses
• Database names
• Application configurations

Sometimes the most valuable information isn’t the shell itself.

It’s what the application reveals after exploitation.

7 — Never Store Weak or Default Credentials

The credentials:

root : root

and:

admin : admin

are extremely weak.

Default credentials are one of the easiest ways to compromise an application.

Even worse, when those credentials are stored inside configuration files, another vulnerability can expose them.

Tools Used

arp-scan

Used for:

Discovering devices on the local network

arp-scan -l

Nmap

Used for:

Port scanning and service enumeration

nmap -A 192.168.170.130

Nikto

Used for:

Web server enumeration and identifying interesting files

nikto -h http://192.168.170.130

Metasploit

Used for:

Testing the known TikiWiki Remote Code Execution vulnerability

msfconsole

MySQL Client

Used for:

Connecting to and enumerating the MySQL database

mysql --host=192.168.170.130 -u root -p --skip-ssl

Final Thoughts

Metasploitable is intentionally designed to contain multiple vulnerable services.

And that’s what makes it such a useful learning environment.

There were many possible attack paths available.

But in this walkthrough, I focused on one specific chain:

Web Enumeration
      ↓
TikiWiki
      ↓
Version Research
      ↓
Remote Code Execution
      ↓
Credential Disclosure
      ↓
MySQL Access
      ↓
Database Enumeration
      ↓
Administrator Credentials
      ↓
Admin Control

The biggest lesson I took from this machine is simple:

Penetration testing is about connecting information.

An open port might not matter yet.

A filename might look insignificant.

A software version might just be a number.

But when you connect those pieces together…

You can build an entire attack path.

And that’s exactly what happened here.

This is only one of the many vulnerabilities available on Metasploitable.

There are still plenty of services left to investigate.

So this definitely won’t be my last time exploring this machine. 👀

See you in the next walkthrough.