MSF RCP: Vulnerability Analysis and Validation

Vulnerability analysis and validation tests whether you can turn scan data into confirmed, evidence-backed findings. Expect questions on the check method, module references, false positives, version ambiguity, and the difference between a scanner hit and a validated vulnerability.

Core rules

• search cve:YYYY-NNNN locates modules by CVE; info shows references, targets, rank, and whether the module supports check.
• check returns vulnerable, safe, or unknown. Not every module implements it; some return unknown even on a vulnerable host. Treat unknown as unproven.
• Version banners can lie: backported patches, reverse proxies, and custom builds make version-only inference unreliable. Validate with a benign request, configuration review, or a controlled proof.
• Prefer non-destructive validation. Avoid DoS modules, brute-force modules, and payload execution until scope and rules of engagement allow it.
• Record the evidence: command, timestamp, target, response, and module output. Use vulns and notes in the database so the report is traceable.

Worked example

A scan shows SMB on 10.10.10.23. Run search cve:2017-0144; use auxiliary/scanner/smb/smb_ms17_010, set RHOSTS 10.10.10.23, and run check. If it reports vulnerable, you have a validated finding and can plan exploitation. If it reports unknown, do not claim MS17-010; inspect the SMB banner, patch level, and any compensating controls, then document the uncertainty. Reasoning: the auxiliary check tests the specific flaw without delivering a payload, which is safer and more defensible than running the exploit first.

Traps

• Treating a scanner plugin hit as a confirmed vulnerability.
• Assuming check is implemented everywhere or that its output is definitive.
• Inferring a patch level from a banner alone.
• Running a destructive check in production without a window.
• Failing to preserve output that supports the finding.