An Introduction to Web-shells – Part 1


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.

Why Use Web-shells?

Persistent Remote Access

A web-shell usually contains a backdoor which allows an attacker to remotely access and possibly, control a server at any time. This would save the attacker the inconvenience of having to exploit a vulnerability each time access to the compromised server is required.

An attacker might also choose to fix the vulnerability themselves, in order to ensure that no one else will exploit that vulnerability. This way the attacker can keep a low-profile and avoid any interaction with an administrator, while still obtaining the same result.

It is also worth mentioning that several popular web shells use password authentication and other techniques to ensure that only the attacker uploading the web-shell has access to it. Such techniques include locking down the script to a specific custom HTTP header, specific cookie values, specific IP addresses, or a combination of these techniques. Most web shells also contain code to identify and block search engines from listing the shell and, as a consequence, blacklisting the domain or server the web application is hosted on – in other words, stealth is key.

Privilege Escalation

Unless a server is misconfigured, the web shell will be running under the web server’s user permissions, which are (or, at least, should be) limited. Using a web-shell, an attacker can attempt to perform privilege escalation attacks by exploiting local vulnerabilities on the system in order to assume root privileges, which, in Linux and other UNIX-based operating systems is the ‘super-user’.

With access to the root account, the attacker can essentially do anything on the system including installing software, changing permissions, adding and removing users, stealing passwords, reading emails and more.

Pivoting and Launching Attacks

A web-shell can be used for pivoting inside or outside a network. The attacker might want to monitor (sniff) the network traffic on the system, scan the internal network to discover live hosts, and enumerate firewalls and routers within the network.

This process can take days, even months, predominantly because an attacker typically seeks to keep a low profile, and draw the least amount of attention possible. Once an attacker has persistent access, they can patiently make their moves.

The compromised system can also be used to attack or scan targets that reside outside the network. This adds an additional layer of “anonymity” to the attacker since they are using a 3rd party system to launch an attack. A step further would be to pivot (tunnel) through multiple systems to make it almost impossible to trace an attack back to its source.


Another use of web-shells is to make servers part of a botnet. A botnet is a network of compromised systems that an attacker would control, either to use themselves, or to lease to other criminals. The web-shell or backdoor is connected to a command and control (C&C) server from which it can take commands on what instructions to execute.

This setup is commonly used in distributed-denial-of-service (DDoS) attacks, which require expansive amounts of bandwidth. In this case, the attacker does not have any interest in harming, or stealing anything off-of the system upon which the web shell was deployed. Instead, they will simply use its resources for whenever is needed.


Part 3

Keeping web-shells under cover

Part 4

Web-shells in action

Part 5

Detection & Prevention

Share this post

Leave a Reply

Your email address will not be published.