Explain reverse shells versus bind shells and when you'd choose each.

After landing code execution, you need an interactive channel back to the target. The two classic models differ in which side initiates the TCP connection, and that single detail decides which one actually works in real networks.

Bind shell

In a bind shell, the payload on the target opens a listening socket on a port and waits. The attacker then connects into that port to get a shell.

• Direction: attacker connects in to the target.
• Problem: inbound connections to the target are usually blocked by perimeter firewalls and NAT. A victim behind NAT typically isn't reachable from the internet at all, and inbound ports are the first thing firewalls drop.
• Bind shells are mostly useful on a flat internal network where you already have direct reachability.

Reverse shell

In a reverse shell, the attacker runs a listener, and the payload on the target makes an outbound connection back to it.

• Direction: target connects out to the attacker.
• Advantage: outbound traffic is far more permissive. Most networks let hosts make outbound connections (especially on 80/443), and NAT handles the return path automatically. This is why reverse shells are the default in real engagements.
• To blend in, testers often have the callback ride common ports and even wrap it in TLS.

The catch: egress filtering

A mature network restricts outbound traffic too. If only proxied web traffic is allowed out, a naive reverse shell to port 4444 dies. Testers adapt by calling back over 443, tunneling through the proxy, or using DNS/ICMP/HTTPS C2 channels.

What interviewers look for

That you correctly state who initiates the connection, that you default to reverse shells because of firewalls and NAT, and that you understand egress filtering as the real-world constraint — bonus points for mentioning TTY stabilization and blending into 443.