Shells and Reverse Shells: The Principles

Once a weakness gives you a way to run commands on a target, you need a convenient way to keep interacting with it. This is the role of a shell. In this lesson you will understand what a shell is in this context, the difference between a regular and a reverse connection, and why these concepts matter as much for defence as for testing.

What a shell means here

You already know a shell as the command-line interface you use on your own Kali machine (bash, for example). In an exploitation context, "getting a shell" on a target means obtaining that same kind of interactive command access, but on the target machine, through the specific weakness you exploited. From there, you can run commands exactly as if you were sitting at that machine's own keyboard, within whatever privilege level the weakness granted you, which is often limited at first, a theme the next chapter on post-exploitation develops in depth.

Two directions of connection

Network connections have a direction: one side initiates, the other side listens and accepts. This simple fact gives rise to two very different patterns.

• A "bind" shell: the target machine starts listening on a port, waiting for a connection, and the tester connects to it from their own machine. This is conceptually the simplest pattern, similar to connecting to any ordinary service.
• A "reverse" shell: the tester's own machine listens, and the target machine initiates the connection outward, back to the tester.

Why reverse shells are so common in practice

At first glance, a bind shell seems simpler, so why do reverse shells appear so often in real engagements and training material? The answer lies in how networks are usually configured:

• Organisations commonly configure firewalls to block most incoming connections to internal or workstation machines, while allowing outgoing connections (for ordinary web browsing, updates, and so on) much more freely.
• A bind shell on the target requires an incoming connection to reach it, which a firewall is more likely to block.
• A reverse shell only requires the target to make an outgoing connection, which is far more likely to be permitted, especially on a common port already used for other outgoing traffic.

This is exactly why, from a defensive point of view (which you studied in earlier courses of this track), monitoring and restricting outgoing connections from sensitive machines, not just incoming ones, is an important and often under-appreciated control.

The conceptual shape of a reverse shell

Rather than specific commands, understand the shape of the interaction:

1. The tester starts a listener on their own machine, on a chosen port, waiting for an incoming connection.
2. Through the exploited weakness, the target machine is made to initiate a connection back to the tester's address and port.
3. Once connected, the tester's listener receives an interactive command channel, and commands typed by the tester are executed on the target, with their output sent back.

A generic illustration of starting a listener, using a basic network tool rather than any specific exploit payload:

# On the tester's own machine, in the authorised lab:
nc -lvnp 4444

This command tells nc to listen (-l) verbosely (-v) without resolving names (-n) on port 4444 (-p 4444), waiting for an incoming connection, which is the generic building block behind many reverse shell techniques, independent of any specific vulnerability.

Limitations of a basic shell

A first shell obtained this way is often simple and fragile: it can be unstable on an unreliable network connection, it may lack features you expect from an ordinary terminal (such as proper handling of certain keys or a full-screen text editor), and it typically runs with whatever privilege level the original weakness granted, which is frequently a limited, non-administrative account. Dealing with this last limitation is exactly the subject of privilege escalation in chapter 6.

Keeping shells inside the rules

Professional discipline includes closing shell sessions cleanly at the end of a testing session, noting exactly when each session started and ended in your journal, and, in a real engagement, removing any temporary listener or added account before the engagement closes, exactly as mentioned in the previous lesson.

Your fil rouge: documenting a shell session

Using the lab machine and finding from the previous lesson, if you obtained command execution there, start a basic listener on your Kali machine following the official instructions of your training platform or lab exercise for that specific machine, and add a short note to your journal describing which direction of connection (bind or reverse) was used and why that choice made sense given the lab's network setup. If your particular exercise did not produce a shell, write instead a short paragraph explaining which direction you would expect to work better given a hypothetical firewall configuration that blocks all incoming connections to the target but allows outgoing web traffic, and why.

Your turn: diagnose a connectivity problem

A fellow student sets up a bind shell on a lab target and tries to connect to it from their attacker machine, but the connection times out. They mention that the lab network has a strict firewall rule on the target that blocks all incoming connections except on port 80. What is the most likely explanation, and what change would you suggest?

See a solution

The most likely explanation is that the bind shell is listening on a port other than 80, and the firewall on the target is blocking the incoming connection to that port, exactly the scenario described in this lesson as the main reason reverse shells are preferred in practice. A reasonable suggestion is to switch to a reverse shell approach instead, where the target initiates an outgoing connection to the tester's listener, since outgoing connections are typically allowed more freely, or alternatively, if only port 80 accepts incoming traffic, to use a listener bound to that specific port if the lab exercise's instructions support it.

A single compromised machine is rarely the end of the story in a real network. The last lesson of this chapter introduces pivoting: using one foothold to reach further into a network.