MSF RCP: Installation, Configuration, and Console Operation

Installation, configuration, and console operation tests whether you can stand up a working console, connect the database, isolate engagement data, and automate repetitive commands. Expect questions on msfdb, workspaces, datastore scope, logging, and resource scripts.

Core rules

• Rapid7 provides an omnibus installer; Kali and other distributions package Metasploit. Docker images also exist. After install, initialize PostgreSQL with msfdb init, then confirm with db_status inside msfconsole.
• workspace -a name creates an engagement workspace; workspace name switches. Workspaces isolate database records such as hosts, services, vulns, creds, and loot. They do not change module options.
• set changes a value for the current module; setg sets a global value for future modules; unsetg clears it. save persists the active datastore.
• db_nmap runs Nmap and writes results directly to the database. db_import ingests XML, Nexpose, OpenVAS, and other supported formats.
• spool /path/file.log copies console output; makerc /path/file.rc saves commands; msfconsole -r file.rc runs a resource script at startup.

Worked example

For a new client, run workspace -a ClientA, db_nmap -sV -p 22,80,445 10.10.10.5, hosts, and services. Set setg RHOSTS 10.10.10.5, then use auxiliary/scanner/smb/smb_version and run. Start spool /tmp/clientA.log before scanning and makerc /tmp/clientA.rc after. Reasoning: the workspace keeps evidence separate; db_nmap avoids retyping results; setg avoids repeating the target; spooling and makerc preserve evidence and reproducibility.

Traps

• Running hosts or services without checking db_status.
• Assuming workspace changes RHOSTS; it does not.
• Using set when the value must persist across modules.
• Forgetting that resource scripts run in the current console and can overwrite datastore values.
• Confusing spool (console transcript) with the database or with module logging.