Reverse Shells and Living Off the Land: Why Netcat Still Matters

Netcat reads and writes arbitrary TCP and UDP connections. That is all it does, and it is why the same tool appears in a network engineer's troubleshooting kit and in an attacker's toolkit — the general-purpose nature is the point. The concept worth extracting from it is the difference between a bind shell and a reverse shell, which explains most of how command channels work.

Bind shells and reverse shells

A bind shell listens on the compromised host and waits for the attacker to connect to it. Conceptually simple, and almost always blocked in practice, because inbound connections to an arbitrary port on an internal host are exactly what a perimeter firewall exists to prevent. Address translation makes it worse for the attacker, since the host may not be addressable at all.

A reverse shell inverts it: the compromised host connects outward to the attacker, who is listening. The firewall sees an outbound connection from an internal host, which is the traffic it is configured to permit.

That inversion is the whole reason reverse shells dominate. Perimeter firewalls are typically strict inbound and permissive outbound, so the attacker uses the direction that is allowed — and the exam question usually turns on recognizing that.

Ports are chosen to blend in. Outbound 443 looks like web browsing and is permitted almost everywhere, so a reverse shell on 443 passes the port-based check even though nothing about it is HTTPS.

Legitimate uses

Genuine, and the reason the tool is present on systems.

Testing whether a port is reachable and what a service says when you connect — the banner-reading described under banner grabbing. Verifying firewall rules by attempting connections that should and should not succeed, which is the rule-validation argument under packet crafting. Transferring a file between two hosts quickly. Standing up a listener to confirm something can reach you.

Which creates the classic detection problem: the tool itself is not malicious, and its presence is not evidence of anything. Behaviour is.

Living off the land

The more important point. An attacker does not need netcat, because a reverse shell can be built from almost anything already installed — a scripting language interpreter, a shell with network redirection support, a management framework, a remote administration utility.

Removing netcat from systems is worth doing and achieves little on its own, because the capability is inherent in the tooling any usable system has. That is the living-off-the-land principle described under fileless malware and persistence: there is no malicious binary to find because none is needed.

Which means the defence cannot be about the tool.

Egress control is the answer

If the reverse shell works because outbound traffic is permitted, the control is to stop permitting it indiscriminately.

Default-deny outbound, with an allowlist of what each segment legitimately needs. Server segments in particular rarely need arbitrary internet access, and a database server that can reach the whole internet is a finding.

Force web traffic through a proxy, so a raw connection on 443 that is not HTTPS fails, and inspection applies to what is. A reverse shell surviving a proxy has to speak the protocol convincingly, which raises the cost substantially — the enforcement point under secure web gateways.

Restrict DNS to your own resolvers and block the alternatives, since DNS is the fallback channel when everything else is closed — the tunnelling detection under DNS filtering.

Application allowlisting constrains what can run, and constrained language modes limit what scripting engines can do.

Detecting it

Process behaviour is the strongest signal. A shell or interpreter spawned by a web server, a document application or a service process is anomalous regardless of what it then does, and it is the detection that catches the whole family — recorded by behaviour-based EDR.

Network behaviour supplies the rest: an outbound connection from a host that does not normally initiate one, a long-lived connection with low-volume bidirectional traffic, and the regular interval pattern of beaconing that shows in flow data.

Protocol mismatch is the other good signal — traffic on 443 that never performs a TLS handshake is not HTTPS, and a proxy or an inspection point notices immediately even without decryption.

Exam angles

Distinguish a bind shell, which listens on the victim for an inbound connection, from a reverse shell, where the victim connects outward to the attacker. Know that reverse shells are preferred because firewalls are strict inbound and permissive outbound, and that common ports are chosen to blend with legitimate traffic. Recognize that removing tools does not remove the capability because of living-off-the-land techniques, and that egress filtering, proxy enforcement and process behaviour detection are the effective controls.