Web shells are malicious scripts that grant attackers persistent access to compromised web servers, enabling them to execute commands and control the server remotely. These scripts often exploit vulnerabilities like SQL injection, remote file inclusion (RFI), and other kind of flaws to gain entry.
Once deployed, web shells allow attackers to manipulate the server, leading to data theft, website defacement, or using the server as a launchpad for further attacks. Given their stealth and versatility across various programming languages (PHP, Python, Ruby, ASP), web shells pose a significant threat to a website’s security.
Understanding Web Shells
A web shell is a malicious script or piece of code that an attacker uploads to a compromised web server to facilitate remote control. This backdoor access allows attackers to run server commands, modify files, and access databases, providing them with unauthorized control over the server.
It is important to mention that any technology, due to bad coding practices, is prone to allowing attackers to upload web shells. For that reason, we recommend our services to help avoid these kinds of harmful situations caused by malicious actors.
How does a web shell end up on my website or server?
There are multiple ways for attackers to upload these kinds of backdoors to a server. The most common method is when an attacker finds a vulnerability that allows them to execute code, upload files, or somehow gain unauthorized access to the web server. Attackers can exploit various types of vulnerabilities, with one of the most frequent being:
- Remote Code Execution: This vulnerability allows an attacker to directly interact with the server. It can occur due to outdated libraries or poor coding practices that enable the execution of malicious code.
Attackers upload these backdoors to maintain access and interact with the server, potentially allowing them to execute commands on the operating system through the web shell.
How do web shells work?
The main point of a web shell is to interact with the server and its files. That’s the primary goal and focus. With that in mind, here is an example of a workflow that could provide a better understanding of this:
- Identification of Vulnerability:
- The attacker identifies vulnerabilities in the target website or server, such as SQL injection, remote file inclusion, file upload, etc.
- Exploitation:
- By exploiting the identified vulnerability, he gets unauthorized access to the server. It may result in the execution of malicious code, uploading of files, or even manipulation in server configuration.
- Uploading the Web Shell:
- Using the gained access, the attacker uploads the web shell script to the server. Normally, this script will be hidden as some other legit file.
- Establishing Remote Access:
- The web shell serves as a backdoor that allows an attacker to remotely execute commands, manipulate files, and access databases on the server.
The attacker sends commands through the web shell issued to the server, which might include data exfiltration, manipulation of the server, or further attacks from the already compromised server.
Types of webshell
There are several types of web shells, but the most well-known are C99, WSO, and b374k. Here are some screenshot examples of them:
Nowadays, these kinds of web shells are mostly used for exfiltration or pivoting purposes. However, some years ago, defacement was popular, allowing attackers to change the main page and display any message. Mirrors of these defacements can be found on popular websites like Zone-H.
When a team or hacktivists hacked a site, they often saved the defacement on Zone-H to gain reputation and ensure the hack wasn’t forgotten. Even after several years, some attackers still use web shells to modify the index.html.
How to detect them?
The approach should be proactive, not reactive. Instead of waiting for an attacker to hack the web server, actions such as penetration testing, source code analysis, and hardening of web servers should be taken to prevent these kinds of situations. If a web shell is detected on a web server, the best course of action is to thoroughly check the entire server for any anomalies, such as unusual services or filenames. If you use repositories or version control systems like Git, you can compare each file to identify any changes.
Remember that we have skilled professionals who can help you detect threats in your software, allowing you to avoid these headache-inducing situations.