Use a framework module with explicit target and feature constraints

Needs: Correct module/target/options, accepted payload/delivery route and the applicable current exam feature/target restrictions

Manual module inspection

# Manual module inspection
search type:exploit cve:CVE_ID
info MODULE_PATH
use MODULE_PATH
show options
show advanced
show targets
show payloads
set RHOSTS TARGET
set RPORT PORT
set TARGET TARGET_ID
set PAYLOAD PAYLOAD_NAME
set LHOST LHOST
set LPORT LPORT
show missing
run

module rank describes expected exploit stability, not target vulnerability;

check is an active module operation and does not prove exploitability when unsupported or inconclusive;

target IDs, default payloads and options vary by module/version;

automatic target selection is still an assumption to verify;

a module's success message is weaker than a verified session, host and identity;

setg persists values across modules and can silently aim later work at the wrong host; prefer local set unless global state is intentionally tracked.

Current OSCP+ restriction:

msfvenom and exploit/multi/handler may be used against all targets, except that a Meterpreter payload remains subject to the one-target limit;

any Metasploit Auxiliary, Exploit or Post module—or Meterpreter payload—locks the selection to one target, even if check or the attack fails;

Metasploit pivoting is prohibited;

automatic exploitation tools are prohibited.

Use manual/source-reviewed exploitation as the reusable baseline. Decide on the restricted Metasploit target deliberately and record that decision before using a restricted module or Meterpreter.

Verify → Verify destination effect and identity outside the module's status message.

If it fails → The official guide limits module/Meterpreter use to one target, with stated handler/msfvenom exceptions; even a failed check can commit the choice. Recheck the linked guide before choosing the feature. More detail ↓

If → then

A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
Needs: A functioning execution primitive and an observable output or controlled side effect
A payload connects without a session, or a handler/session exits unexpectedly → Pair staged payloads with the correct handler and session lifecycle
Needs: Exact payload/architecture/transport pairing, correct listener binding, reachable staging path and suitable job/session configuration
A pivoted exploit reaches its target but its shell/download cannot return → Build the callback and delivery routes separately from the attack route
Needs: Target-to-listener/download-server path, correct advertised address and compatible reverse listener/forward

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Use a framework module with explicit target and feature constraints

USE WHEN: A reviewed module fits a verified exploit prerequisite set
STARTING ACCESS: A recorded delivery/execution chain with the expected consumer and effect
RESULT: An independently verified module effect and a tracked framework context

Recognize the clue

Read the selected module's information/targets/options and compare them with independently gathered component evidence before any target check/run.

info
show options
show targets
show payloads

SYNTHETIC EXAMPLE OUTPUT

Module target: BUILD_AND_PLATFORM
Required option: authenticated ROLE
Observed target: role/feature not yet verified

Means: The module describes conditions to investigate; its existence is not a vulnerability result.

Confirm: Verify exact target/configuration, access, payload/route and current feature restrictions before selecting it.

After validation: The module conditions and intended effect are independently established: use it within the permitted context.
Ruled out in this context: The required feature/target is absent: reject this module candidate.
Still inconclusive: A banner match without role/configuration evidence is inconclusive; do not use a check to replace prerequisite reasoning.

Troubleshooting: The official guide limits module/Meterpreter use to one target, with stated handler/msfvenom exceptions; even a failed check can commit the choice. Recheck the linked guide before choosing the feature.

Manual module inspection:

Interpretation rules:

module rank describes expected exploit stability, not target vulnerability;
check is an active module operation and does not prove exploitability when unsupported or inconclusive;
target IDs, default payloads and options vary by module/version;
automatic target selection is still an assumption to verify;
a module's success message is weaker than a verified session, host and identity;
setg persists values across modules and can silently aim later work at the wrong host; prefer local set unless global state is intentionally tracked.

Current OSCP+ restriction:

msfvenom and exploit/multi/handler may be used against all targets, except that a Meterpreter payload remains subject to the one-target limit;
any Metasploit Auxiliary, Exploit or Post module—or Meterpreter payload—locks the selection to one target, even if check or the attack fails;
Metasploit pivoting is prohibited;
automatic exploitation tools are prohibited.

Use manual/source-reviewed exploitation as the reusable baseline. Decide on the restricted Metasploit target deliberately and record that decision before using a restricted module or Meterpreter.

Why it works

Module completion or a vulnerability check is not a verified foothold. Module, handler and payload choices have different behavior and policy treatment; keep their roles explicit.

Worked example · hypothetical

Observation: a module reports completion without a session. Test: inspect its expected effect, actual target selection and staged route. Illustrative output: execution occurred but the callback path is missing. Interpretation: retain execution proof and diagnose transport.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗