Payloads with msfvenom

Sometimes the exploit is not a Metasploit module. You have a file-upload form, a writable share, or a command-injection bug, and you just need a payload you can drop and trigger yourself. msfvenom is the standalone generator that builds that payload as a .exe, .elf, a raw PHP snippet, or twenty other formats. It is the same payload engine behind the framework, exposed as a command-line tool.

The anatomy of every command is the same: pick a payload, set LHOST and LPORT, pick a format, write it to a file. Learn that skeleton and every variant is a small change.

-p is the payload, -f is the output format, -o is the file. The format has to match how you'll deliver it. A .php shell needs a server that runs PHP; an .exe needs the victim to execute it; raw shellcode with -f raw is what you paste into a buffer-overflow exploit.

Staged versus stageless

Notice the difference between windows/x64/meterpreter/reverse_tcp and windows/x64/meterpreter_reverse_tcp. The slash before reverse_tcp makes it staged: a tiny first-stage stub connects back and pulls the real payload from your handler over the network. The underscore version is stageless: the whole payload ships in the file at once.

Staged payloads are smaller on disk, which helps when you're squeezing bytes into a tight exploit. Stageless payloads are bigger but more reliable, because there's no second network round-trip that can fail. On a flaky VPN or through a picky proxy, reach for stageless. When file size is the constraint, go staged.

Catch the callback

A payload with nothing listening on the other end is useless. Whatever LHOST and LPORT you baked in, you need a handler bound to the same values before you trigger the file. The generic multi/handler exploit is that catcher.

The single most common msfvenom mistake is a handler that doesn't match the payload. If you generated a staged reverse_tcp but set the handler to a stageless meterpreter_reverse_tcp, the session dies on arrival. The PAYLOAD, LHOST, and LPORT on the handler must be byte-for-byte what you fed msfvenom.

The encoder reality check

You'll read old tutorials that say -e x86/shikata_ga_nai -i 10 makes your payload undetectable. It does not, and it never really did. Modern antivirus and EDR match behavior and known msfvenom stubs, not just static byte patterns, so a shikata-encoded Meterpreter is one of the most-flagged files on the internet. Encoders exist to solve a different, narrower problem.

Their real job is removing bad characters. If your delivery path chokes on a null byte or a 0x0a, -b '\x00\x0a' tells msfvenom to encode around those bytes so the payload survives transit. That is a legitimate, everyday use. Evasion is not.