Skip Navigation
Get a Demo


Common web shells

In 2021, adversaries exploited web applications with help from web shells such as China Chopper, Godzilla, and Behinder.
Pairs With This Song


Editors’ note: While the analysis and detection opportunities remain applicable, this page has not been updated since 2022.


Web shells seriously affected many environments in 2021 due in large part to Microsoft Exchange and Zoho ManageEngine web server exploitation. Throughout the year, adversaries exploited ProxyShell, a Microsoft Exchange vulnerability, to gain privileged access to email systems owned by thousands of organizations. In these cases, the adversaries left behind a China Chopper web shell, a small and extensible bit of code that runs arbitrary ASP.NET, PHP, JSP, and other languages. Some versions of China Chopper require authentication with a preset password, but many adversaries fail to implement this, meaning that multiple adversaries can use the same web shell in different campaigns at once.

We also observed adversaries exploiting Oracle WebLogic servers to install the Godzilla web shell. Like China Chopper, Godzilla supports execution in ASP.NET, JSP, and PHP. Unlike China Chopper variants though, Godzilla web shells use a combination of simple password authentication with an additional encryption key value to require adversaries to have two pieces of information to communicate with the shell. The authentication ensures that only a single adversary can use the web shell. This encryption also obfuscates network traffic and confounds network-based analysis.

Finally, we observed the Behinder web shell following adversaries exploiting a Java-based web application made by Chinese cloud software company Yonyou. Behinder can load and execute compiled payloads in addition to standard commands. As with Godzilla, Behinder supports encryption and goes the extra mile by randomizing User-Agent strings in network traffic to hinder network and log analysis.

Why web shells matter

Web shells are malicious scripts designed to maintain persistent access to compromised web servers and facilitate remote code execution. Some are simple, allowing adversaries to issue a single command in a text box on a web page, while others include extensive capabilities where the adversary’s imagination is the limit. Web shells execute with the same user account privileges as the exploited web application. If the application runs as an administrator, sensitive databases and systems may be accessible. Most web shells have simple or non-existent authentication mechanisms. Adversaries often leave web shells on public-facing web servers with no authentication mechanisms so they can return to the systems later. In some incidents, responders may find many web shells on a single server or evidence of multiple adversaries using an abandoned web shell. Web shells should be removed as soon as possible to prevent further access.

Patching should be the first step for remediating vulnerable web applications like Exchange, to prevent web shells from being dropped at all. Look for evidence of an existing breach by following guidance from the application developers. For example, Microsoft recommends using the Microsoft Support Emergency Response Tool (MSERT) to scan the Exchange server for exploitation.

If you cannot patch your web applications, consider creating IIS rewrite rules, disabling Unified Messaging services, and disabling multiple Internet Information Services (IIS) application pools. These stopgap measures may affect the internal and external availability of your applications, depending on which products your organization uses. For more remediation advice, check out our blog Microsoft Exchange server exploitation: how to detect, mitigate, and stay calm.

To detect web shells, start by examining file modifications and process executions. For Exchange servers, look for suspicious ASPX file modifications that may indicate an adversary wrote a web shell to disk. For other web applications like ASP.NET, PHP, and JSP applications, look for suspicious process behaviors. For example, you may be able to identify web shell activity by watching for web server worker processes spawning cmd.exe and PowerShell, certutil on Windows, or curl on Linux systems.

Windows IIS Worker process spawning certutil.exe

This detection analytic will identify unusual activity originating from w3wp.exe executing certutil to download files.

parent == w3wp.exe
command_line_includes ('certutil' && '-split')

Linux PHP or Java processes spawning wget or curl

This detection analytic will identify unusual activity originating from Linux web servers executing wget or curl to download files.

parent_process == ('php' || 'java')
command_line_includes ('wget' || 'curl')
Back to Top