Web Shell

A web shell is one of the simplest yet most dangerous tools in an attacker's kit. After breaking into a web application, an attacker drops a small script into a directory the web server will execute, and from that moment on the public website doubles as a private command console. Every instruction travels as an ordinary web request, so the server keeps serving pages to real users while quietly running the attacker's commands in the background. That blend of persistence and stealth is why web shells appear in so many breach reports.

How a Web Shell Works

A web shell is just code the server is willing to run. An attacker first needs a way to place that code on disk, which usually comes from an exploit against the application or its stack: an unrestricted file upload, a SQL injection that writes a file, a vulnerable plugin, or unpatched server software. Once the script sits in a web-accessible folder, the attacker visits its URL and passes commands through parameters, headers, or the request body.

From there the server becomes a foothold. The attacker can read files, harvest credentials, and pivot toward internal systems, all while traffic looks like normal web activity. Because the script lives on the server rather than in a single session, access survives reboots and even some cleanup attempts, which is exactly what makes it valuable.

Why It Maps to MITRE ATT&CK T1505.003

Mapping a real intrusion to T1505.003 gives defenders a shared language. It lets a SOC compare its detections against published threat intelligence, line up indicators with other organizations, and reason about what the attacker is likely to do next.

This technique is also getting easier to deploy at scale. In Anthropic's data, web shell deployment (T1505.003) was 3 to 5 times more common among the highest-risk AI-enabled actors than among ordinary intrusions, a pattern explored in our look at how hackers use AI. When tooling lowers the effort to weaponize a foothold, the foothold itself shows up far more often.

Detecting and Removing Web Shells

Exploit Web App

→upload

Plant Web Shell

→access

Run Commands and Pivot

→detect

Hunt, Contain, Remediate

Detection leans on a few reinforcing signals:

• File integrity monitoring that flags new or modified scripts in upload and web-root directories.
• Web server log analysis for unfamiliar URLs, odd user-agents, or requests carrying command-like parameters.
• Threat hunting for the behavioral traces a web shell leaves once it starts executing commands.

The web shell endures because it is cheap to deploy and quiet to operate. Defenders win not by chasing individual scripts, but by shrinking the exposure that lets them land and by watching for the behavior they cannot hide once they run.