How Metasploit Fits Into a Pentest Workflow
Metasploit's own module library covers an enormous range of vulnerabilities, and its payload options range from a single harmless command all the way to a fully interactive, persistent shell. That range is exactly why using it inside a client engagement requires more discipline than using it in a lab.
Search, then propose, then approve, then execute
A responsible workflow separates Metasploit usage into distinct steps rather than treating module selection and execution as one action:
- Search. Looking up candidate modules by name, CVE, or affected product is pure local database lookup. It touches no target and carries no risk.
- Propose. Fetching a specific module's real options and compatible payloads, still without contacting the target, so an operator can see exactly what a module would need before deciding anything.
- Approve. A human reviews the exact module, the exact payload, and the exact proof command before anything is authorized to run.
- Execute. Only after approval, and only after re-checking scope and the engagement's time window one more time.
Restrict the payload family, not just the target
Metasploit's payload options include interactive shells, meterpreter sessions, and reverse or bind handlers that open a persistent connection back to the operator. None of those belong in a confirmation-focused engagement. Restricting available payloads to a safe, single-shot "exec" family, run one command, capture its output, done, means even a fully approved action cannot leave a live channel open on the client's system afterward.
id,
whoami, or hostname, rather than a free-text field, keeps the actual
executed command as predictable and reviewable as the payload choice itself.
Session cleanup is not optional
Even a payload chosen from a restricted, safe set can occasionally still open a session on some modules. A workflow that unconditionally attempts to close any session created, whether or not the confirmation step considered it expected, avoids quietly leaving access open on a client's infrastructure after the engagement moves on.
What "it ran" actually tells you
One detail worth knowing if you are evaluating or building this kind of workflow: a module that successfully launches is not automatically the same as a module that successfully compromised something. Metasploit's own execution response for many modules confirms the module ran, not that a session or session-equivalent proof was produced. Treating "it ran without error" and "it worked" as the same fact will overstate what actually happened. A defensible workflow reports both facts separately.
See it in an actual tool
Shieldome Siege enforces scope on every action and gates exploit confirmation behind a human approval, with a tamper-evident audit log of the whole engagement.
Read the documentation