Web shell

What is a web shell?

A web shell is a script that makes it possible to gain remote shell access to the web server’s operating system through an HTTP connection. Black hat hackers often use web shells as backdoors to send commands to a compromised system.

What is a shell?

A shell is a program that lets users (or other programs) use operating system services. This term is now most often used to describe command-line interfaces created for that purpose, such as cmd.exe in Windows, but it can also be used to describe graphical user interfaces (GUIs). The name shell comes from the fact that this is the outer layer of the operating system.

Note that many shells are network-enabled (for example, telnet or SSH) and let users send commands to the operating system remotely. Such software is called remote shells.

How do web shells work?

In most legitimate scenarios, the user gains remote access to the web server by using authorized software such as SSH. They make a connection to the web server’s SSH port and obtain a text interface to send commands to the server’s operating system.

A web shell is a script that does exactly the same thing, but instead of using a specific protocol (for example, SSH) to connect to a specific service (for example, sshd), the connection is made over HTTP and then handled by whatever web server software the target is running.

Web shells are not malicious scripts by their nature. They only become malicious if they are uploaded by an attacker, for example, as a consequence of exploiting a web vulnerability.

Types of web shells

There are two types of web shells. One type requires the web browser as the client – in this case, the web browser displays an interface that lets the user send commands to the operating system and view the results. The second type requires a client script and looks like a typical command-line console. It uses HTTP to send commands to the web shell installed on the server, receives responses, and displays them in the console.

Note that web shells may be written in any programming language that the web server supports and runs. Most are developed in PHP due to its popularity, but you can find ASP, Python, Perl, Ruby, and Unix shell web shell scripts, too.

Web shells vs reverse shells

Web shells and reverse shells have precisely the same purpose: to allow remote shell access to a system. However, they use different methods to circumvent typical limitations such as firewalls:

• For reverse shells, the connection is established from the server to an attacker-controlled endpoint. Most firewalls do not block network traffic outgoing from the server, and such connections work directly even with NAT.
• For web shells, the connection is established to a web page. If the system serves web pages, it cannot block web access, so the attacker is always able to connect.

Note that complex web shell scripts often include reverse shell functionality, too. In such cases, the user (or attacker) connects to a web page for authentication and then uses that web page to create a reverse shell connection in the background.

A typical web shell attack scenario

Since the web shell is just one stage of an attack, here is an example chain of events that involves the use of a web shell:

1. The attacker discovers a local file inclusion (LFI) vulnerability in www.example.com, where the site allows modules to be included dynamically based on filenames provided in HTTP GET requests.
2. After establishing that www.example.com also lets users upload their own files, the attacker uploads a PHP web shell to www.example.com, calling the file test.php.
3. The attacker uses the LFI vulnerability to run the uploaded test.php PHP script: http://www.example.com/my_app/?module=test.php
4. In the browser window, the attacker now sees a command-line interface that allows them to send commands to the operating system and view the results.
5. The attacker may now attempt privilege escalation. For example, they may find a vulnerability in the operating system that allows them to gain root access to the compromised web server. They may also attempt to access other servers on the internal network (though this may be prevented by network segmentation).

Web shell example

The following very simple web shell uses the browser as the shell interface:

<form method="get" name="shell">
<input type="text" name="command" id="command" size="80" autofocus>
<input type="submit" value="Run">
</form>
<pre><?php if(isset($_GET['command'])) { system($_GET['command']); }?></pre>

However, penetration testers usually use more complex web shells, for example, the Weevely web shell that acts in a way similar to the telnet command.

Examples of well-known web shells

Web shells have been used by many prominent threat actors to control attacked systems. Here are some of the best-known examples.

• Malicious hackers from China often use the China Chopper software, originally discovered in 2012. The server-side component of China Chopper is written as an ASPX component (Active Server Page Extended) and targets Microsoft IIS servers. It was used, for example, to attack Australian Internet providers in 2019.
• The Hafnium group used a Microsoft JScript version of the China Chopper as part of the 2021 Microsoft Exchange Server attacks.

How to detect web shells?

Since web shells use typical HTTP connections, there is no simple way to detect whether your system has a web shell running. You need detailed cybersecurity forensics, including an audit of all incoming HTTP connections and all files within the web server directory:

• Check all server access and error logs for common keywords used by web shells. This includes filenames and/or parameter names used by well-known web shell scripts.
• Search for very long strings, which may indicate encoded web shell commands.
• Search for files on the web server system that have recently modified timestamps.
• See if there are any modifications in .htaccess files.

Note that professional black hat hackers create custom malicious code that avoids such detection methods. Therefore, the best course of action is to focus on preventing attackers from installing a web shell on your system in the first place.

It is also best practice to install file integrity monitoring software on the server. While a web shell itself does not modify crucial files, the following steps of an attack once a web shell is established often cause such changes. Having effective file monitoring can help you detect such cyberattacks as soon as possible.

How to prevent web shell use?

In general, web shells are not malware and can also be used for legitimate purposes, for example, remote server administration. If you don’t need to use web shells, you can try to limit the available options for creating them, but it is very difficult:

1. If any of your web applications allow file uploads to the web server, make sure that you only permit uploading for whitelisted file types. Take care to verify uploads not only based on file extensions but also by checking file content on the server side for potential malicious payloads. This will also help you avoid many other threats, such as botnet software used for DDoS attacks.
2. Limit the permissions of the operating system user used to run the web server software.
3. If you’re using PHP, disable potentially dangerous PHP functions such as exec(), shell_exec(), passthru(), system(), show_source(), proc_open(), pcntl_exec(), eval(), and assert(). To do that, add a disable_functions directive in your php.ini. Of course, this is only practical if you don’t use these functions in your web applications. Also, disable PHP execution in directories used to upload files to the server. Make sure to check if third-party content management systems written in PHP (like WordPress and its plugins) or any other open-source and commercial applications on your server use such functions.
4. If you use web application firewalls (WAFs) for your internet-facing servers, configure them to block attempts to upload malicious files and send typical web shell commands to a server.
5. Install antivirus/anti-malware software on your servers, both in the case of Microsoft Windows and Linux servers. Such software often includes signature-based detection for well-known malicious web shells used by black-hat hacker groups.

Even if you succeed in avoiding web shells, there are other methods that attackers can use to establish control over the system. For example, in some cases, they may use reverse shells instead.

How to avoid attacks based on web shells?

Because it’s extremely difficult, if not impossible, to completely prevent the use of web shells, the best way to avoid having a web shell installed on your server is to ensure the server is not susceptible to initial attacks. And the most common attacks that lead to attackers installing a web shell are web attacks exploiting vulnerabilities such as remote code execution (RCE), local file inclusion (LFI), remote file inclusion (RFI), SQL injection, cross-site scripting (XSS), and others.

Therefore, the best way to avoid attacks based on web shells is to prevent web vulnerabilities in the first place. The recommended way to avoid vulnerabilities in your web applications is to include security testing in the software development lifecycle through vulnerability scans with DAST and SCA tools, as well as vulnerability management.

Frequently asked questions

Related blog posts

• How web shells work

Written by: Tomasz Andrzej Nidecki, reviewed by: Benjamin Daniel Mussler