MSF RCP common mistakes
MSF RCP · Understand the traps and how to avoid them.
Launching msfconsole and immediately running exploit modules against a target without first configuring the workspace, database, and global options, then losing all results when the session ends.
Candidates treat msfconsole as a standalone shell and skip the 'msfdb init' / workspace setup step, so hosts, services, vulns, and loot are not persisted and cannot be referenced later in a Pro-style workflow or report.
What to do instead
Before any module runs, start the database ('msfdb init' or 'msfdb start'), confirm 'db_status' shows connected, create and select a named workspace ('workspace -a '), and verify with 'workspace'. Re-check 'db_status' after any restart.
Confusing a payload with an exploit module and setting the wrong option names (e.g., setting RHOSTS on a payload, or LPORT on an exploit that uses a different option name), producing 'unknown datastore option' errors or sessions that never call back.
The exam tests the exploit/payload/encoder/auxiliary separation in the architecture, but candidates memorize module names rather than the datastore model and the meaning of Required/Advanced options.
What to do instead
For every module, run 'show options', 'show advanced', and 'show payloads' before setting anything. Set RHOSTS/RPORT on the exploit and LHOST/LPORT on the payload, then confirm with 'show options' that no required field is blank.
Using 'set' instead of 'setg' (or the reverse) and then wondering why a value disappears or leaks into unrelated modules during a multi-target run.
Candidates do not internalize datastore scoping: 'set' applies to the current module instance, 'setg' is global across modules and sessions, and 'unset'/'unsetg' clear them. Leftover globals silently override intended values.
What to do instead
Deliberately choose scope: 'setg' only for values reused across many modules (e.g., LHOST), 'set' for target-specific values. Run 'setg' with no arguments to audit globals, and clear stale ones with 'unsetg ' before a new engagement.
Running a scan or auxiliary module and reporting 'no vulnerabilities found' as a conclusion without checking that the target was actually reachable, the port was open, and the module's check actually executed.
Auxiliary modules can return empty output for reasons unrelated to security posture (firewall, wrong RHOSTS, wrong port, service mismatch). Candidates read absence of output as absence of risk.
What to do instead
Validate reachability first ('db_nmap -sV -p ', then 'services'/'hosts' to confirm DB records). After a check, inspect 'vulns' and 'notes' and re-run with 'set VERBOSE true' to distinguish 'not vulnerable' from 'not tested'.
Treating a Metasploit 'check' result or an auxiliary scanner hit as confirmed exploitability and skipping manual validation before attempting exploitation or writing it into a report.
Many check methods are banner- or version-based and produce false positives/negatives; candidates conflate 'Vulnerable' output with proof and then misattribute failed sessions to the payload.
What to do instead
Cross-validate: confirm the service version via 'db_nmap -sV', review the module's check code with 'info' and the References/Reliability fields, and where safe reproduce with a benign proof (e.g., a callback or file read) before claiming exploitation.
Selecting a staged payload (e.g., windows/meterpreter/reverse_tcp) for a constrained channel and then blaming the target when the handler never receives the second stage, instead of switching to a single/stageless payload or fixing the handler.
Candidates memorize one payload name and ignore staging semantics, payload size limits, and the requirement that the multi/handler options (LHOST/LPORT/Payload) exactly match what was generated.
What to do instead
Match payload to channel: use stageless (e.g., windows/meterpreter_reverse_tcp) when the stager can't return, and always configure 'use exploit/multi/handler', set the identical PAYLOAD, LHOST, LPORT, and ExitOnSession false before launching the listener.
Getting a Meterpreter session and immediately running destructive or noisy post modules (e.g., hash dumps, persistence) without migrating, checking privileges, or recording the session ID and target.
Candidates rush to 'getsystem'/'hashdump' to show a win, which can crash the exploited process, trip EDR, or fail silently due to integrity level, and they lose track of which session maps to which host.
What to do instead
Stabilize first: 'sysinfo', 'getuid', 'getprivs', then 'migrate' to a stable process of matching architecture. Record the session ID and target, and only run post modules whose requirements (admin/SYSTEM) you have verified with 'getprivs'.
Building a client-side payload or HTA/office document and testing it only against the attacker's own host or a fully patched machine, then declaring the social-engineering vector ineffective or, conversely, effective for the client.
Client-side success depends on the victim's Office/browser version, macro policy, and user action; candidates skip the environmental variables and don't verify the handler is listening with matching options before delivery.
What to do instead
Before delivery, start the matching multi/handler and confirm it is listening. Test in an environment representative of the target (same app version, macro settings), and document the preconditions (user enables content, version range) as part of the finding.
In Metasploit Pro, launching a discovery or exploitation campaign with default scan speed and no scope exclusions, then exporting a report that lists out-of-scope hosts or unvalidated findings.
Pro's defaults favor speed and breadth; candidates don't set the project's target range, excluded hosts, or credential/validation options, and they generate a report before reviewing collected evidence.
What to do instead
In the project, define the exact target range and exclusions before any task, set scan speed and module sets deliberately, review the hosts/vulnerabilities/loot tabs after the task, and only then generate the report with the appropriate template and validated findings.
Testing exploitation, password attacks, or payload delivery against public or third-party systems 'just to see if it works', or continuing past the written scope because a target responded.
Candidates focus on technical success and treat scope and authorization as paperwork; they also reuse engagement data (credentials, hosts) beyond the authorized window.
What to do instead
Confirm written authorization, defined scope, time window, and rules of engagement before any active module. Keep a scope list, exclude out-of-scope hosts explicitly, stop and report immediately if a system outside scope responds, and delete engagement data when the authorized period ends.