MSF RCP cheat sheet

MSF is modular: exploits, payloads, auxiliary, encoders, nops, post modules stored under modules/; each module is a Ruby class inheriting from Msf::Module.

Exploit modules combine a vulnerability trigger with a compatible payload; the exploit target defines offsets and return addresses for specific OS/version combinations.

Payload types: singles (self-contained, e.g., shell_reverse_tcp), stagers (small stage loader, e.g., reverse_tcp), stages (larger feature set, e.g., meterpreter). Naming convention: ///.

The framework core includes Rex (library), Msf::Core (framework instance), and Msf::Session (interaction with compromised targets). Console, msfvenom, and msfdb are front-ends to the same core.

Module metadata includes Name, Description, Author, License, Platform, Arch, PayloadCompat, References (CVE, BID, URL), and DisclosureDate; these drive search and compatibility checks.

Mixins provide shared behavior: Msf::Exploit::Remote::Tcp for socket handling, HttpClient for HTTP, and Handler for setting up listeners for reverse payloads.

Sessions are managed in a central session registry; each session has a type (shell, meterpreter), a tunnel (transport), and an optional route for pivoting.

The database schema (msfdb) stores hosts, services, vulns, credentials, loot, notes, and workspaces; modules query and update it via ActiveRecord.

Install via official installers (Linux/Mac/Windows) or from source with Ruby and bundler; the msfinstall script sets up the apt/yum repository for the metasploit-framework package.

Initialize the database with msfdb init; it creates a PostgreSQL user, database, and msfconsole configuration; use msfdb start/stop/status to manage the service.

Global configuration lives in ~/.msf4/ (config, history, logs, loot, local modules); the MSF_DATABASE_CONFIG or DATABASE_URL environment variable overrides DB settings.

Essential console commands: search, use, info, show options, show payloads, show targets, set/setg, run/exploit, back, sessions, jobs, resource, spool.

setg sets a global variable that persists across modules; unsetg clears it; set without -g applies only to the current module context.

Workspaces isolate engagement data: workspace -a , workspace , workspace -d ; the default workspace is named 'default'.

Resource scripts (.rc) automate console commands; run them with resource or msfconsole -r ; useful for repeatable setup and post-exploitation workflows.

Logging: spool captures console output; set LogLevel and Logging in msfconsole config; framework logs are stored under ~/.msf4/logs/.

msfvenom replaces msfpayload and msfencode; syntax: msfvenom -p LHOST=x LPORT=y -f -o ; use -l payloads to list.

Auxiliary/scanner modules perform discovery: portscan (TCP/UDP), smb_version, ssh_version, http_version, ftp_version, and service-specific banner grabbers.

db_nmap wraps Nmap and imports results directly into the MSF database (hosts, services, notes); use -sV for version detection and -O for OS fingerprinting.

Host discovery modules: arp_sweep (local subnet), ping_sweep (ICMP), and udp_sweep; results populate the hosts table and can be queried with hosts.

Service enumeration: smb_enum_shares, smb_enum_users, http_enum_wayback_urls, and snmp_enum; each module writes findings to the database or loot.

Scanning with RHOSTS supports CIDR, ranges, and file input (file:/path); THREADS controls concurrency; default is often 1, increase cautiously to avoid detection.

The 'services' command lists discovered services with port, protocol, name, and state; 'vulns' lists validated vulnerabilities; 'creds' lists captured credentials.

Auxiliary/gather modules collect OSINT and credentials: search_email_collector, google_enum, and snmp_enum; use within authorized scope only.

Nmap integration: nmap -sS -sV -p- -oX out.xml then db_import out.xml; or use db_nmap to run and import in one step.

Use search with keywords, CVE, platform, or type (e.g., search cve:2021-44228, search type:auxiliary smb) to locate relevant modules; 'info' shows references and reliability.

Validation modules (auxiliary/scanner/*) often include a CHECK method; running check tells whether the target appears vulnerable without exploiting.

Cross-reference module references (CVE, BID, URL) with vendor advisories and public PoCs to confirm applicability before running an exploit.

Version-based validation: compare banner/version output from scanner modules against known vulnerable ranges; false positives occur with backported patches.

Vulnerability records in the database (vulns) are created by modules that call report_vuln; manual entry via 'vulns -a' is possible but should cite evidence.

Risk rating in MSF (Excellent, Great, Good, Normal, Average, Low, Manual) reflects exploit reliability, not business impact; interpret alongside CVSS.

For web apps, use auxiliary/scanner/http modules (e.g., http_version, http_put, dir_scanner) and validate findings with manual requests (curl, Burp) before exploitation.

Avoid running destructive checks (e.g., DoS modules) unless explicitly authorized; prefer non-intrusive validation to maintain service availability.

Workflow: search -> use -> show options -> set RHOSTS/RPORT -> show payloads -> set PAYLOAD -> show targets -> set TARGET -> exploit.

Payload selection depends on architecture, platform, and egress: reverse_tcp for NAT/firewall traversal, bind_tcp when inbound is allowed, and staged vs. stageless based on size constraints.

LHOST must be reachable from the target; use the interface IP or a public address; LHOST can be set to an interface name (e.g., eth0) in recent versions.

Staged payloads (e.g., windows/x64/meterpreter/reverse_tcp) require a stager; stageless variants (windows/x64/meterpreter_reverse_tcp) embed the full payload and avoid stage download.

Encoders (e.g., x86/shikata_ga_nai) modify payload bytes to avoid bad characters; they do not guarantee AV evasion; use only when necessary and test.

The Handler module (exploit/multi/handler) listens for reverse payloads; set PAYLOAD, LHOST, LPORT, and run; use 'jobs' to manage background handlers.

Exploit check: many modules support 'check' to validate the target without exploitation; use it to reduce noise and risk.

ExitOnSession false keeps the handler running after a session is established; set it when expecting multiple connections.

Target selection matters: wrong TARGET can crash the service; review 'show targets' and match OS, service pack, and architecture.

Meterpreter runs in memory and communicates over an encrypted channel; core commands: sysinfo, getuid, getsystem, ps, migrate, shell, background, and exit.

migrate moves the Meterpreter process into another process for stability and stealth; choose a stable process (e.g., explorer.exe, svchost.exe) with matching architecture.

getsystem attempts privilege escalation via named pipe impersonation, token duplication, and other techniques; success depends on target privileges and configuration.

File and data commands: upload, download, cat, edit, search, and hashdump (requires SYSTEM); loot stores collected files in the database.

Pivoting: route add <session_id> to route traffic through a session; then use auxiliary/scanner modules against the internal network.

Post modules (post/windows/gather/, post/linux/gather/) automate credential harvesting, enumeration, and persistence; run with 'run post/'.

Persistence modules (e.g., post/windows/manage/persistence_exe) install auto-start mechanisms; use only with explicit authorization and document changes.

Keylogging (keyscan_start/stop/dump) and screenshot capture require appropriate privileges; output is stored in the session or loot.

Cleanup: remove added users, scheduled tasks, and uploaded files; document all changes for the engagement report.

Client-side exploits target applications (browsers, Office, PDF readers) and require user interaction; modules are under exploit//browser/ and exploit//fileformat/.

Browser exploitation: exploit/multi/browser/* modules (e.g., firefox, chrome) serve malicious content; combine with a resource script to automate the handler.

File format exploits: exploit/windows/fileformat/* generate malicious documents; deliver via email or web; test in a lab before use.

msfvenom generates standalone payloads (exe, dll, elf, apk, war, php, aspx); encode and sign to bypass basic filters; always verify with a test execution.

Social engineering modules: auxiliary/gather/credentials/* (e.g., phishing) and auxiliary/server/* (e.g., capture server) collect credentials; use only in authorized simulations.

Phishing campaigns in Metasploit Pro automate email delivery, tracking, and credential capture; configure SMTP, target list, and landing page.

HTA and macro payloads (e.g., exploit/multi/script/web_delivery) rely on user execution; document consent and scope for social engineering tests.

Obfuscation: use encoders, custom templates, and signed binaries to evade detection; no technique guarantees evasion; validate against the target's security controls.

Metasploit Pro is a commercial web UI; core workflows: project creation, discovery scan, vulnerability scan, exploitation, post-exploitation, and reporting.

Projects isolate data per engagement; each project has its own hosts, services, vulns, credentials, and reports; use project templates for repeatability.

Discovery scans use Nmap; vulnerability scans use Nexpose/InsightVM integration or built-in scanners; import results into the project.

Exploitation in Pro: use 'Modules' or 'Automated Exploitation' (formerly 'Autopwn'); configure allowed modules, payloads, and concurrency.

Credential harvesting and reuse: Pro stores credentials and can attempt reuse across hosts; use 'Credentials' tab to manage and validate.

Reporting: generate reports in PDF, HTML, XML, and other formats; select report type (audit, executive summary, compliance) and customize sections.

Evidence collection: Pro captures screenshots, loot, and session logs; attach to findings for client deliverables.

Cleanup and closeout: use 'Cleanup' to remove artifacts; export project data and archive for records; ensure scope and legal requirements are met.

Obtain written authorization (Rules of Engagement) before any testing; define scope, targets, time windows, allowed techniques, and emergency contacts.

Legal frameworks vary: CFAA (US), Computer Misuse Act (UK), and GDPR (EU) impose criminal and civil penalties for unauthorized access; testing without permission is illegal.

Scope includes IP ranges, domains, applications, and excluded systems; verify targets against scope before running modules; use allowlists in MSF where possible.

Data handling: avoid exfiltration of sensitive data; if found, stop and notify the client; encrypt and store evidence securely; comply with privacy laws.

Reporting must be accurate and non-repudiable: include timestamps, module names, targets, and evidence; avoid exaggeration and unverified claims.

Disclosure: follow coordinated disclosure timelines; do not publish vulnerabilities without client consent; respect NDAs.

Professional ethics: act in the client's best interest, avoid unnecessary risk, and maintain confidentiality; adhere to codes of conduct (e.g., (ISC)², EC-Council).

Incident response: if testing causes unintended impact, stop, notify the client, and document the incident; preserve logs for analysis.