Things to Try When your Reverse Shell Fails

Target enumerated, check.
Vulnerability identified, check.
Tested payload delivery, check.
RCE verified, check.
Reverse shell…nope.

Today we are going to look at some practical ways to troubleshoot your reverse shell. Some of these points come from logical thinking, others are lessons learned from hours of frustration. If you’re already familiar with the different types of shells and how they work, feel free to skip to the troubleshoot your shell section. Otherwise, let’s do a quick review of what’s happening under the hood.

How Reverse Shells Work

A reverse shell is where the target machine connects back to the attacking machine. This is usually because the target is behind a firewall, and we can’t connect to it directly, except on explicitly allowed ports, such as 80 and 443 on web servers. To prepare for the connection, the attacking machine will have a port open and listening before the shell is initiated. The steps usually look something like:

1. Listen on a specific port for an incoming connection
2. Send a payload to the target machine
3. Execute the payload on the target machine, this opens a connection back to the attacking machine to the specific port
4. The connection is received, and a shell is spawned

Reverse Shell - Target Connects Back to Attacker — Reverse shell

How Bind Shells Work

A successful bind shell should yield the same results as a reverse shell, but instead of the target machine connecting back to the attacking machine, the attacking machine connects directly to the target. Often we can use this approach if we have already infiltrated the network where our target resides. The steps will be:

1. The attacker starts a listener on a specific port on the target machine
2. The attacker then connects to that port from their attacking machine
3. Once the connection is make, a shell is spawned

Bind Shell - Attacker connects back to the target — Bind shell

Troubleshooting your Shell

Check For Typos and Mistakes

Let’s start with the obvious checks.

Are you using the correct IP address?
Are you using the correct port?

Often typos and mistakes when copying and pasting lead to oversights that can cause commands to fail. Double check these first, and if you’re calling a payload to trigger your connection, verify you have the correct filename and path to the payload.

Do You Have the Correct Permissions to Execute your Payload?

If you don’t have permissions to execute your payload, nothing will happen. Ideally your RCE would already be verified before we reach this point, but sometimes when going from PoC to a stable shell we get excited and skip steps in the process. Make sure you are actually able to execute your code or binary.

Bonus tip: If you’re updating the permissions of your target binary via a webshell using chmod in the URL, using chmod +x /tmp/payload won’t work. In this case, the + will be interpreted as a URL encoded character for a space. Once decoded it will be chmod x 777. In this case you can use numerical permissions such as chmod 777 /tmp/payload instead.

When Using Netcat, Check if the -e Flag is Available

Netcat can get us up and running with a stable reverse shell very quickly. However, depending on the variant it can be missing the -e flag (-e executes a specified file after the connection is made, in our case, we often use -e /bin/bash). If you have RCE and are able to read the output of your commands, you can easily check this with nc -h.

Check if You Are Using a Common Port

Many of us are using ports like 4444 and 1337 for our shells. This is a common mistake, as generally a hardened environment won’t allow traffic to flow over uncommon ports without a good reason (deny bt default). If we’re using a reverse shell, it’s usually best to use common ports (80, 443, 8080, 139, 445) that services are running on as it’s more likely traffic will be allowed. If you’re using a bind shell, you’ll need to test for ports you have permission to open a listener on, as well as allowing traffic to connect to.

For red teamers that are trying to evade detection, OpSec is important. Using ports like 1337 is a great way to get caught by the blue team.

Therefore, it’s considered good practice to use common ports like 80, 443, etc. for your shells.

Check for the Existence of AV/EDR/Firewalls

Often on Windows targets, security solutions prevent us from getting a stable shell in the first place. If you have RCE and can read the output then try to enumerate what services are running. Below are a few commands to try to get some insight on services interfering with your fun.

PS C:\> wmic /namespace:\\root\securitycenter2 path antivirusproduct
PS C:\> Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntivirusProduct
PS C:\> Get-Service WinDefend
PS C:\> Get-NetFirewalLProfile
PS C:\> Get-EventLog -List
PS C:\> wmic product get name,version

On Linux, we can also check for local firewall rules that might be causing some trouble. Though these might require elevated privileges, it’s worth a try.

$ iptables -S
$ firewall-cmd --list-services

Check if You’re Trying to Catch a Staged Payload with nc

There is a key difference between staged and stageless payloads. Staged payloads are sent in multiple stages, with the initial payload used to establish a connection. Once connected, the remaining stages of the payload are then delivered. With stageless, as I’m sure you’ve guessed, the whole payload is delivered in one. It’s typically larger and less flexible than a staged approach. Therefore, if you’ve setup a nc listener, and you’ve mistakenly generated a staged payload with msfvenom, unfortunately it won’t work. You need to make sure you are using a stageless payload in this case.

Bonus tip: When you are doing binary exploitation and have limited space, stageless payloads are the way to go.

Try Different Payloads

Every target is different. From the operating system and architecture, to the installed packages, patch levels, security software and firewall configuration. This means that often you will need to try a few different payloads before you can get a stable shell.

Some advice to live by as a penetration tester is enumerate enumerate enumerate. The more you know about your target, the easier it will be to understand what went wrong, and adjust your attack to get your payload working.

Bonus Tip: It Connects, Then Dies Instantly (or a few seconds later)

If you’re using Metasploit and your shell keeps dying, you can easily migrate to a new process. The migrate command will move the current session to a different process on the target. Before you can do this, you’ll need to know the process ID (PID) of the process you want to migrate into. With RCE this should be fairly easy information to obtain.

One thing to be aware of though, migrating to another process is often detected by EDR. If you’re trying to be stealthy, this isn’t always the best approach.

About the Author: Alex Olsen

Alex is a Web Application Security specialist with experience working across multiple sectors, from single-developer applications all the way up to enterprise web apps with tens of millions of users. He enjoys building applications almost as much as breaking them and has spent many years supporting the shift-left movement by teaching developers, infrastructure engineers, architects, and anyone who would listen about cybersecurity.

Alex holds a Master’s Degree in Computing, as well as the PNPT, CEH, and OSCP certifications.

About TCM Security

TCM Security is a veteran-owned, cybersecurity services and education company founded in Charlotte, NC. Our services division has the mission of protecting people, sensitive data, and systems. With decades of combined experience, thousands of hours of practice, and core values from our time in service, we use our skill set to secure your environment. The TCM Security Academy is an educational platform dedicated to providing affordable, top-notch cybersecurity training to our individual students and corporate clients including both self-paced and instructor-led online courses as well as custom training solutions. We also provide several vendor-agnostic, practical hands-on certification exams to ensure proven job-ready skills to prospective employers.

See How We Can Secure Your Assets

Let’s talk about how TCM Security can solve your cybersecurity needs. Give us a call, send us an e-mail, or fill out the contact form below to get started.

Things to Try When your Reverse Shell Fails

How Reverse Shells Work

How Bind Shells Work