PHP web shell: what it is and how to defend your own server against one

A web shell is a single file that turns your server into a server somebody else controls. It is not a break-in to the operating system or anything exotic — it is an ordinary script that poses as part of your application and quietly listens for commands from outside.

This article explains what it is and how to protect against it. It deliberately contains no code for such a script and no guidance on how to alter one or hide it from a scanner — that would be a manual for an attacker. We are interested in the other side: how to keep such a file from reaching you, and how to spot it quickly if it does.

What a PHP web shell is

PHP is the language much of the web runs on — from content systems to online shops. The server treats PHP files as instructions to execute: when a browser sends a request, the server runs the file and returns the result. That is entirely normal, and it is how every PHP page works.

A web shell abuses that behaviour. It is a PHP file that is not part of your application — somebody else smuggled it in — and its only job is to take a command from the internet and let the server carry it out. The upshot is that the attacker has what they would have if they sat at your server: they see the files, read the database, download data, add more scripts.

Why "shell": in IT a shell is the interface through which a person gives a computer commands. A web shell is exactly that, only reachable through a web address — and reachable by anyone who knows that address.

It tends to look unremarkable. It can be a file with a name that resembles the rest of the system, sitting among hundreds of legitimate files. That is precisely what makes it dangerous: nothing crashes, nothing breaks, the site keeps running perfectly normally.

What it can do, and how it gets onto a server at all

The impact and the way in are two different things, and both are worth knowing for the defence to make sense.

What an attacker can do with it

Once a web shell is running, the limit is whatever the user the website runs as can reach. In practice that is usually enough to read and change the application's files, get at the database credentials kept in configuration, download customers' personal data, send spam from your server, or install further code that redirects visitors or mines cryptocurrency. The server keeps working on the surface — which is exactly the point.

How it gets there

It does not appear from nowhere. Almost always it comes through one of a handful of ordinary doors:

• File upload that trusts what it receives. A form for uploading a photo that in fact accepts and stores a PHP file too is the most common route. The problem is not the uploading, but that the uploaded file can then be executed.
• An old dependency with a known vulnerability. An un-updated plugin, library or version of a system for which a publicly known way to slip a file through already exists.
• Stolen or weak credentials. A leaked password to the admin area, to FTP or to a management console — the attacker then simply uploads the file as an "authorised" user.
• A shared server with a weak neighbour. On cheap hosting where many sites run side by side, a break-in to someone else's site can open a path to yours as well.

What these share is that none of them is an attack on PHP as such. They are ordinary operational lapses — which is exactly why they can be closed off in advance.

Why nobody knows for a long time

A web shell makes no noise. The site does not go down, customers notice nothing, ordinary reports show no change. Until somebody deliberately looks for a file that does not belong, or notices unusual activity, the shell can wait for months. That is why a defence cannot rest on "we would have noticed".

How we defend against it, and how we help you

A web shell is not a problem you solve with one antivirus at the end. You solve it with decisions made during design — the same ones security by design is about — and then by the server being able to say when something has changed.

When building a solution, that means a few concrete things. Uploaded files are stored outside the space the server executes anything from, so even a smuggled PHP file has no way to come to life. We check what is allowed to arrive against a list of what is permitted, not against the extension in the name. The website runs with the least permissions it needs, separated from other projects, so that a break-in has nowhere to spread. And dependencies are kept current, because most of the ways in lead through something a fix has long existed for.

The other half is visibility. We watch file integrity — the server knows which files belong to the application, so a new one that has no business being there can be caught, rather than only once it has done damage. Sensitive operations and access go to a separate audit trail that cannot be rewritten from inside the application.

And when something is found, the order is fixed: first stop the damage and preserve the evidence, then rotate every credential that could have got out, only then clean up — and finally close the door it came through, so it does not happen again.

If you are taking over a system from somebody else, running a site where a data leak would hurt, or merely suspect there is something on the server that does not belong, get in touch — we will go through it and tell you where you stand. There is more about this area on our services page.