Web shell

What is a web shell?

A web shell is a script that makes it possible to gain remote shell access to a web server’s operating system through an HTTP connection. Malicious hackers commonly use web shells as backdoors that allow command execution on a compromised system and enable ongoing malicious activity without needing repeated exploitation.

Once installed, a web shell often becomes a command and control point that may allow an attacker to issue commands, access the file system, upload or run executable files, and maintain persistent access to the server.

What is a shell?

A shell is a program that lets users (or other programs) interact with operating system services. Today, the term is most often used to describe command-line interfaces created for that purpose, such as cmd.exe on Windows, but it can also refer to graphical user interfaces. The name comes from the idea of a shell being the outer layer through which users interact with the operating system.

Many shells are network-enabled, such as those accessed via SSH or telnet, and allow commands to be sent remotely. These are commonly referred to as remote shells.

How do web shells work?

In legitimate scenarios, administrators gain remote access to a web server using authorized tools such as SSH. They connect to a dedicated service and obtain a text-based interface for issuing commands to the operating system.

A web shell provides similar functionality but works very differently. Instead of using a dedicated remote access protocol, the attacker communicates with the server over HTTP or HTTPS. The web shell is handled by the web server itself and executed by the application runtime, whether that is PHP, ASP.NET, JSP, or another supported technology.

While web shells can technically have non-malicious administrative uses, dedicated admin tools are usually a better and safer solution. In practice, this means that a raw command-execution shell on a production server is almost always a sign of compromise. Web shells are typically installed after exploiting a web vulnerability that allows file uploads, command execution, or access to the underlying file system.

Types of web shells

There are two main types of web shells.

One type uses a web browser as the client. In this case, the attacker accesses a web page that displays a simple HTML interface for sending commands and viewing the results. The second type relies on a separate client script and behaves like a traditional command-line console. Commands are sent over HTTP to the web shell, responses are returned, and the output is displayed locally.

Web shells can be written in any language supported by the web server. While PHP shells are common, attackers also use ASP, ASPX, JSP, Python, Perl, Ruby, and Unix web shell scripts, depending on the target environment.

Web shells vs reverse shells

Web shells and reverse shells serve the same basic purpose (providing remote access to a system), but they differ in how they bypass common cybersecurity controls:

• With reverse shells, the compromised server initiates an outbound connection to an attacker-controlled system. Outbound connections are often less restricted by firewalls, making this approach effective even in segmented networks.
• With web shells, the attacker connects to a web endpoint hosted on the compromised web server. Because the server needs to accept HTTP traffic to function normally, completely blocking this access is usually not an option.

More advanced web shells may combine both approaches. For example, a web-based interface may be used for authentication and validation before triggering a reverse shell connection in the background.

One important difference compared to a web shell is that a reverse shell on a compromised server can often be established without writing a file to disk. This is one area where web shells are comparatively easier to detect, since they typically require a file on disk that file integrity monitoring can flag.

A typical web shell attack scenario

A web shell is usually one stage of a broader cyberattack rather than the initial entry point. A simplified example attack chain might look like this:

1. An attacker discovers that www.example.com allows users to upload files but does not properly validate file types or restrict executable content.
2. The attacker uploads a PHP web shell to the server, for example by submitting it through an upload form that is intended for images or documents.
3. Because the uploaded file is stored in a web-accessible directory and PHP execution is allowed, the attacker requests the file directly, such as http://www.example.com/uploads/test.php.
4. When the malicious file is accessed, the web shell executes and presents an interface that allows the attacker to send commands to the operating system and view the results.
5. With command execution available, the attacker may attempt privilege escalation, explore the file system, deploy additional malicious tools, deface web content, or pivot to other systems on the internal network.

At this point, the presence of a web shell typically indicates that the application and server are already compromised and should be treated as such.

Web shell examples

The following simple example in PHP shows how a browser-based web shell might work, though web shells can be created in most programming languages. In this case, a web form is used to submit shell commands that are then executed on the web server using the system() function:

<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>

While this example provides a clear illustration of the web shell concept, real-world attacks typically use more complex and often obfuscated web shells. For one thing, a real attack payload usually wouldn’t use GET requests since those show up in server logs and are easy to detect. It’s also far too long for what it does – here’s a more realistic one-liner with some trivial obfuscation added:

<?php $f = str_rot13('flfgrz'); $f($_REQUEST['cmd']); ?>

In this example, the string system is entered in its ROT13 form to evade basic filtering and then decoded to run commands. $_REQUEST is also used to accept POST as well as GET requests. Note that ROT13 is only one of many possible obfuscation techniques – attackers also commonly use base64 encoding, string concatenation, and dynamic function calls to avoid detection.

Penetration testers and attackers alike use specialized web shell tools such as Weevely, which provide encrypted communication, authentication, and additional features.

Examples of well-known web shells

Web shells have been widely used in real attacks by multiple threat actors.

• China Chopper is one of the most well-known examples. This lightweight but powerful tool has been used for years to compromise servers running IIS and other platforms. Variants of the China Chopper web shell have appeared in multiple languages and have been linked to large-scale attacks.
• During the 2021 Microsoft Exchange Server attacks, the Hafnium group used a JScript-based version of China Chopper to maintain access to compromised systems. The shell was set up following the exploitation of CVE-2021-26855 and related vulnerabilities in the ProxyLogon exploit chain.

These examples highlight how web shells are often used as long-term access mechanisms rather than one-off attack tools.

How to detect web shells?

Because web shells use standard HTTP requests, detecting them is challenging. There is no single indicator that reliably shows a web shell is present. Detection usually requires a combination of forensic analysis and monitoring.

Common approaches include:

• Reviewing web server logs for suspicious parameters, unusual request patterns, or known web shell signatures.
• Looking for long or seemingly random strings that may indicate encoded or obfuscated commands.
• Checking the file system for recently modified files, especially in directories that should only contain static HTML or media files.
• Inspecting configuration files such as .htaccess for unauthorized changes.

Skilled attackers often use custom or heavily obfuscated shells designed to evade these checks. For this reason, early detection is difficult, and prevention is far more reliable.

File integrity monitoring can also help. While a web shell itself may be a single file, follow-on malicious activity often involves changes to executables, configuration files, or application code.

How to prevent web shell use?

Because web shells can technically serve administrative purposes, some environments may not flag them by default, but most security teams will investigate any web shell presence as an indicator of compromise. 

The key to preventing web shells is to reduce the attack surface that allows them to be installed in the first place. Best-practice preventive measures include:

1. Strictly validating file uploads. Allow only expected file types, verify content on the server side, and never rely solely on file extensions.
2. Limiting the permissions of the operating system account used by the web server.
3. Disabling dangerous functions in environments such as PHP, wherever functions like exec(), system(), and eval() are not strictly required. 
4. Disabling script execution in upload directories, in particular for popular PHP-based content management systems like WordPress (including any plugins and modules).
5. Configuring web application firewalls to detect and block suspicious uploads and command execution attempts for internet-facing systems.
6. Using antivirus or anti-malware tools that can detect known malicious web shells.

Keep in mind that even with these controls, attackers may use alternative techniques, such as reverse shells, to obtain and maintain access.

How to avoid attacks based on web shells?

Completely preventing web shells is extremely difficult. The most effective defense is to prevent the initial vulnerabilities that allow attackers to upload or execute them.

Web shells are commonly installed following the successful exploitation of issues such as remote code execution (RCE), local or remote file inclusion, SQL injection, or cross-site scripting. Addressing these weaknesses significantly reduces the risk.

This is why security testing should be a routine part of the development and operations process. Regular vulnerability scanning with DAST and SCA tools, combined with vulnerability management, helps identify and fix exploitable issues before attackers can get at them. See how Invicti combines DAST, SCA, posture management and more within a unified application security platform.