Reverse shells are what pop up in incident reports right after someone asks “how did they get a shell out of a network that only allows outbound HTTPS?” The honest answer is that egress filtering on most networks is either an afterthought or nonexistent, and attackers have known this for two decades.
What a Reverse Shell Actually Does
A reverse shell flips the usual connection model. Instead of an attacker connecting inbound to a listening port on a compromised host, the compromised host initiates an outbound connection back to a server the attacker controls. That connection carries an interactive command shell, giving the attacker a live session on the victim machine.
This matters because most organizations spend their firewall budget on inbound rules. Ingress traffic gets scrutinized, logged, and often blocked by default. Egress traffic – connections leaving the network – is frequently wide open, because blocking it tends to break things people don’t expect (software updates, telemetry, third-party APIs), and nobody wants to be the one who broke production troubleshooting it.
Why Egress Ports Are the Real Vulnerability
An open egress port isn’t a vulnerability in the traditional CVE sense. It’s a policy gap. The port itself isn’t running vulnerable software – it’s just permission for traffic to leave. But that permission is exactly what a reverse shell payload needs to phone home.
A typical scenario: a web application gets compromised through an unpatched plugin. The attacker drops a small payload that opens an outbound TCP connection on port 443 to an external IP. Because port 443 is almost universally allowed outbound (it’s what browsers use for every HTTPS site), the connection sails past the firewall without triggering a single inbound alert. From the network’s perspective, it looks like the server is just making a web request.
This is the part that catches people off guard: they assume because they locked down inbound access tightly, they’re covered. Inbound hardening does nothing to stop a reverse shell, because the compromised host is the one initiating the connection. That’s the myth worth busting directly – closing unnecessary listening ports protects against unauthorized inbound access, not against a host that’s already been compromised and is calling out.
Common Ports Abused for Reverse Shells
Attackers gravitate toward ports that blend into normal traffic patterns:
Port 443 (HTTPS) – the most common choice. Encrypted, expected, and rarely inspected deeply unless the organization does TLS interception.
Port 53 (DNS) – used for DNS tunneling when even outbound HTTPS is restricted. DNS almost always has to be allowed outbound for basic name resolution to work, which makes it a reliable fallback channel.
Port 80 (HTTP) – less common now since plaintext traffic is easier to inspect, but still used against networks with lax outbound filtering.
High, non-standard ports – tools like Metasploit’s default reverse shell payloads often use arbitrary high ports (4444 is the classic example) when the attacker isn’t worried about blending in, usually in test environments or against networks with no egress filtering at all.
The choice of port usually reflects what the attacker expects to survive the network’s egress rules, not any technical requirement of the shell itself. Netcat, for instance, will happily open a reverse shell on any port you tell it to.
How to Detect and Prevent Reverse Shell Activity
Preventing this class of attack requires shifting some attention from inbound rules to outbound policy, plus watching what’s actually listening and connecting on your servers.
Restrict egress traffic by default. Move toward a default-deny outbound policy where only explicitly required destinations and ports are allowed. This is a significant operational shift for most teams and won’t happen overnight, but even partial segmentation – restricting database servers from making arbitrary outbound connections, for example – closes off a lot of easy reverse shell paths.
Monitor for unexpected listening services and outbound connections. A server that suddenly has a new process making outbound connections to an unfamiliar IP is worth investigating immediately. This is where watching for unusual listener behavior pays off, since reverse shell tooling often leaves other footprints beyond the outbound connection itself.
Use external, continuous port monitoring. Internal firewall rule reviews miss a lot – rules drift, exceptions pile up, and nobody notices a rule got loosened six months ago for a project that’s since been abandoned. Regularly validating what’s actually reachable from outside, and cross-checking against documented policy, catches configuration drift before an attacker finds it. This is also where external scans against your own firewall rules tend to surface gaps that internal reviews miss entirely.
Log and alert on DNS anomalies. Since DNS tunneling is a common fallback when HTTPS is blocked, unusually long DNS queries, high query volume to a single domain, or queries to newly registered domains are worth flagging.
Segment sensitive systems. A compromised web server calling out on port 443 is bad. A compromised web server that also has unrestricted access to internal database ports is much worse. Proper network segmentation limits how far a reverse shell foothold can be leveraged into lateral movement.
A Common Mistake in Incident Response
One pattern that shows up repeatedly in post-incident reviews: teams find the reverse shell process, kill it, and consider the incident closed. But the outbound connection succeeded because a policy gap allowed it – and if that gap isn’t closed, the same technique works again five minutes later with a different payload. Fixing the symptom without fixing the underlying egress rule is a common way the same incident repeats within weeks.
Frequently Asked Questions
Can a firewall block all reverse shells?
Not entirely. A well-configured egress policy can block many reverse shell attempts by restricting which ports and destinations are reachable, but sophisticated attackers will use tunneling techniques over allowed protocols like DNS or HTTPS to blend in. Egress filtering raises the cost of the attack significantly rather than eliminating the risk completely.
Why do organizations ignore egress filtering?
Mostly operational friction. Inbound rules protect against external attackers and are easier to reason about. Outbound rules require understanding every legitimate destination a server needs to reach, and getting it wrong breaks business functions – so many teams leave outbound traffic permissive by default and never revisit it.
Does closing unused inbound ports prevent reverse shells?
No. Closing unnecessary listening ports reduces the attack surface for how an attacker gets in initially, but a reverse shell is an outbound connection from an already-compromised host. The two controls address different stages of an attack and both matter, but neither substitutes for the other.
Reverse shells succeed because most networks treat outbound traffic as trusted by default. Auditing what’s allowed to leave your network is just as important as auditing what’s allowed in, and it’s a gap that inbound-focused security reviews consistently miss.