What Is a Reverse Shell Attack?

A web server is sitting behind a firewall that blocks every inbound connection except port 443. The attacker has found a command injection flaw in the app but cannot connect back to the box, because the firewall drops anything they send toward it. So they flip the direction. They make the server run a single command that opens an outbound connection from the server to the attacker's machine and hands over a command prompt. The firewall waves it through, because the firewall was built to stop connections coming in, not going out. Now the attacker is typing commands on a server they were never able to reach directly.

That reversal is the whole idea. A reverse shell is a command shell where the victim initiates the connection to the attacker, instead of the attacker connecting to the victim. It turns the firewall's own rule, trust outbound, distrust inbound, into the way in.

This guide covers what a reverse shell is, how it works step by step, how it differs from a bind shell, the tools and one-liners attackers use, why defenders find it so hard to stop, and how to detect and prevent it. It is written for blue teamers who have to catch the connection that looks like ordinary outbound traffic.

What is a reverse shell?

A reverse shell is a type of shell session in which the target machine connects back to the attacker and gives them interactive command execution on that target. The attacker runs a listener on a machine they control, the victim runs code that connects out to that listener, and once the connection is established the attacker types commands that execute on the victim and sees the output. It is a remote shell, with the connection direction reversed from what you would expect.

The reason the direction matters comes down to the firewall. Network defenses are usually strict about inbound traffic and permissive about outbound traffic, because users and servers legitimately need to reach the internet. A reverse shell exploits that asymmetry: by having the victim dial out, the malicious connection looks like the host reaching the internet, which is exactly the traffic the firewall is configured to allow. MITRE ATT&CK catalogs this kind of attacker communication under the Command and Control tactic (TA0011), the techniques adversaries use to talk to systems they control inside a victim network.

A reverse shell is not an exploit in itself. It is the payload, the thing an attacker runs after they already have some way to execute a command, whether through a software vulnerability, a malicious document, or stolen access. The exploit gets code running once; the reverse shell turns that one-shot execution into a persistent, interactive session.

How a reverse shell attack works

A reverse shell has two halves: a listener on the attacker's side and a connect-back payload on the victim's side. The sequence is short.

1. The attacker starts a listener. On a machine they control, with a public IP or a forwarded port, the attacker opens a listener on a chosen port and waits for an incoming connection. A common choice is a port that blends in, such as 443, so the outbound connection looks like normal HTTPS.
2. The attacker gets code to run on the victim. Through a vulnerability, a phishing payload, a malicious macro, or an exploited service, the attacker achieves one round of command execution on the target.
3. The payload connects out. That command tells the victim to open a network connection back to the attacker's listener and attach a shell process (such as /bin/bash or cmd.exe) to the socket, so input and output flow over the connection.
4. The firewall allows it. Because the connection originates from inside and goes outbound, the perimeter firewall treats it as a normal host reaching the internet and lets it through.
5. The attacker has an interactive shell. The attacker now types commands that run on the victim with the privileges of the process that launched the shell, and reads the results in real time, as if sitting at a terminal on the box.

From there the attacker does what any shell allows: reconnaissance of the host and network, downloading more tools, escalating privileges, and moving toward their objective. The reverse shell is the foothold that makes all of that interactive instead of one command at a time.

Reverse shell vs. bind shell

The counterpart to a reverse shell is a bind shell, and the difference is purely about who connects to whom. Understanding both clarifies why attackers reach for the reverse variant.

A bind shell opens a listening port on the victim and waits for the attacker to connect to it. That works only when the attacker can actually reach that port, which firewalls, network address translation, and inbound filtering usually prevent. The reverse shell sidesteps all of it by making the victim the one to initiate the connection. That is why reverse shells are by far the more common of the two in real intrusions: most targets sit behind a firewall or NAT, and outbound is the path of least resistance.

Common reverse shell tools and techniques

Reverse shells are usually small. A single line of a scripting language already present on the host is often all it takes, which is part of what makes them hard to stop. Defenders should recognize the usual building blocks.

• Netcat. The classic. A short nc command can connect out and pipe a shell over the socket. Because plain netcat is well known, attackers also use variants and other tools to avoid the obvious pattern.
• Bash and other shells. On Linux, a one-liner using bash's /dev/tcp pseudo-device opens a connection and redirects a shell over it, with no extra tooling installed at all.
• Scripting languages. Python, Perl, PHP, and Ruby each have compact reverse-shell one-liners. They abuse interpreters that are already on the system for legitimate reasons, so nothing new has to be dropped to disk.
• PowerShell. On Windows, a PowerShell command can open a TCP connection and run an interactive shell over it. Because it lives in memory and uses a signed, built-in binary, it overlaps heavily with fileless malware techniques.
• Offensive frameworks. Tools like Metasploit and post-exploitation agents generate reverse-shell and reverse-connection payloads with features like encryption and session handling built in, including the well-known Meterpreter payload.

Two patterns tie these together. First, living off the land: most reverse shells use interpreters and tools that are already on the host (bash, PowerShell, Python), so there is no malicious file to flag. Second, encryption and port choice for blending in: attackers route the connection over port 443 and often wrap it in TLS, so on the wire it resembles ordinary HTTPS and survives casual inspection.

Why reverse shells are hard to detect

The core problem is that a reverse shell is, at the network level, just an outbound connection, and hosts make outbound connections constantly. There is no inbound attack to block and frequently no new file to scan. The malicious traffic is hiding inside the single largest category of normal traffic on the network.

Several factors compound it. Attackers pick common ports like 443 and 80 so the connection looks like web browsing. They encrypt the channel so its contents cannot be read by simple inspection. They use built-in interpreters, so signature antivirus sees a legitimate, signed binary doing legitimate-looking work. And because the connection is outbound, a perimeter firewall configured only to filter inbound traffic never even examines it. Detecting a reverse shell means recognizing that an allowed connection is behaving abnormally, which is a question of behavior and context, not signatures.

How to detect a reverse shell

Because the traffic is allowed and often encrypted, detection leans on behavior and correlation rather than blocking known-bad indicators.

• Process and network correlation on the endpoint. The strongest signal is a suspicious parent-child process relationship tied to an outbound connection: a web server process spawning /bin/bash, or Microsoft Word launching powershell.exe that then opens a network socket. Endpoint detection and response tooling records exactly this and is the most reliable place to catch a reverse shell.
• Outbound and egress anomalies. Watch for connections to unfamiliar external IPs, traffic on odd ports, long-lived sessions with steady low-volume two-way traffic (the back-and-forth of an interactive shell), and beaconing patterns. A server that should only ever receive connections suddenly initiating one is a strong tell.
• Command-line and script auditing. Log and inspect command lines and script blocks for the telltale strings of reverse-shell one-liners: /dev/tcp, nc -e, interpreter invocations that open sockets, and encoded PowerShell that resolves to network calls.
• Centralized analysis. Pull endpoint, command-line, and network telemetry into one place so a single odd outbound connection can be tied to the process that made it. The correlation across data sources is what turns an allowed connection into a confirmed detection.

The unifying skill is knowing what normal outbound behavior looks like for each host. An interactive shell talking to an external IP from a machine that has no business doing so is obvious once you have the baseline, and invisible without it.

How to prevent reverse shell attacks

You cannot always stop the initial code execution, but you can make the connect-back fail and make it loud when it tries. The controls that matter most:

• Egress filtering. This is the direct counter. Default-deny outbound traffic and allow only what hosts actually need, by destination and port, so a server cannot open an arbitrary connection to an attacker's listener. Egress control turns the firewall's permissive side strict, which is the gap reverse shells exploit.
• Patch and harden to prevent the initial execution. A reverse shell needs a way to run that first command. Fixing the vulnerabilities, injection flaws, and exposed services that grant code execution removes the precondition.
• Least privilege and segmentation. Run services with the minimum rights they need so a shell inherits little, and segment the network so a foothold on one host cannot reach the rest. This limits what a reverse shell can do even if it connects.
• Restrict and monitor interpreters. Constrain or log the scripting tools reverse shells rely on, such as PowerShell with logging and constrained language mode, and application control that limits what can spawn a shell.
• Deploy endpoint and network detection. Pair egress filtering with monitoring that catches the suspicious process-and-connection behavior, so an attempt that gets through filtering still raises an alert.

The theme is defense in depth: block the outbound path with egress filtering, remove the execution that starts it, and watch the endpoint for the behavior that gives it away. No single control is enough, but together they turn an easy connect-back into a blocked, noisy failure.

Frequently Asked Questions

What is a reverse shell in simple terms?

A reverse shell is a remote command session where the victim machine connects out to the attacker, rather than the attacker connecting in to the victim. The attacker runs a listener and waits; the victim runs a payload that dials out and attaches a shell to the connection. Once connected, the attacker types commands that run on the victim. The reversed direction lets the connection slip past firewalls that block inbound traffic but allow outbound.

What is the difference between a reverse shell and a bind shell?

In a bind shell, the victim opens a listening port and the attacker connects to it, which requires the attacker to be able to reach that port. In a reverse shell, the attacker listens and the victim connects out to them. Reverse shells are far more common because most targets sit behind a firewall or NAT that blocks inbound connections but allows outbound ones, so the connect-back succeeds where a bind shell would be blocked.

Why do attackers use reverse shells?

Because they bypass the firewall. Network defenses typically block inbound connections but allow hosts to make outbound connections to the internet. By making the victim initiate the connection, a reverse shell looks like ordinary outbound traffic and is allowed through. It also works when the victim is behind NAT and not directly reachable, which is the common case, making the reverse shell the default choice for interactive access after exploitation.

Are reverse shells always malicious?

The technique itself is neutral. The same connect-back mechanism is used legitimately by system administrators and during authorized penetration tests and red team engagements to gain access to machines behind firewalls. What makes a reverse shell an attack is the lack of authorization. On a production network, an unexpected reverse shell is almost always a sign of compromise.

How do you detect a reverse shell?

Detection focuses on behavior, not signatures, because the traffic is allowed and often encrypted. The strongest signal is an endpoint detection tool spotting a suspicious process opening an outbound connection, such as a web server or Office application spawning a shell that then talks to an external IP. Network monitoring for connections to unfamiliar destinations, odd ports, and long-lived low-volume interactive sessions also helps, as does auditing command lines for reverse-shell one-liners.

How do you prevent reverse shell attacks?

The most direct control is egress filtering: default-deny outbound traffic and allow only the destinations and ports hosts genuinely need, so a connect-back to an attacker has nowhere to go. Combine that with patching and input validation to prevent the initial code execution, least privilege and segmentation to limit impact, restricting and logging interpreters like PowerShell, and endpoint and network detection to catch attempts that get through.

The bottom line

A reverse shell is the payload that turns one round of code execution into an interactive session, by making the victim dial out to the attacker instead of the attacker reaching in. It works because firewalls are built to stop inbound connections and trust outbound ones, and a reverse shell rides that trust straight out of the network, often over port 443 and wrapped in TLS so it looks like ordinary web traffic. That is also why it is hard to catch: the malicious connection hides inside the largest category of normal traffic there is.

The defense follows from the mechanism. Close the outbound path with egress filtering so the connect-back fails, remove the vulnerabilities and exposed services that grant the first command, run services with least privilege behind a segmented network, and watch the endpoint for the one thing a reverse shell cannot hide, a process that should never make an outbound connection suddenly making one. You will not stop every exploit, but you can make the connect-back a dead end and a loud one.