Web Shell

A web shell is a small script planted on a web server that gives an attacker an ongoing, remote command interface into that machine, hidden in plain sight among the server's own legitimate files. Once it's there, the attacker doesn't need to re-exploit anything; they just request the planted file directly, and it does whatever they ask.

This is a persistence technique, not an initial-access one: it's what an attacker plants after getting in, specifically so they don't have to get in the same way twice. A vulnerability might get patched, but a web shell sitting quietly in the webroot survives that, as long as nobody notices it's there.

Once initial access is achieved, often through exploiting the application itself, an attacker writes a small script, sometimes just a handful of lines, into a location the web server will actually execute: the webroot, an uploads directory, anywhere the application serves files from. From that point on, simply requesting that file's URL gives them a command interface, no further exploitation required.

The web shell itself is often deliberately unremarkable: a filename that blends in with legitimate application files, minimal functionality, sometimes password-protected against anyone else stumbling onto it. The goal is to look like nothing worth a second glance.

Data source: a shell spawned by the web application process in process-creation telemetry, file-integrity records for a new web-root script, and command-bearing access logs

{
  "host": {
    "name": "WEB01"
  },
  "process": {
    "name": "sh",
    "parent": {
      "name": "nginx"
    },
    "command_line": "sh -c whoami"
  }
}

Prebuilt Elastic rule: Web Shell Detection: Script Process Child of Common Web Processes

Hunt the process relationship first: filter for a web server process as the parent of a shell or interpreter, which is a fundamentally unusual thing for a web server to do during normal operation. Once you find one, the access log tells you how it's being reached, look for repeated requests to that same specific file path, which is what active use of a planted shell actually looks like over time, as distinct from a one-time exploit request.

The file itself, if you can locate it, is often the most direct evidence: an unexpected file in the webroot with a creation or modification time that lines up with the suspected compromise.

Legitimate web applications and their maintenance tooling sometimes do launch scripts or shell commands as part of normal operation, deployment scripts, health checks, log rotation, and administrative tasks can all produce a web-server-parent-spawns-shell pattern that looks superficially similar.

The distinguishing signal is repetition and context: a known, scheduled maintenance task recurs predictably and runs recognizable, consistent commands. A web shell's activity tends to be irregular, tied to whenever the attacker chooses to use it, running commands that vary rather than repeating the same fixed task, and often traceable back to a specific file that has no business being part of the deployed application in the first place.

• MITRE ATT&CK T1505.003: Web Shell
• Elastic Security: Web Shell Detection

1 scenario in this catalog covers T1505.003. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →