June 22, 2026
From Enumeration to Root: My First Internal Network Penetration Test on Metasploitable 2
Lessons learned while performing an internal penetration test in a controlled lab environment.
Asad Sayyad
4 min read
"Finding an exploit isn't the hard part."
When I first started learning penetration testing, I thought the process was simple:
- Scan the target.
- Find a vulnerability.
- Run an exploit.
- Get a shell.
After completing my first internal penetration test on Metasploitable 2, I realized how wrong that assumption was.
The real challenge wasn't exploitation.
It was understanding what the target was exposing, why it was vulnerable, and how seemingly unrelated pieces of information could be combined into a successful attack path.
Instead of treating this machine like a Capture The Flag challenge, I approached it as if I had been assigned an internal security assessment for a client. That single mindset change made the experience completely different.
The Plan
Rather than opening Metasploit immediately, I followed a simple methodology.
Reconnaissance
β
Service Enumeration
β
Vulnerability Research
β
Controlled Exploitation
β
Post-Exploitation
β
DocumentationReconnaissance
β
Service Enumeration
β
Vulnerability Research
β
Controlled Exploitation
β
Post-Exploitation
β
Documentationπ€ The First Surprise
Running the first Nmap scan was the moment I realized this machine was intentionally designed to teach security concepts.
Instead of finding one or two services, I was greeted by an entire ecosystem:
Instead of asking,
"Which exploit should I run?"
I started asking,
"Why is this service exposed, and what can it tell me?
π― Assessment Snapshot
- Duration: 2 Days
- Target: Metasploitable 2
- Services Enumerated: 10+
- Critical Findings: 6
- High Findings: 2
- Medium Findings: 1
- Low Findings: 1
- Multiple Independent Paths to Root Access
1οΈβ£ "Logging Into a Database Doesn't Mean You've Compromised the System"
When I successfully authenticated to PostgreSQL using default credentials, I thought the machine was already compromised.
After all, I had access to the database.
What else was left?
Then I realized something important.
Database access and operating system access are two completely different security boundaries.
I could browse databases, execute SQL queries, and inspect objects β but I still couldn't interact with the underlying operating system.
Only after researching PostgreSQL User Defined Functions (UDFs) and understanding how they could be abused for code execution did I finally obtain a Meterpreter session.
It was one of those moments where everything clicked.
Instead of blindly running exploits, I started asking:
"What privileges do I actually have, and what can I do with them?"
2οΈβ£ Enumeration Is More Valuable Than Exploitation
At the beginning of the assessment, my instinct was simple:
Find a service β SearchSploit β Metasploit β Exploit.
But after spending hours enumerating every open service, I realized that enumeration was doing most of the work.
Version numbers immediately pointed toward:
- vsFTPd 2.3.4
- Samba 3.0.20
- UnrealIRCd 3.2.8.1
Each one already had publicly documented vulnerabilities.
The exploit wasn't the difficult part.
Finding the right service, the correct version, and validating the vulnerability was where most of the learning happened.
3οΈβ£ Sometimes Configuration Is the Vulnerability
One of my favorite findings wasn't a CVE.
It was WebDAV.
The server happily accepted file uploads.
Even more interesting, uploaded PHP files could be executed directly through the browser.
There wasn't a complicated memory corruption bug.
There wasn't an advanced exploit chain. It was simply an insecure configuration.
That finding completely changed the way I look at web applications. Sometimes attackers don't need to break the application.
They simply use it exactly as it was configured.
4οΈβ£ The "Small" Findings Aren't Small
During enumeration I tested SMTP and ran a simple command:
VRFY rootVRFY rootThe server responded with a valid user.
Nothing crashed.
No shell appeared.
No meterpreter session opened.
At first, it felt insignificant. But then I realized that information disclosure is often the first step in a real attack.
Knowing valid usernames makes password attacks easier. Knowing software versions speeds up vulnerability research. Knowing server configuration simplifies exploitation.
Those "boring" findings are often what enable the exciting ones.
What This Project Really Taught Me
Before starting this assessment, I thought penetration testing was mostly about exploiting vulnerabilities.
Now I think differently.
It's about:
- Being curious enough to ask why something exists.
- Spending time enumerating instead of immediately exploiting.
- Understanding the difference between application access and system access.
- Researching software versions instead of assuming they're vulnerable.
- Documenting every observation, even the ones that don't immediately lead to a shell.
π If I Had to Do It Againβ¦
- Spend more time on enumeration β it reveals more than exploitation.
- Treat every open port as a separate challenge and explore it thoroughly.
- Research software versions, CVEs, and service configurations before looking for exploits.
- Good research makes exploitation straightforward.
- Always look for multiple attack paths instead of stopping after the first successful compromise.
π Final Note
This is not an exhaustive assessment of Metasploitable 2._ I performed this project as part of my eJPT preparation and intentionally kept the scope aligned with the concepts covered in the certification. The goal was to strengthen my understanding of enumeration, vulnerability research, exploitation, and documentation rather than identify every possible vulnerability._
Final Closing
The biggest takeaway from this project wasn't getting a root shell β it was realizing that good penetration testing starts with curiosity, thorough enumeration, and research. Everything else becomes much easier once those foundations are in place.