What is a webshell? A definition for hosting operators

Ask ten people what a webshell is and you get ten answers, most of them about a hacker in a hoodie. The useful definition is much more boring, and it comes from a neutral source: a webshell is a script placed in a directory your web server serves, which turns an HTTP request into a command on your machine.

The short definition

MITRE ATT&CK catalogues web shells as a persistence technique, T1505.003 , verbatim:

Adversaries may backdoor web servers with web shells to establish persistent access to systems. A Web shell is a Web script that is placed on an openly accessible Web server to allow an adversary to access the Web server as a gateway into a network.

Two words in that sentence carry the operational weight. Persistent: the webshell is not the break-in, it is what makes the break-in survive your cleanup. And gateway: it is the interactive foothold from which everything else — spam, SEO injections, ransomware staging, pivoting to the next account — becomes convenient.

The break-in itself is a different technique, T1190 Exploit Public-Facing Application . The pair describes almost every incident on a shared web host: a vulnerable plugin gets exploited, a file gets written, and the vulnerability stops mattering because the attacker no longer needs it.

What a webshell looks like on disk

A single file, often small

Public tooling sets the expectation. The p0wny-shell project describes itself, verbatim , as

a very basic, single-file, PHP shell. It can be used to quickly execute commands on a server when pentesting a PHP application

with command history, tab completion, filesystem navigation and file upload and download — and the project’s own README warns that “THIS SCRIPT IS A SECURITY HOLE.” It is a legitimate pentest tool, and it is the shape of the thing: one file, dropped anywhere PHP executes, and the account is under someone else’s control. Derivatives of that pattern are what turn up in real incidents.

If you want to look at the family properly, bartblaze/PHP-backdoors is a CC0-licensed corpus split into obfuscated and deobfuscated samples. It is also a fair public benchmark: any detection-rate claim, ours included, should be reported against both halves rather than the easy one.

Polyglots and handler abuse

Modern droppers rarely arrive as shell.php. Two techniques recur, and both are documented in captured exploit traffic rather than in theory. The first is the polyglot: a file that starts with %PDF-1.4 or GIF89a so that a naive upload check passes, with PHP further down. The second is handler abuse: uploading an .htaccess that re-maps a harmless extension to the PHP handler, so a .txt file executes. Wordfence’s write-up of the Ninja Forms upload campaign reproduces exactly that — an .htaccess submitted as image.jpg, carrying AddType application/x-httpd-php .txt (Wordfence ).

We take those techniques apart file by file in how webshells get into WordPress uploads .

Files that load themselves

The variants that survive longest are the ones nobody looks at. WordPress mu-plugins load on every request and never appear in the plugins screen. Fake plugin directories borrow the name of something plausible. A modified core file sits in a directory administrators trust by default.

Why the backdoor, not the break-in, decides how bad it gets

Sucuri’s 2023 Hacked Website Report states it plainly, verbatim :

In 2023, 49.21% of compromised websites were discovered to contain at least one backdoor at the time of infection. Our team successfully removed 21,062 backdoors from these infected sites.

That figure is 2023 data — Sucuri has published no later edition with cleanup numbers, so it should always be quoted with its year. It still says something durable: on roughly half of the sites their team cleaned, someone had arranged to come back.

Wordfence’s 2024 Annual WordPress Security Report points the same way from a different dataset: its second most-detected malware in 2024 was “a generalized obfuscated backdoor”, found on 78,500 sites.

What actually finds them

The NSA’s own repository on mitigating web shells is unusually direct about method, verbatim :

The most effective method of discovering most web shells is to compare files on a production web server with a known-good version of that application, typically a fresh install of the application where available updates have been applied.

That is a filesystem control, not an application control — comparison against known-good, performed on the server. MITRE’s Linux detection analytic for the same technique (AN1109) names the other half:

File creation of unauthorized script (e.g., .php, .sh) in /var/www/html followed by execution of unexpected system utilities (e.g., curl, bash, nc) by apache/nginx

Note the honest detail: MITRE pairs file creation with subsequent anomalous process execution. Watching writes into the web root is one half of that analytic, and a strong half — it is the first observable event in the chain — but nobody should present it as the whole of it.

The same repository is equally direct about the cost of heuristics: rules that detect obfuscation and encoding “are likely to produce a significant number of false positive results.” Any vendor promising obfuscation detection with no false positives is contradicting the NSA. We describe how we handle that trade-off in false positives in malware scanning .

The honest limit: not everything is a file

Filesystem detection covers file-based persistence, which is most of it and the part that survives a site cleanup. It does not cover everything. Sucuri’s analysis of the Sign1 campaign describes over 39,000 sites infected over six months by an injection that lived entirely in the database — JavaScript placed in Custom HTML widgets — with no malicious code in server files at all.

A scanner that watches files would not have caught that campaign, and saying so is more useful than pretending otherwise. Database-resident injections need a different control — integrity checks on options and post content, and a second look at your admin users.

What this means for CyberPanel operators

1. Treat any .php file under wp-content/uploads/ as malicious until proven otherwise. There is no legitimate reason for one to be there.
2. Check .htaccess files for AddType, AddHandler and SetHandler lines as part of every investigation — handler abuse turns “harmless” extensions into code.
3. When you find something, quarantine it rather than deleting it; you will need the file to answer what happened. See quarantine or delete .
4. Detect at the layer where the write happens. A per-site plugin lives inside the account it is defending; the argument for moving that control below the application is set out in why server-level webshell detection .
5. If you run CyberPanel, the installation path for a host-level watcher is documented step by step in the installation docs .

Shelltrap watches writes into your customers’ web roots in real time, scores them with signatures, hash sets and heuristics, and keeps every finding explainable. See what it does .