What Is a Web Shell? Detection and Defense

In early 2021, a single 4 kilobyte file landed on roughly 30,000 organizations in the United States. It was called China Chopper, and HAFNIUM operators dropped it onto Microsoft Exchange servers after chaining the ProxyLogon vulnerabilities. That tiny file gave the attackers a command interface into each network without a single stolen password. By March 9, an estimated 250,000 servers were affected.

That file was a web shell. It is one of the most economical footholds in offensive security: a few lines of script that convert a public-facing web server into an attacker-controlled terminal. This guide covers what a web shell is, how attackers plant and use one, and the detection and prevention controls that actually catch them.

What Is a Web Shell?

A web shell is a malicious script uploaded to a web server that lets an attacker run commands on that server remotely, usually through ordinary HTTP requests to the page hosting it. The server treats the script as just another file in its web directory. The attacker treats it as a remote shell.

MITRE ATT&CK catalogs the technique as T1505.003, Server Software Component: Web Shell, under the Persistence tactic. It applies to Linux, Windows, macOS, and network devices. The classification matters: a web shell is not primarily an entry point. It is what an attacker installs after getting in, so they can come back. The server keeps serving it across reboots, patches to other services, and password changes, which is exactly the durable access adversaries want.

Web shells are written in whatever language the server already runs. PHP, ASP, ASP.NET (.aspx), JSP, and Perl are the common ones, because the server has an interpreter for them and will execute them without complaint. Some are a single line. The classic PHP one-liner passes a request parameter straight into the system's command interpreter:

<?php system($_GET['cmd']); ?>

Request shell.php?cmd=whoami and the server runs whoami and returns the output in the page. Others, like China Chopper, ship with a graphical client and a server-side stub small enough to hide in plain sight. The capability ranges from a bare command line to full file managers, database browsers, and pivoting tools.

How a Web Shell Attack Works

A web shell does not appear on its own. It is the payload of an earlier compromise, then the launch point for everything after. The chain runs in five stages.

First, the attacker finds a way to write a file to the server. This is the exploited weakness: an unrestricted file upload form, a vulnerable plugin, an SQL injection that writes to disk, a directory traversal flaw, or a remote code execution bug like ProxyLogon. Any path that lets attacker-controlled content reach the web root will do.

Second, they place the script in a directory the web server will execute, often disguised with an innocuous name like error.aspx or buried among legitimate files.

Third, they execute commands by requesting the file over HTTP or HTTPS. Because the traffic is normal web traffic on port 443, it blends into everything else hitting the server. There is no new listening port, no obvious malware process beating on the network.

Fourth, the web shell provides persistence. The attacker now has a reliable way back in that survives reboots and does not depend on the original vulnerability staying open. This is why ATT&CK files it under persistence rather than initial access.

Fifth, they expand. From the web server the attacker performs reconnaissance, harvests credentials, escalates privileges, and begins lateral movement toward the systems that hold the data they came for. The web shell becomes a staging post for the rest of the intrusion.

What Attackers Do With a Web Shell

Once a web shell is live, it is a general-purpose remote access tool. Common uses:

• Command execution. Run arbitrary OS commands as the web server's user account.
• Persistence. Maintain a foothold that outlives patches to the original entry vector.
• Credential theft. Read configuration files, environment variables, and connection strings for database and service passwords.
• Data staging and exfiltration. Compress, stage, and pull sensitive files out through the same web channel.
• Pivoting. Use the server as a relay deeper into the internal network, including tools like reGeorg that tunnel traffic through the shell.
• Deploying further payloads. Pull down ransomware, miners, or additional tooling.

The web server account often has more access than it should: read access to application databases, network reach to internal hosts, and sometimes excessive filesystem rights. The web shell inherits all of it.

Web Shells in the Wild

This is not theoretical. Named threat groups rely on web shells, and their tools are well documented in ATT&CK.

Groups observed using the technique include APT28, APT29, APT41, HAFNIUM, Leviathan, Volt Typhoon, and Dragonfly. The pattern is consistent: exploit a public-facing application, drop a web shell, then use it as the durable door back in.

How to Detect a Web Shell

Web shells are designed to blend in, which is what makes detection a discipline rather than a single alert. Effective programs layer several signals, and proactive threat hunting often finds a web shell that slipped past automated alerting.

File-based detection

File integrity monitoring is the foundation. Web content changes through known deployment processes. A new or modified .php, .aspx, or .jsp file in the web root that does not correspond to a deployment is a strong indicator. Watch for files with recent timestamps that do not match the rest of the directory, oversized or obfuscated scripts, and known web shell signatures from tools like the NSA and ASD's open-source detection rules.

Behavioral detection

The strongest signal is process lineage. A web server process such as w3wp.exe, httpd, or nginx has no legitimate reason to spawn cmd.exe, powershell.exe, /bin/sh, or whoami. When it does, a web shell is almost always the cause. Endpoint detection and response tooling that tracks parent-child process relationships catches this even when the file itself evades signature scanning.

Network and log detection

Review web server access logs for requests to unusual filenames, requests carrying command-like parameters, and POST requests to scripts that normally only serve GET traffic. A single IP address repeatedly hitting one obscure script is worth a look. Outbound connections initiated by the web server to unfamiliar destinations also warrant investigation.

How to Prevent Web Shells

Prevention works in two layers: stop the upload, and limit the damage if one lands.

• Patch and harden the web application. Most web shells arrive through a known vulnerability in the app, a plugin, or the server software. Timely patching closes the door ProxyLogon-style attacks walk through.
• Validate and restrict file uploads. Enforce allow-lists for file types, store uploads outside the web root, and never let the server execute files from upload directories.
• Apply least privilege. Run the web server under a low-privilege account, restrict write access to web directories, and segment the server from sensitive internal systems so a foothold does not become a pivot.
• Disable dangerous functions. Turn off interpreter functions a web shell depends on, such as PHP's eval(), system(), and exec(), where the application does not need them.
• Deploy a web application firewall. A WAF blocks many upload and injection attempts and can flag requests that carry command payloads.
• Monitor continuously. File integrity monitoring plus behavioral detection on the server turns a silent backdoor into a generated alert.

No single control is sufficient. ProxyLogon showed that a patch gap plus a privileged web service plus weak file monitoring is all an attacker needs. Closing any one of those gaps would have raised the cost.

Frequently Asked Questions

What is a web shell in cybersecurity?

A web shell is a malicious script, usually written in PHP, ASP.NET, JSP, or Perl, that an attacker uploads to a web server to run commands on it remotely over HTTP. It functions as a backdoor that gives persistent control of the server and a launch point into the rest of the network.

Is a web shell malware?

Yes. A web shell is a form of malware classified by MITRE ATT&CK as technique T1505.003 under the Persistence tactic. It is malicious code placed on a system without authorization to give an attacker remote control, which is the defining characteristic of malware.

How do web shells get installed?

Web shells are installed by exploiting a weakness that lets an attacker write a file to the web server: unrestricted file upload forms, vulnerable plugins, SQL injection, directory traversal, or a remote code execution flaw. The attacker places the script in a web-accessible directory and then runs it through ordinary web requests.

How do you detect a web shell?

Detection combines file integrity monitoring for unexpected scripts in the web root, behavioral detection for web server processes spawning command interpreters like cmd.exe or /bin/sh, and log review for unusual requests with command-like parameters. Behavioral process-lineage detection is the most reliable because web shells are built to evade file scanning.

What is the China Chopper web shell?

China Chopper is a compact web shell, about 4 kilobytes, with a graphical client and a small server-side component. It was used heavily by the HAFNIUM group during the 2021 Microsoft Exchange ProxyLogon campaign to backdoor compromised servers.

Can a web application firewall stop web shells?

A web application firewall helps but is not sufficient on its own. A WAF can block many upload and injection attempts and flag requests carrying command payloads, but determined attackers bypass WAF rules. It works as one layer alongside patching, least privilege, and server-side detection.