Is a web shell malware?

Functionally, yes. A web shell is a script or compiled module placed on a web server that lets a remote party run commands or manipulate files through ordinary HTTP requests. Legitimate administration tools with the same capability exist, which is why context (who planted it, where, and how it is used) matters.

Which MITRE ATT&CK technique covers web shells?

Server Software Component: Web Shell, technique T1505.003, under the Persistence tactic. Web shells frequently also enable Execution, Discovery, Credential Access and Lateral Movement techniques.

Can antivirus reliably find web shells?

Not on its own. Web shells are small, trivially modified text files, and many are obfuscated or embedded inside legitimate pages. Layered detection — file integrity monitoring, web log analysis and process-tree telemetry — is far more reliable than signatures alone.

What is a web shell? A defender's primer

A web shell is a piece of code that an attacker places on a web-accessible server so that ordinary HTTP(S) requests can be turned into actions on that server: running operating-system commands, reading and writing files, querying databases, or relaying traffic deeper into the network. It is written in whatever language the server already executes — PHP, ASP.NET (ASPX/ASHX), classic ASP, JSP, Python, Node.js — so it needs no extra runtime and blends in with the application around it.

For defenders, the important point is not how to write one, but what it changes on a system and what traces it leaves. This primer builds the mental model the rest of this site relies on.

Why attackers like web shells

Web shells persist because they solve several attacker problems at once:

Attacker goal	How a web shell helps	What it means for defenders
Persistence	Survives reboots and credential resets; lives as a file or module	Password resets alone do not evict the intruder
Stealth	Traffic looks like normal HTTPS to a public web server	Network perimeter controls rarely block it
Low footprint	Can be a few hundred bytes of text	Easy to miss in a large webroot
Privilege	Runs as the web server or application-pool identity	Often `SYSTEM`, `NETWORK SERVICE` or a service account with broad rights
Pivoting	Many variants proxy or tunnel traffic	The server becomes a beachhead into internal networks

MITRE ATT&CK tracks this as T1505.003 — Server Software Component: Web Shell. Government advisories — notably the joint NSA and Australian Signals Directorate guidance Detect and Prevent Web Shell Malware (2020) — have repeatedly flagged web shells as one of the most common persistence mechanisms on internet-facing servers.

Where web shells live in the attack lifecycle

A web shell is almost never the first thing an attacker does. It is the thing they do immediately after gaining the ability to write a file or execute code on a server:

Initial access — exploitation of a vulnerable application or appliance, abuse of an upload feature, stolen admin credentials for a CMS, or a compromised third-party component.
Web shell deployment — a file is written into a directory the web server will execute, or a module is registered with the server.
Hands-on activity — reconnaissance (whoami, ipconfig, net group), credential theft, staging tools, data access.
Expansion — lateral movement, additional web shells as backups, sometimes ransomware or data theft.

Because step 2 is the pivot between "a bug exists" and "an intruder is operating", web shells are among the highest-value artifacts an incident responder can find. The shell's creation time anchors the timeline; its access logs reveal the attacker's IPs and cadence; its process children reveal what they did.

A defender's classification

Rather than cataloguing families, it helps to classify web shells by the properties that change how you detect them.

By form factor

Form factor	Description	Primary detection surface
Standalone script	A new file such as `.php`, `.aspx`, `.jsp` in the webroot	File integrity monitoring, file creation events
Injected code	Malicious lines appended to a legitimate page or include file	Content diffing against a known-good baseline
Configuration abuse	Handlers or directives changed so a harmless-looking extension executes	Config monitoring (`web.config`, `.htaccess`, server conf)
Server module	Native IIS module, Apache/nginx module, or Java filter/servlet	Loaded-module inventory, memory analysis
Memory-resident	Code injected into the running application (e.g. Java or .NET in-memory implants) with no file on disk	Process telemetry, memory forensics, anomalous request handling

By capability

Command runners execute OS commands and return output.
File managers browse, upload, download and timestomp files.
Database clients connect to back-end databases using credentials found in config files.
Proxies and tunnels relay TCP traffic through HTTP to reach internal hosts.
Loaders and stagers are tiny "one-liners" that evaluate code sent in each request. They carry no visible functionality at rest, which makes them hard to spot by reading the file — the logic arrives with the traffic.

The last category is why reading the source is not enough. A two-line file that evaluates request data can be as dangerous as a full-featured panel.

By interaction style

Interactive panels render an HTML interface; requests often use GET for the panel and POST for actions.
Client-driven shells expect a dedicated client that sends encoded or encrypted payloads, typically via POST bodies, cookies or custom headers. Publicly reported families like China Chopper popularised this model.
Password- or key-gated shells ignore requests that lack a secret parameter and return a normal-looking page or a 404 otherwise, frustrating simple scanners.

What a web shell changes on a system

Every web shell, regardless of family, leaves evidence in some combination of the following places. The detection guides on this site are organised around them.

Evidence layer	Typical trace	Guide
File system	New or modified executable file in a web-served path; odd timestamps	File integrity detection
Web server logs	Requests to a rarely-used URL, often `POST`, from few source IPs	Log analysis
Process telemetry	`w3wp.exe`, `httpd`, `php-fpm` or `java` spawning shells and recon tools	Process-tree detection
Network	Outbound connections from the web server; internal scanning	Firewall and NDR logs
Memory	Injected assemblies, filters or modules without a backing file	Memory forensics

Common misconceptions

"We'd notice a new file." In a webroot with thousands of files, a new error_log.php or aspnet_client/*.aspx does not stand out without automation. Attackers deliberately pick names that look like part of the product.

"Our WAF blocks web shells." A WAF can block some exploitation and some known shell traffic patterns, but encrypted or custom-encoded shell traffic over TLS to an already-planted file will often pass. WAFs are a layer, not a guarantee — see eradication and hardening.

"We patched, so we're safe." Patching closes the door the attacker used; it does nothing to a web shell already planted. The large-scale Exchange compromises of 2021 showed thousands of servers that were patched after shells had been dropped and remained backdoored. See notable incidents.

"Deleting the file ends the incident." The shell is a symptom. Attackers who used it may have harvested credentials, created accounts, planted additional shells, or moved laterally. Eradication must be scoped by investigation — see the forensic investigation guide.

Legitimate look-alikes

Defenders must also recognise tools that behave like web shells but are authorised: hosting control panels, database admin interfaces, remote-management agents with web consoles, and diagnostic pages left by developers. These are both a false-positive source and a real risk — an unauthenticated admin tool left in production is functionally an open web shell. Inventory them, restrict them to management networks, and require strong authentication.

Key takeaways

A web shell turns HTTP requests into server-side actions and is ATT&CK technique T1505.003.
It is a post-exploitation artifact: find it and you have found proof of compromise and a timeline anchor.
Classify by form factor and interaction style to choose the right detection surface.
No single control is enough; combine file, log, process and memory visibility.

Continue with how web shells get planted to understand the vulnerability classes that lead to deployment.