⚠️ Isolated Lab Environment Only. Metasploitable 2 is intentionally vulnerable. It must run on an isolated host-only network with no internet access or connection to your main network. Connecting Metasploitable 2 to any network accessible by other users or systems is dangerous and potentially illegal. Every lab in this series uses the isolated vboxnet0 configuration only.
DVWA gave you web application skills. Metasploitable 2 is where I take those skills into network exploitation — where you learn to exploit services — the FTP server with a backdoor baked into the binary, the Samba share exploitable with a single Metasploit command, the database with no root password. Twenty-plus intentionally vulnerable services on a single VM, all exploitable from Kali Linux across an isolated lab network. This first lab gets the environment running in 20 minutes. After that, every lab in this series focuses exclusively on exploitation.
🎯 What You’ll Build in Lab 1
Metasploitable 2 running in VirtualBox with isolated host-only network
Both Kali Linux and Metasploitable on the same 192.168.56.x subnet
All 20+ vulnerable services confirmed running
Clean snapshot saved for lab restoration
⏱️ 25 min setup · 3 exercises · Lab 1
✅ Before You Start
DVWA Labs Complete — completing the 30-lab DVWA series built the web application pentesting foundation. Metasploitable extends this to network service exploitation and Metasploit framework usage.
VirtualBox 7.x installed. At least 8GB RAM total. 10GB free disk space. Kali Linux VM already working.
The DVWA lab series covered web application exploitation across 30 labs. Metasploitable shifts the focus to network-layer service exploitation — the techniques covered in the Metasploitable Labs series. The first step is a correct lab environment — everything else depends on it.
Follow the setup steps exactly. The network configuration is the critical step — if Metasploitable reaches the internet, it’s a security risk to you and potentially to others. Verify isolation before starting any exploitation lab.
Step 1: Create the VM
VirtualBox → New → Metasploitable2 → Linux → Other Linux 64-bit
Memory: 512MB
Hard disk: Use existing → select Metasploitable.vmdk
Step 2: Verify VM settings before first boot
Settings → System → Boot Order: Hard Disk first
Settings → Display → Video Memory: 16MB
Settings → Network → (configure in Exercise 2)
Step 3: First boot test
Start Metasploitable2 VM
Wait for boot (30-60 seconds)
Login: msfadmin / msfadmin
Run: ifconfig
Note the eth0 IP address
Step 4: Verify basic services from console
ps aux | grep -E “ftp|ssh|apache|mysql|postgres”
Should show multiple services running
Confirm: VM boots, you can login, services are running.
✅ If the ifconfig output shows 10.0.2.x, Metasploitable is currently on NAT (VirtualBox default) — it has internet access and is reachable from your host in a less isolated way than we want. Don’t exploit anything yet. Complete Exercise 2’s network reconfiguration to host-only before any lab work. The 10.0.2.x address is a warning flag — it means the isolation step wasn’t completed.
📸 Screenshot your Metasploitable2 boot screen with msfadmin login. Share in #metasploitable-labs.
Kali → Metasploitable: ✅ Metasploitable → Internet: ❌ (Isolated ✅)
📸 Correct Metasploitable 2 lab network topology. Kali Linux has two adapters: Adapter 1 (NAT) for internet access for tool downloads, and Adapter 2 (vboxnet0 host-only) for the lab network. Metasploitable 2 has only Adapter 1 on vboxnet0 — no internet access, no external network reach. Kali can attack Metasploitable from 192.168.56.100 to 192.168.56.101. Metasploitable cannot reach anything outside the 192.168.56.0/24 subnet. This is the mandatory safe configuration.
⚡ EXERCISE 2 — KALI TERMINAL (10 MIN)
Configure and Test Network Isolation
⏱️ 10 minutes · Both VMs running
After the network reconfiguration, verify that isolation is correct before any exploitation work. The isolation check is a 2-minute test that prevents lab sessions from accidentally attacking external systems.
From METASPLOITABLE console:
ping -c 3 8.8.8.8 # Must FAIL (no internet)
ifconfig # Should show 192.168.56.x
From KALI terminal:
# Show kali’s lab interface
ip addr show | grep 192.168.56
# Ping Metasploitable
ping -c 3 192.168.56.101 # Must SUCCEED
# SSH test
ssh msfadmin@192.168.56.101 # Accept fingerprint, password: msfadmin
# You should get a shell
exit
# HTTP test
curl http://192.168.56.101 # Should return DVWA homepage HTML
✅ The SSH test in this exercise is more than just a connectivity check — it confirms that the Metasploitable SSH service is running and accepting connections with the default credentials. This exact connection (msfadmin / msfadmin over SSH) is the starting point for post-exploitation labs. More importantly, getting your first shell on Metasploitable — even via SSH with default credentials — is your first moment of real access to a target. That feeling transfers directly to real engagement work.
📸 Screenshot both the Metasploitable ping failure (8.8.8.8) and Kali ping success (to Metasploitable). Share in #metasploitable-labs.
Verify Services and Create Snapshot
⚡ EXERCISE 3 — KALI TERMINAL (10 MIN)
Verify All Services and Create Clean Snapshot
⏱️ 10 minutes · Kali Linux + Metasploitable running
Before any exploitation work, document the baseline service inventory and create a clean snapshot. The snapshot is your restore point for every subsequent lab — essential when labs modify system state.
Step 1: Quick Nmap scan from Kali
nmap -sV –top-ports 100 192.168.56.101
Now every lab in this series starts with: Restore to this snapshot → begin exploitation.
✅ The two services with “(BACKDOORED!)” labels in the Nmap output — vsftpd 2.3.4 and UnrealIRCd — are the highest-value targets in the lab. Both contain known backdoors where a specific input sequence triggers an instant shell. Lab 2 starts with the vsftpd backdoor exploitation. These aren’t misconfigurations or weak credentials — they’re actual backdoors deliberately compiled into the binaries, exactly the type of supply chain attack that appears in real-world CVEs.
📸 Screenshot your full Nmap service scan output. Share in #metasploitable-labs.
The 20+ Vulnerable Services — What You’re About to Attack
The services overview I always give students before any exploitation: know what’s there before you touch it. The network isolation step is the one I verify twice — a misconfigured adapter puts vulnerable services on a reachable network. My VirtualBox setup for Metasploitable follows specific settings to avoid the most common boot failure. The Metasploitable 2 download step is the only one I recommend doing from a specific source — SourceForge only. Metasploitable 2 is running right now on your vboxnet0 network. Here’s what’s listening on those 23 open ports — and why each one matters for the labs ahead.
vsftpd 2.3.4 (port 21) — The backdoored FTP server. In 2011, someone uploaded a version of vsftpd with a deliberate backdoor: sending a username containing a smiley face :) triggers a root shell on port 6200. It was distributed as the official vsftpd 2.3.4 release on SourceForge for several days before discovery. CVE-2011-2523. This is Lab 3’s first target.
Samba smbd 3.0.20 (ports 139, 445) — The username map script vulnerability. Samba’s “username map script” configuration option, when set, passes the username to a script via the shell. Injecting shell metacharacters into the username field achieves RCE without authentication. CVE-2007-2447. Metasploit module: exploit/multi/samba/usermap_script. Produces a root shell.
UnrealIRCd 3.2.8.1 (port 6667) — Another supply chain backdoor, this time in the IRC daemon. Sending the string AB; followed by a command triggers the backdoor. CVE-2010-2075. Metasploit module: exploit/unix/irc/unreal_ircd_3281_backdoor. Used in Lab 4.
MySQL 5.0.51a (port 3306) — The MySQL root account has no password. Connect directly with mysql -h 192.168.56.101 -u root — no password prompt. From the MySQL shell, SELECT LOAD_FILE('/etc/passwd') reads arbitrary files and SELECT '' INTO OUTFILE '/var/www/html/shell.php' writes a web shell if FILE privilege is available.
VNC (port 5900) — Virtual Network Computing with no authentication configured. Connect with vncviewer 192.168.56.101:5900 from any VNC client — you get the Metasploitable desktop with no credentials. Direct GUI access to the target system.
Port 1524 — The hidden bindshell — The most direct path to a root shell: nc 192.168.56.101 1524. No exploit, no credentials, no escalation. Instant root shell. This port is the emergency “did my exploitation break something?” recovery point during lab sessions — and a good reminder that thorough port scanning always includes high ports.
QUICK ACCESS VERIFICATION — ALL IMMEDIATE-ACCESS SERVICES
# Verify all no-credential-required services in 60 seconds
nc 192.168.56.101 1524 # Instant root shell
mysql -h 192.168.56.101 -u root –connect-timeout=3 -e “SELECT version();”# MySQL root no pass
curl http://192.168.56.101/dvwa/login.php 2>/dev/null | grep -c “form”# DVWA up
curl http://192.168.56.101:8180/ 2>/dev/null | grep -i “tomcat”# Tomcat up
Troubleshooting — Common Setup Issues
The most common lab setup problems I troubleshoot and their fixes. Most issues come down to network configuration — the host-only adapter is the source of 80% of “can’t connect” problems.
TROUBLESHOOTING GUIDE
# Problem: Kali can’t ping Metasploitable
Fix 1: Check Kali has vboxnet0 adapter enabled
ip addr show | grep 192.168.56 # Should return 192.168.56.100/24
Fix 2: Bring up the interface if missing
sudo ip link set eth1 up && sudo dhclient eth1
# Problem: Metasploitable shows 10.0.2.15 address (NAT, not isolated)
Fix: Shut down VM → Settings → Network → Adapter 1 → Host-Only → vboxnet0
Restart VM → ifconfig should now show 192.168.56.x
# Problem: Metasploitable boots to “unable to mount root fs”
Fix: VMDK attached as SATA, should be IDE
Settings → Storage → remove SATA controller → add IDE → attach VMDK as IDE primary master
# Problem: VirtualBox Guest Additions prompt on Metasploitable
Dismiss/ignore — never install Guest Additions on Metasploitable
It’s a lab target, not a development environment
If all troubleshooting steps fail: restore from the Lab 1 snapshot (if taken before the network issue), re-verify the host-only adapter configuration, and confirm vboxnet0 is created in VirtualBox’s Host Network Manager before starting the VMs. The clean snapshot is your most reliable recovery point.
Web Applications on Metasploitable — What’s Running on Port 80
The web application stack on Port 80 is what I map before starting any web exploitation lab. Port 80 on my Metasploitable instance is not just one web application — it’s a full web application testing platform. The Apache server hosts several intentionally vulnerable applications, each targeting different vulnerability classes. These overlap directly with the DVWA labs and extend them with additional frameworks.
DVWA (Damn Vulnerable Web Application) at /dvwa/ — The same DVWA from your previous lab series, here pre-installed on Metasploitable. All 10 vulnerability modules at configurable security levels. Login: admin/password.
Mutillidae at /mutillidae/ — OWASP’s vulnerable web application. More complex than DVWA with 40+ vulnerabilities across OWASP Top 10 categories. Includes HTML5 web storage vulnerabilities, clickjacking, and source code review challenges.
phpMyAdmin at /phpmyadmin/ — MySQL admin interface with root/empty password access. From phpMyAdmin, you can read/write any database, execute SQL queries, and potentially write PHP web shells via SELECT ... INTO OUTFILE if write permissions allow.
TWiki at /twiki/ — A legacy wiki application with known arbitrary command execution via specially crafted wiki markup. One of the first things security researchers found when testing Metasploitable in 2011.
Apache Tomcat at port 8180 — The Tomcat manager at http://192.168.56.101:8180/manager/html accepts default credentials (tomcat/tomcat). From the manager, you can deploy a malicious WAR file containing a JSP shell — a standard Metasploit technique covered in a later lab.
WEB APPLICATION INVENTORY — PORT 80 + 8180
# Browse all web applications
curl -s http://192.168.56.101/ | grep -oE “href=”[^”]+”” | head -20
Metasploitable 2 running in VirtualBox, isolated on vboxnet0, all 20+ services verified, clean snapshot created. The lab environment is ready. Lab 2 starts immediately with the first exploitation — Nmap enumeration to build the full attack surface map before selecting targets.
🧠 Quick Check
After setting up Metasploitable 2, you ping 8.8.8.8 from the Metasploitable console and it succeeds. What does this mean and what do you need to do?
An intentionally vulnerable Linux VM by Rapid7 running Ubuntu 8.04 with 20+ deliberately vulnerable services. Created for Metasploit framework practice. Includes backdoored binaries (vsftpd 2.3.4, UnrealIRCd), default credentials everywhere, unpatched web applications (DVWA, Mutillidae), and exposed databases.
Is Metasploitable 2 safe to run?
Safe only on an isolated host-only network. Never NAT or bridge it. Configure VirtualBox host-only adapter vboxnet0 (192.168.56.0/24) and verify ping 8.8.8.8 fails from the Metasploitable console before any lab work.
What attacks can you practice on Metasploitable 2?
OS: msfadmin/msfadmin. MySQL root: empty password. PostgreSQL: postgres/postgres. Tomcat: tomcat/tomcat. phpMyAdmin: root/(empty). FTP: anonymous access. VNC: no password on some configs.
What is the difference between DVWA and Metasploitable?
DVWA focuses on web application vulnerabilities (SQLi, XSS, CSRF). Metasploitable focuses on service-level exploits (backdoors, default creds, CVE exploitation via Metasploit). DVWA teaches web app pentesting; Metasploitable teaches network penetration testing and Metasploit framework usage.
Do I need a powerful computer for Metasploitable 2?
Metasploitable needs only 256MB RAM and 1 CPU. Your constraint is running Kali alongside it — 8GB+ total RAM handles both comfortably. On 4GB systems, allocate 2GB to Kali and 256MB to Metasploitable.
← Previous
DVWA Complete Pentest Challenge — Lab 30
Next →
Lab 2: Metasploitable Nmap Enumeration
📚 Further Reading
Lab 2 — Metasploitable Nmap Enumeration— The next lab. Full Nmap enumeration of all Metasploitable services with version detection and vulnerability scripts — building the complete attack surface map before exploitation begins.
DVWA Labs Series— The prerequisite lab series. 30 labs covering web application vulnerabilities that are also present in Metasploitable’s built-in DVWA installation.
Metasploitable Labs Hub— The full series overview. All exploitation labs mapped to specific Metasploitable services and CVEs.
Metasploitable 2 Official Download— The only authorised download source for Metasploitable 2. Download from SourceForge directly — avoid third-party mirrors which may contain modified VMs with additional malware.
Rapid7 — Metasploitable 2 Exploitability Guide— Official Rapid7 documentation mapping each Metasploitable service to its exploit, CVE number, and Metasploit module. The authoritative reference for planning your lab exploitation sequence.
ME
Mr Elite
Owner, SecurityElites.com
Metasploitable was the first target where I got a real shell through exploitation rather than default credentials. The vsftpd 2.3.4 backdoor — a single Metasploit command, one minute from start to root shell. That transition from DVWA web vulnerability practice to network exploitation practice is the biggest jump in the learning path. DVWA teaches you to think like a web security researcher. Metasploitable teaches you to think like a network penetration tester. They’re completely different mindsets and skill sets, and this lab series covers both.
