Managing Scan Results in Metasploit

In this post, let's go through managing scan results using Metasploit's database. Covering everything from setup, workspaces, importing data, querying it, and driving exploitation straight from your recon. Metasploit's built-in database layer is one of the most underused tools in a red teamer's kit, and by the end of this you'll have a clean workflow you can bring to every engagement.

Setting Up the Database

Before anything else, we need to make sure Metasploit's database is actually running. Metasploit uses PostgreSQL.

sudo systemctl start postgresql → starts the PostgreSQL service.

sudo systemctl status postgresql → checks the PostgreSQL service status.

sudo msfdb init -> prepares the database that will be used by metasploit.

Once that's done, fire up msfconsole and verify the connection:

If you see "Connected to msf. Connection type: postgresql", you're good to go. If not, msfdb reinit usually fixes it, it drops and recreates the database from scratch.

Workspaces

By default, Metasploit dumps everything into a single workspace called default. That's fine for a quick test, but once you're running multiple targets you'll want to keep things separated.

workspace -a target_name -> used for creating a workspace.

workspace target_name -> used for changing workspace.

workspace -> used for listing workspaces.

The * shows your active workspace. Anything you scan or import from this point goes into it. Hosts, services, credentials, everything. Switching between target is just a workspace command away, no more digging through folders.

To delete one when you're done:

workspace -d client_name.

Scanning Directly From Metasploit

This is the core of the workflow. Instead of running Nmap separately and importing the results, db_nmap runs Nmap directly from within Metasploit and automatically stores everything into your active workspace.

db_nmap [Flags] [IP] → runs nmap directly from metasploit.

It takes the same flags as regular Nmap, so your existing scan habits carry over. The difference is that when it finishes, hosts, open ports, services, and OS fingerprints are all automatically saved to the database, no manual importing needed.

You can verify what got stored:

Hosts → lists scanned hosts.

Services → lists scanned services.

Everything is queryable from here, which is where the real value starts to show.

Importing Scans to Metasploit

Sometimes you're not starting your scans from inside Metasploit, maybe you ran Nmap from the terminal. db_import handles that.

For an Nmap XML output:

db_import /path/to/scan.xml → imports .xml scan files into metasploit database.

Make sure you ran Nmap with -oX to get XML output, that's the format Metasploit expects:

nmap [Flags] [IP] -oX nmap_scan.xml → stores scan into .xml file.

Querying Your Data

Once your scan data is in, you can start slicing through it instead of grepping XML files. The three main commands are hosts, services, and vulns.

Filtering hosts by OS:

hosts -S Windows → queries hosts based on OS.

Finding all hosts with a specific port open:

services -p 445 -S open → queries hosts based on specific open ports.

Checking stored vulnerabilities from an auxiliary scan:

vulns → checks for stored vulnerabilities from an auxiliary scan.

This is where having everything in one place pays off, instead of hunting through files you're just querying a database and getting clean, filtered output.

Driving Exploitation, Automating the Pipeline & a Few Notes

Driving Exploitation From Your Recon

This is where the workflow really clicks. Instead of manually copying IPs into modules, you can feed your scan data directly into them using -R.

services -p 445 -S open -R → assigns queried host into RHOSTS.

use exploit/windows/smb/ms17_010_eternalblue → metasploit module for eternalblue exploit.

run → runs the selected module (eternalblue).

-R automatically sets RHOSTS to whatever your filtered query returned. No copying, no pasting.

A Few Notes

• The database doesn't capture everything. Notes, context, and your thought process still need to be written somewhere else.
• If your DB connection drops mid-engagement, msfdb reinit will wipe your data, export regularly with db_export.

db_export -f xml /path/to/backup.xml → exports current active workspace into xml file.