Everything You Need To Know About Web Shells

So let’s talk about Web Shells, something many of us are already familiar with, but to level the field – what is a web shell?

A web shell is a script that can be uploaded to a web server to enable remote administration of the machine. Infected web servers can be either Internet-facing or internal to the network, where the web shell is used to pivot further to internal hosts.

We have written about various web shell implementations and tools such as:

– Weevely 3 – Weaponized PHP Web Shell
– A Collection of Web Backdoors & Shells – cmdasp cmdjsp jsp-reverse php-backdoor
– InsomniaShell – ASP.NET Reverse Shell Or Bind Shell

And various other mentions here and there.

Now, Acunetix has come out with a great, really comprehensive 5 part article about web shells which covers:

Which covers pretty much everything apart from the really advanced stuff, an introduction and then obviously PHP as it’s still the most widespread language for commonly installed CMS packages (WordPress, Joomla, Drupal etc), then hiding your web shells, what you can do with web shells and finishing with detecting and preventing the installation of web shells.

A web-shell is a malicious script used by an attacker with the intent to escalate and maintain persistent access on an already compromised web application. A web-shell itself cannot attack or exploit a remote vulnerability, so it is always the second step of an attack (this stage is also referred to as post-exploitation).

An attacker can take advantage of common vulnerabilities such as SQL injection, remote file inclusion (RFI), FTP, or even use cross-site scripting (XSS) as part of a social engineering attack in order to upload the malicious script. The common functionality includes but is not limited to shell command execution, code execution, database enumeration and file management.

From – Part 1

And the series to conclude:

As we have seen, coding and using a web-shell is not difficult. Unfortunately, many web servers are setup in such a way where even a simple script is enough to cause significant damage. This is the main reason as to why there are thousands of publicly available web-shells. The fact that so many variations exist, make it difficult for intrusion detection and intrusion prevention systems (IDS/IPS) to detect them; especially if they are using signatures to detect such web shells. Some web-shells are very sophisticated and they are almost impossible to be detected, even with behavioral analysis.

Having said this, early on in this article series, we had established that web-shells are post-exploitation tools. This means that the best way to prevent exploitation, is to prevent them from being uploaded in the first place.

From – Part 5

My best tip, if you’re a WordPress user to prevent the usage of PHP based exploits and/or web shell is to add this to your nginx config file:

    # Deny access to PHP files in any /uploads/ or /cache/ directories
    location ~ /uploads/(.+)\.php$ { access_log off; log_not_found off; deny all; }
    location ~ /cache/(.+)\.php$ { access_log off; log_not_found off; deny all; }

# Deny access to PHP files in any /uploads/ or /cache/ directories