Other commands may of course be run, which allows attackers to read files, navigate the file system, start processes, and possibly other things, all with the privilege level of the web server process.

While the above example is perhaps the most minimal web shell that the author could think of, there are quite sophisticated ones available from many sources. Kali Linux, a popular penetration testing distribution, provides fourteen different examples, written in the PHP, perl, jsp, cfm, aspx, and asp languages. A quick search of Github showed 1,808 repositories that contain the words “web shell” somewhere in their description or title. Any reasonably competent programmer in a web language would be able to code their own without too much effort.

Web Shell Capabilities

Of the 14 web shells packaged with Kali Linux, which we can take as a somewhat representative example, the following capabilities were present.

• Command execution on both Windows and Linux platforms
• File upload
• File download
• Archive creation and download
• Database query execution
• Database table dumping
• Executing code to create a network connection back to an attacker-controlled machine (a “reverse shell”)

This list, however, is by no means comprehensive. An attacker with knowledge of the target system and a specific agenda would likely customize their web shell towards those ends, with their capabilities limited only by their skill, the commands available to them on the target, and the permissions of the web server process.

Attacker Advantages and Disadvantages

Why would an attacker use a web shell? First and foremost, not every vulnerability is a one-shot, Remote Code Execution (RCE) vulnerability. Frequently, a successful attack involves leveraging several vulnerabilities to achieve the desired outcome.

In the case of web shells, they are frequently used to go from a Local File Inclusion (LFI) vulnerability to having the ability to run commands on the system. From there, depending on attacker objectives, further reconnaissance can be done, or further exploits deployed to elevate privileges, pivot, and maintain persistence.

Additionally, web shell traffic appears to be legitimate website traffic; a client requests a URL, and a response is returned. Further, as most sites now run HTTPS/TLS, this traffic is also encrypted. Finally, HTTP is by far the most used protocol, and any site with a lot of traffic will have many thousands of requests per second that would need to be inspected to detect malicious activity. These facts, taken together, mean that unless a defender is carefully inspecting the URL requested, the contents of the request and response, and the presence of malicious files in their web application directories, there’s a good chance attacker activity will go unnoticed.

Finally, a capable web shell can be constructed from the many examples available by attackers with limited skills, and can be just as effective as more difficult, high-end techniques like custom shellcode and sophisticated malware.

The disadvantages are few, but not to be discounted entirely. Antivirus and IDS vendors do inspect traffic and files and have signatures that can match commonly encountered web shells. It is relatively easy to detect if new files have been placed in web directories. Even so, with a modicumof effort, web shells can be changed and obfuscated to avoid signature-based detection, and in many cases, web directory changes are monitored for only periodically, giving the attacker a window of opportunity before detection occurs.

Detection and Defenses

As we have already mentioned above, the main line of defense is detecting suspicious web traffic, URL parameters, and suspicious URLs. Directory content monitoring is also a good approach, and some programs exist which can detect changes to monitored directories immediately and roll back changes automatically.

Additionally, some defensive tools allow for the detection of anomalous process creation.; In this case, the invocation of a shell by a webserver would be caught and alerted on. More sophisticated approaches involve the explicit allow-listing of subprocesses and blocking of any that don’t match that list. These approaches are an excellent solution if, for some reason, your webserver needs to spawn subprocesses. However, it should be noted that for a skilled programmer in a web language, there’s very little that can’t be accomplished using the language’s common features, without having to execute system commands.

Conclusion

Despite their simplicity, web shells are a common way for attackers to gain the ability to run commands on a server and avoid detection by hiding in the “noise” of normal web traffic. They are very customizable and flexible tools requiring modest technical skills. For a targeted organization, they can be devastating, leading to data exfiltration, installation of malware, and further reconnaissance of their environment by attackers.

We recommend that companies running dynamic websites use all the tools at their disposal to detect and mitigate web shells, paying special attention to the contents of storage accessible by their webservers. Secure coding practices which aim to eliminate an attacker’s ability to upload malicious content are an absolute requirement, addressing as they do the most common means by which attackers install web shells in the first place. In-depth monitoring of webserver process creation, as well as requested URLs and parameters, and even the content delivered by the webserver to client, are all excellent methods of detection.