What Is Reverse Shell?

A reverse shell is a command shell in which the compromised system initiates the connection outward to the attacker, rather than the attacker connecting inward to it.

The direction is the entire point. Inbound connections are blocked by firewalls and network address translation; outbound connections are usually permitted freely, which makes the reversal a way around the perimeter rather than through it.

Why outbound is the easy direction

Most networks permit unrestricted outbound traffic on the assumption that internal systems are trustworthy. That assumption is what the technique exploits.

It also survives address translation and works from networks with no inbound reachability at all, which is why it is the default approach in both intrusions and authorised testing.

How it blends in

Connections over common web ports look like browsing. Traffic wrapped in encryption is opaque to inspection. Connections to legitimate cloud and collaboration services reach destinations your organisation already permits.

Some implementations connect only periodically rather than maintaining a session, which removes the long-lived connection that would otherwise stand out. At that point it is indistinguishable from ordinary command and control beaconing.

Egress control is the defence

The technique depends entirely on being able to reach an arbitrary external destination. Restricting outbound connections to what is genuinely required removes the capability rather than detecting it.

This is practical for servers and embedded devices, which have well-defined communication needs. It is harder for user workstations, where forcing traffic through a controlled proxy and blocking direct external connections achieves most of the same result.

Detection signals

Unexpected processes making outbound connections — a database engine, a web server process or an office application initiating a connection to an unfamiliar destination.

Long-lived connections to addresses with no history. Regular periodic connections. Command interpreters with network activity, which is a strong signal because shells do not normally talk to the internet.

Where they are usually found

Following web application exploitation, where the payload's first act is to establish one. After a successful phishing execution. And in authorised testing, where the same technique is standard practice.

That last point matters operationally: the presence of such traffic during a scheduled test is expected, which is why testing windows should be known to whoever watches the alerts.

Interactive sessions versus staged implants

A raw interactive shell is noisy: a long-lived connection, a live operator, and typed commands arriving at human speed. Detection is comparatively achievable where anyone is looking.

Serious intrusions therefore tend to upgrade quickly to a staged implant that checks in periodically, queues commands and disconnects between tasks. The technique is the same and the traffic pattern is quieter, which is why periodic beaconing analysis outperforms looking for long connections.

Cloud workloads deserve particular attention here, because a compromised container or function can usually reach the internet freely by default and also reach the platform metadata service holding its own credentials. Restricting both is configuration rather than tooling, and it turns a successful exploitation into a contained one.

Where to start

Pick your most exposed application server and enumerate the outbound destinations it genuinely needs. Restricting it to that list removes a whole class of post-exploitation capability.

See firewalls. GuardsArm runs security program reviews.