What Is a Web Shell?
Web shells are malicious scripts that enable threat actors to compromise web servers and launch additional attacks. Threat actors first penetrate a system or network and then install a web shell. From this point onwards, they use it as a permanent backdoor into the targeted web applications and any connected systems.
How Are Web Shells Used by Attackers?
Threat actors use web shells for a range of scenarios:
- Exfiltrating and harvesting sensitive information and credentials.
- Uploading malware, which can potentially create a watering hole for further infection and scanning of other victims.
- Defacing websites by modifying or adding files.
A web shell can serve as a relay point for issuing commands to hosts located inside the network, without direct Internet access. Web shells can also participate in a command-and-control infrastructure—for example, a web shell can be used to compromise a host and enlist it into a botnet. Attackers can infect other systems on the network with the web shell, in order to compromise additional resources.
Threat actors use a wide range of web application vulnerabilities and exploits to deliver web shells, including SQL injection (SQLi) and cross-site scripting (XSS). Actors also exploit vulnerabilities in services and applications, file processing vulnerabilities, exposed admin interfaces, as well as local file inclusion (LFI) and remote file inclusion (RFI) vulnerabilities.
Web Shell Attacks on the Rise
Microsoft has identified an increase in web shell attacks by various groups, affecting both private and public organizations. These include advanced persistent threat (APT) teams using web shells to gain a foothold into the target networks.
One such attack, discovered by Microsoft’s detection and response team, involved web shells installed in multiple folders on an organization’s misconfigured server, allowing the attacker to move laterally and install web shells on further systems. A DLL backdoor registered as a service allowed the attacker to persist on the email server, download malware payloads and send commands in the form of emails.
If a web shell is successfully implanted into a web server, it enables a remote attacker to execute malicious commands and steal data. Hacker groups that have used web shells in their attacks include the Gallium group and the Lazarus group.
How Web Shells Work
Web shell attacks have several stages: first, the attacker creates a persistent mechanism on the server enabling remote access. Then, they attempt to escalate privileges, and leverage the backdoor to attack the organization, or use its resources for criminal activity.
How a web shell attack works
1. Persistent Remote Access
Web shell scripts provide a backdoor allowing attackers to remotely access an exposed server. Persistent attackers don’t have to exploit a new vulnerability for each malicious activity. Some attackers even fix the vulnerability they exploit to prevent others from doing the same and avoid detection.
Some web shells use techniques such as password authentication to ensure that only specific attackers can access them. Web shells usually obfuscate themselves, including code that prevents search engines from blacklisting the website where the shell is installed.
2. Privilege Escalation
Web shells normally run with user permissions, which can be limited. Attackers can escalate privileges through web shells by exploiting system vulnerabilities to acquire root privileges. Root account access allows attackers to perform almost any action—they can install software, change permissions, add or remove users, read emails, steal passwords, etc.
3. Pivoting and Launching Attacks
Attackers can use web shells to pivot to additional targets both in and out of the network. The process of sniffing network traffic to identify live hosts, firewalls, or routers (enumeration) can take weeks, during which attackers will keep a low profile to avoid detection.
An attacker that successfully persists on a network will move patiently, possibly even using a compromised system to attack other targets. This allows the attacker to remain anonymous, and pivoting through several systems can make it virtually impossible to trace attacks to the source.
4. Bot Herding
Web shells can be used to connect servers to a botnet (a network of systems controlled by the attacker). The affected servers execute commands sent by attackers through a command and control server connected to the web shell.
This is a common technique for DDoS attacks that require extensive bandwidth. Attackers aren’t directly targeting the system where they’ve installed the web shell, but are simply exploiting it for its resources to attack more valuable targets.
Web Shell Protection
Here are a few ways to protect your organization against the threat of web shells.
File Integrity Monitoring
File integrity monitoring (FIM) solutions are designed to block file changes on web-accessible directories. Once a change is detected, FIM tools alert admins and security staff. Implementing FIM can help detect issues in real-time, as soon as files are saved to a directory. This can help security staff quickly find and remove web shells.
Integrity monitoring solutions can be customized to allow certain file changes while blocking others. If, for example, your web application typically handles only portable document format (PDF) files, the integrity monitoring solution can block uploads that do not end with the “.pdf” extension.
Web Application Permissions
When defining permissions for web applications, it is important to employ the least privilege concept. The main principle behind this concept is to provide users with the bare minimum of privileges required to perform their role. The goal is to ensure that each user does not have privileges they should not have and that compromised accounts are restricted in their actions.
The least privilege principle can help prevent threat actors from uploading a web shell to vulnerable applications. You can set it by not enabling web applications to directly write to a web-accessible directory or modify web-accessible code. This way, the server blocks the actor from accessing the web-accessible directory.
Intrusion Prevention and Web Application Firewalls
An intrusion prevention system (IPS) is a network security technology designed to protect IT assets and environments against threats, by monitoring the flow of network traffic. Web application firewalls (WAF) protect against threats by filtering, monitoring, and blocking HTTP traffic flowing to and from web services.
Organizations should employ several technologies when implementing intrusion prevention. When used together, IPS and WAF solutions can each monitor the flow of traffic and block known malicious uploads. Ideally, each security appliance introduced into the ecosystem should be tailored to the specific needs of the organization.
Network Segmentation
Network segmentation is a type of architecture that splits the network into separated subnetworks. Each subnetwork is considered a segment, and each segment has its own secured network. A network segregation architecture prevents connections between unrelated segments. This separation can help prevent web shell propagation.
There is a wide range of network segregation techniques. Isolating a demilitarized zone (DMZ) subnet, for example, is a basic technique that can quarantine internet-facing servers. There are also more advanced network segregation techniques, such as software-defined networking (SDN), which can help implement a zero-trust architecture.
A zero trust architecture requires explicit authorization before allowing communication between nodes within a network. This type of technique can prevent threat actors from chaining web shells in order to reach deeper into the network. In this scenario, web shells can still affect the targeted server, but attackers are blocked from moving laterally further into the network.
Endpoint Detection and Response (EDR)
Certain endpoint detection and response (EDR) and host logging solutions can help protect against web shell attacks. These solutions monitor system calls and process lineage abnormalities and use patterns of malicious behavior to detect web shells.
EDR solutions with web shell protection capabilities can monitor all processes on endpoints, including invoked system calls. When web shells cause abnormal behavior within a web server process, the solution recognizes it. For example, the majority of web servers do not usually launch the ipconfig utility. This is a common reconnaissance technique prompted by web shells, which can be recognized via behavioral analysis.
Imperva Web Shell Protection
Imperva prevents web shells and other threats that communicate with C&C servers, via its industry-leading Web Application Firewall, which prevents attacks with world-class analysis of web traffic to your applications.
Beyond the WAF, Imperva provides comprehensive protection for applications, APIs, and microservices:
Runtime Application Self-Protection (RASP) – Real-time attack detection and prevention from your application runtime environment goes wherever your applications go. Stop external attacks and injections and reduce your vulnerability backlog.
API Security – Automated API protection ensures your API endpoints are protected as they are published, shielding your applications from exploitation.
Advanced Bot Protection – Prevent business logic attacks from all access points – websites, mobile apps, and APIs. Gain seamless visibility and control over bot traffic to stop online fraud through account takeover or competitive price scraping.
DDoS Protection – Block attack traffic at the edge to ensure business continuity with guaranteed uptime and no performance impact. Secure your on-premises or cloud-based assets – whether you’re hosted in AWS, Microsoft Azure, or Google Public Cloud.
Attack Analytics – Ensures complete visibility with machine learning and domain expertise across the application security stack to reveal patterns in the noise and detect application attacks, enabling you to isolate and prevent attack campaigns.
Client-Side Protection – Gain visibility and control over third-party JavaScript code to reduce the risk of supply chain fraud, prevent data breaches, and client-side attacks.
