A reverse shell is a remote command shell in which the compromised machine initiates an outbound connection to the attacker’s listener, giving the attacker interactive control while bypassing inbound firewall rules.
How a reverse shell works
In a normal remote session, the client connects to a server that listens for incoming connections. A reverse shell flips this around:
- The attacker starts a listener on their own machine, for example with netcat or Metasploit.
- They exploit a vulnerability such as remote code execution or upload a web shell, and run a short command on the target.
- The target connects back to the listener and attaches a shell (bash, cmd.exe or PowerShell) to that connection.
Typical one-liners use bash’s /dev/tcp feature, Python, PowerShell or netcat. The opposite approach, a bind shell, opens a listening port on the victim instead. MITRE ATT&CK maps reverse shell activity to Command and Scripting Interpreter (T1059) and application layer protocols for command and control.
Why reverse shells matter
Most firewalls and NAT devices block unsolicited inbound connections but allow outbound traffic, so a reverse shell is often the simplest way to turn a one-off code execution bug into full interactive access. That is why exploit write-ups and attacks on web applications, VPN appliances and IoT devices so often end with a reverse shell. In penetration testing, a working reverse shell is a standard proof of successful compromise. Attackers may tunnel it over HTTPS or DNS to blend in with normal traffic.
How to defend against reverse shells
- Restrict egress traffic: servers should only connect to the destinations they actually need.
- Alert when web servers or services spawn shells or scripting interpreters.
- Use EDR and network monitoring to spot long-lived connections to unknown hosts.
- Patch internet-facing applications quickly to remove the initial code execution.
