FRAMEWORK
// interactive metasploit msfconsole trainer — learn the workflow, not just the syntax
This trainer simulates msfconsole. Every command you'd type at a real prompt, you can type here. The simulator reads your input, validates it, and prints back realistic output — including how things go wrong when you forget a flag or mistype a target. Each command is explained: what it does, why it exists, and where it fits in a real engagement.
Metasploit is for security research, CTFs, lab work, and engagements you have written permission for. Pointing it at machines you don't own or have authorization to test is illegal in most jurisdictions. The targets in this trainer are fictional. Practice on Hack The Box, TryHackMe, your own VMs, or your employer's authorized scope.
Read each module's brief and command anatomy. Watch the demo run — you can replay it. Then attempt each challenge by typing into the live terminal. The terminal accepts help and clear as builtins. Use ↑/↓ to recall previous commands. If stuck, the hints reveal progressively more of the answer. Your progress saves automatically.
01Welcome to msfconsole
// what metasploit is, how to launch it, how to find your way around
Metasploit Framework is the world's most-used exploitation toolkit. Think of it as a giant library of pre-built attacks — exploits, scanners, payloads, post-exploitation modules — wrapped in a command-line shell called msfconsole. Instead of writing custom code for every CVE, you load a module, set a few options, and fire.
Metasploit ships in Kali by default. The console is interactive — when you launch it, you get a prompt that looks like msf6 >, and from there you navigate by typing commands.
msfconsole is like a kitchen. The pantry has thousands of ingredients (modules). The countertop is your active workspace. You go grab one ingredient (use a module), prep it (set options), and serve it (run or exploit). When you're done, you put it back (back) and grab the next.
Command anatomy — the navigation basics
| Command | What it does |
|---|---|
msfconsole | Launches the framework console (run from your bash shell) |
help or ? | Lists every console command, grouped by category |
help <cmd> | Detailed help on one command. help search shows search filters. |
version | Prints framework + console version. Useful when reporting bugs or checking module compatibility. |
banner | Reprints the ASCII-art startup banner. Cosmetic, but rotates through several designs — try it twice. |
history | Shows previous commands you've run this session |
exit or quit | Leaves msfconsole and returns to your shell |
Every module you'll ever use lives behind these basic navigation commands. If you can't get help, can't see options, can't get back out — you can't work the framework. Master these first; everything else is just more specific versions.
Demo run
Watch a typical session start: launching the console, checking the version, asking for help.
Challenges
└─$ to msf6 > — that's how you know you're inside the framework.search command accepts. Print its detailed help inside msfconsole.help dumps every command — too much. Pinpoint help for one command is faster.02Searching the arsenal
// finding the right module among thousands
Metasploit ships with 2,300+ exploits, hundreds of payloads, scanners, and post-exploitation modules. The search command is how you find the one you need. It accepts a free-text query, but the real power is in the filters — keyword:value pairs that narrow results dramatically.
Modules have paths like exploit/windows/smb/ms17_010_eternalblue. Read it left-to-right: category / platform / service / name. That structure is what the filters target. type:exploit hits the first segment, platform:windows hits the second, and so on.
Command anatomy — search filters
| Filter | Purpose |
|---|---|
search <term> | Free-text query against name and description. search eternalblue finds anything mentioning EternalBlue. |
type:exploit | Restrict to exploits. Other values: auxiliary, post, payload, encoder, nop, evasion |
platform:windows | Restrict to a target platform. Values: windows, linux, unix, osx, android, php, python, java, multi |
cve:2017-0144 | Match a specific CVE identifier. Year-only also works: cve:2017 |
name:smb | Substring match against the module name only (not description) |
rank:excellent | Filter by exploit reliability. Worst→best: manual, low, average, normal, good, great, excellent |
app:client | Client-side (user must open something) vs app:server (remote, no interaction) |
| combine them | search type:exploit platform:windows smb — filters AND together |
Without filters, search smb returns 80+ results. With type:exploit platform:windows smb, you're down to maybe 25 — all relevant. In a time-boxed engagement, the difference between scrolling output and finding-what-you-need is fluency with these filters.
Demo run
Searching for EternalBlue three different ways — by name, by CVE, by combined filter.
Challenges
search smb would also dump scanners, post-modules, and Linux Samba bugs — none of which are what you want right now.03Anatomy of a module
// the use → info → show options → set workflow that runs everything
Once you've found a module, working with it is always the same four-step dance: use it, info it, show options on it, then set what's required. This loop is the same for an exploit, a scanner, a post-module, anything. Once you internalize it, the framework gets dramatically smaller.
1. use — load the module into your active workspace. The prompt changes to show what's loaded.
2. info — read the module's documentation: what it does, refs, targets, options.
3. show options — list every parameter, what it's currently set to, and which are required.
4. set — assign values to required options, primarily RHOSTS (the target).
Command anatomy — module workflow
| Command | What it does |
|---|---|
use <module-path> | Loads the module. Prompt becomes msf6 exploit(...) > showing what's active. Tab-completion works on paths. |
use <number> | After a search, you can use the result number directly: use 0 picks the first result. |
info | Full description, references (CVE, BID, MSB), authors, supported targets. Read this before firing. |
show options | Three-column table: Name, Current Setting, Required, Description. Required options must be set or the module won't run. |
show targets | Lists target OS/version variants. Some exploits work on Win7 but not Win10 — pick the right one. |
show payloads | Lists payloads compatible with the loaded exploit. Filtered automatically. |
set OPT value | Assign a value to an option. Case-insensitive on the option name. set RHOSTS 10.10.10.5. |
setg OPT value | Set globally — applies to every module loaded this session. Useful for LHOST when your IP doesn't change. |
unset OPT | Clear a value. unset RHOSTS. Use unset all to clear everything. |
back | Unload the current module — prompt returns to msf6 >. Doesn't lose your sets if you re-use the same module. |
Newcomers skip info and jump to exploit — which crashes loudly because they didn't notice the module needs three required options, not one. The four-step loop isn't bureaucracy; it's the difference between knowing what your tool will do versus throwing packets at a target hoping for the best.
Demo run
Loading EternalBlue, reading its info, viewing options, setting the target.
Challenges
yes in the Required column. Anything missing a current setting that's required will block exploit from running.RHOSTS.10.10.10.0/24), or a file (file:targets.txt).04Payloads explained
// the part you actually send — and why picking the right one matters
An exploit is the delivery mechanism. The payload is what runs on the target after the exploit lands. Pick the wrong payload and you either get nothing (a session that dies in 30 seconds), or you get a basic shell when you could have had a Meterpreter — losing 90% of your post-ex capability.
Reverse vs Bind: Reverse = target connects back to you (works through NAT/firewalls). Bind = target opens a port and you connect to it (almost always blocked by firewalls). Default to reverse.
Staged vs Stageless: Staged splits the payload into a tiny initial dropper plus a second-stage download — small footprint, two network connections. Stageless ships the full payload at once — bigger but more reliable through fragile shells.
Shell vs Meterpreter: Shell = a regular OS command prompt. Meterpreter = an in-memory framework with file transfer, screenshot, hash dump, pivoting, lateral commands. Always prefer Meterpreter when available.
Reading payload paths
| Path | Decoded |
|---|---|
windows/x64/meterpreter/reverse_tcp | Windows, 64-bit, Meterpreter, reverse TCP, staged. The default for most modern Windows exploits. |
windows/x64/meterpreter_reverse_tcp | Same idea, but stageless — note underscore instead of slash before reverse_tcp. One transfer, larger payload. |
linux/x64/meterpreter/reverse_tcp | Linux Meterpreter — yes, it exists; not just Windows. |
cmd/unix/reverse_bash | Just a bash one-liner reverse shell. No framework, no fancy commands. Use when target is a constrained appliance. |
generic/shell_reverse_tcp | Generic shell over reverse TCP. Falls back to whatever the target offers (cmd.exe, /bin/sh). |
Key payload options
| Option | What it does |
|---|---|
LHOST | "Listen Host" — your attacker IP. The target will connect to this. Common bug: setting this to 127.0.0.1 by accident — the target can't reach your loopback. |
LPORT | "Listen Port" — what port your handler listens on. Defaults to 4444. Pick a port your firewall allows outbound; 443 often gets through restrictive egress. |
set payload <path> | Switch the payload from the default. Always tab-complete or copy-paste — the paths are long. |
show payloads | Lists every payload compatible with the loaded exploit. Don't pick a Linux payload for a Windows exploit. |
The number-one reason "the exploit ran but I didn't get a session" is a payload misconfig: LHOST set to your hostname instead of your IP, LHOST set to a NAT'd address the target can't reach, or LPORT blocked outbound from the target's network. Spend 30 seconds confirming your payload before firing.
Demo run
Listing compatible payloads, switching to a stageless variant, setting LHOST/LPORT.
Challenges
127.0.0.1 or your hostname, the target can't reach you and the session never opens.05Firing the exploit
// check, exploit, sessions — the actual moment of compromise
Everything so far has been setup. Now you fire. The professional move is always check first, then exploit. The check command runs a non-destructive probe to confirm the target is actually vulnerable — if you skip it, you might be wasting time on a target that's been patched.
check — sends harmless probes. Result: vulnerable / not vulnerable / appears unexploitable / detection unavailable. Not every module supports it.
exploit (or run — same thing) — actually fires. If everything's set up correctly, you get a session. If options are missing, the framework refuses and tells you what's wrong.
Command anatomy
| Command | What it does |
|---|---|
check | Probe target without exploiting. Best practice before exploit. |
exploit / run | Fire the module. run is an alias — they're identical. |
exploit -j | Run as a background job. Handler stays up after session opens — needed for multiple sessions or to keep listening. |
exploit -z | Don't auto-interact with the new session. Pairs with -j for hands-off automation. |
jobs | List running background jobs. |
jobs -k <id> | Kill a job by ID. |
sessions / sessions -l | List active sessions you've opened. Each gets a numeric ID. |
sessions -i <id> | Interact with session N — drops you into Meterpreter or shell. |
sessions -K | Kill all sessions. Capital K. Useful at end-of-engagement. |
Without -j, your exploit ties up the foreground. If you want to launch a second exploit while the first is still serving sessions — a multi-host engagement — you need background jobs. Likewise, the difference between sessions -i 1 and sessions 1 is the difference between "this works" and "syntax error."
Demo run
Running check, then exploit, then dropping into the resulting Meterpreter session.
Challenges
06Meterpreter post-exploitation
// you have a session — now what
Meterpreter is an in-memory framework that runs entirely as a thread inside a hijacked process. It never touches disk. It speaks an encrypted protocol back to your handler. And it ships with dozens of commands for reconnaissance, file transfer, lateral movement, and credential theft.
When a session opens, the first questions are always: Where am I? (sysinfo) — Who am I? (getuid) — What's running here? (ps) — Can I become SYSTEM? (getsystem). Build that muscle memory; it's the core of every post-ex flow.
Command anatomy — Meterpreter essentials
| Command | What it does |
|---|---|
sysinfo | Computer name, OS, build, architecture, domain. First thing you run. |
getuid | Username Meterpreter is running as. NT AUTHORITY\SYSTEM = jackpot. WORKGROUP\IUSR_X = web shell, you have work to do. |
getpid | Process ID Meterpreter is currently injected into. |
ps | List running processes. Used to find a target to migrate into or processes to kill. |
migrate <pid> | Move Meterpreter into another process. Useful if your current host process might die. |
getsystem | Try several local-privilege-escalation techniques to become SYSTEM. |
hashdump | Dump local SAM hashes. Requires SYSTEM privs. Output: username:RID:LM:NTLM::: |
screenshot | Grab a screenshot from the active console session. Saved to your Kali home dir. |
shell | Drop to a regular cmd.exe / /bin/sh. Type exit to come back to Meterpreter. |
upload <src> <dst> | Push a file from Kali to the target. |
download <path> | Pull a file from target to Kali. |
background | Push the current Meterpreter to the background — back to msf6 >. Session stays alive. |
An unmigrated Meterpreter dies the second the user kills the exploited process. Forgetting getsystem means everything you do is constrained to the user you popped — including hashdump, which silently fails without SYSTEM. The order isn't arbitrary; it's the difference between a stable foothold and a session that vanishes mid-investigation.
Demo run
Inside a fresh Meterpreter — sysinfo, getuid, ps, hashdump.
Challenges
NT AUTHORITY\NETWORK SERVICE, you have escalation work ahead.07Database & workspaces
// remember everything you've found, separately per engagement
Metasploit can hook into a PostgreSQL database that automatically tracks every host, service, vuln, and credential it touches. Across a multi-day engagement, this is the difference between scrolling through scrollback and a queryable record of everything found. Workspaces let you segment data per engagement so customer A doesn't bleed into customer B.
Run db_nmap -sV 10.10.10.0/24 instead of plain nmap. Same scan — but every host found, every port, every service banner gets stored. Two days later you can services -p 445 -R to list every host with SMB open and pre-fill RHOSTS for the next exploit. The DB turns recon into automation.
Command anatomy — db & workspace
| Command | What it does |
|---|---|
db_status | Confirm the DB is connected. Connected to msf. Connection type: postgresql. = good. |
workspace | List workspaces. The active one has a * next to it. |
workspace -a <name> | Add a new workspace. Switches to it automatically. |
workspace <name> | Switch to an existing workspace. |
workspace -d <name> | Delete a workspace and all its data. |
db_nmap [opts] <target> | Run nmap and ingest results. Same flags as real nmap (-sV -p- -A). |
hosts | List every host stored in current workspace. |
services / services -p 80 | List services. -p filters by port. |
services -p 445 -R | The -R flag pipes the host list straight into RHOSTS for whatever module you have loaded. |
vulns | List known vulnerabilities discovered (auto-populated by some scanners). |
creds | List captured credentials. Auto-populated by hashdump, login bruteforcers, etc. |
Once you've worked with the DB, going back to plain nmap + scrollback feels like coding without source control. It's not just storage — it's the -R chain that lets you do db_nmap → services -p 445 -R → exploit as one fluid motion across dozens of hosts.
Demo run
Setting up a workspace, running db_nmap, querying services and using -R.
Challenges
db_* and workspace command silently does nothing useful.-sV) so you can tell which ports run what software, not just which ports are open.08Auxiliary scanners
// recon and enumeration without exploitation
Not everything in Metasploit is an exploit. The auxiliary category contains scanners, login bruteforcers, fingerprinters, and information-gathering modules. They use the same four-step loop as exploits — use, show options, set, run — but they don't try to compromise anything. They just collect.
For raw port scanning, plain nmap (or db_nmap) is faster and more flexible. Where auxiliary modules shine is service-specific work: auxiliary/scanner/smb/smb_version grabs SMB dialect + OS; auxiliary/scanner/ssh/ssh_login bruteforces creds with a wordlist; auxiliary/scanner/http/dir_scanner finds web paths. They feed straight into the DB, populate creds and vulns, and chain into exploits.
Useful auxiliary scanners
| Module | What it does |
|---|---|
auxiliary/scanner/portscan/tcp | TCP connect scan. Useful when nmap isn't available, or to stay inside msfconsole. |
auxiliary/scanner/smb/smb_version | SMB dialect, OS name, domain — works against an entire subnet. |
auxiliary/scanner/smb/smb_ms17_010 | Detection-only check for EternalBlue. Pair with the actual exploit module. |
auxiliary/scanner/ssh/ssh_version | SSH server version banner. |
auxiliary/scanner/ssh/ssh_login | Bruteforce SSH with username and password lists. Stores creds it finds. |
auxiliary/scanner/http/http_version | HTTP server fingerprint. |
auxiliary/scanner/http/dir_scanner | Wordlist-driven directory bruteforce against a web server. |
auxiliary/scanner/discovery/udp_sweep | UDP probe — finds DNS, SNMP, NetBIOS. |
Real engagements aren't just "find the box and pop it." They're "enumerate 254 hosts, identify which services run, find the weak ones, and pivot from there." Auxiliary modules + the database = an enumeration pipeline you can run unattended overnight, then come back to a populated services and creds table.
Demo run
Loading the SMB version scanner, pointing it at a subnet, running it.
Challenges
use command as for exploits — auxiliary modules use the identical workflow.RHOSTS option you've used before — but now it accepts a CIDR range, not just a single IP.run or exploit — by convention you'd use the former for non-exploit modules.Once these eight modules feel automatic, install Metasploit on a Kali VM, build a small lab — vulnhub.com has free VMs designed for exactly this — and rerun every workflow against real targets. Then look at resource scripts (.rc files) for automating multi-step engagements, and msfvenom for generating standalone payloads outside the console.