What are Web Shell Attacks? How to Protect Your Web Servers

During a web shell attack, a cybercriminal injects a malicious file into a target web server's directory and then executes that file from their web browser.

After launching a successful web shell attack, cybercriminals could gain access to sensitive resources, recruit the target system into a botnet, or create pathways for malware or ransomware injections.

If you haven't implemented defense strategies against this cyber threat, your systems are at a high risk of exploitation. According to Microsoft, monthly web shell attacks have doubled in just the past year.

Web shell encounters on servers - Source: Microsoft.com
Web shell encounters on servers - Source: Microsoft.com

What is a Web Shell?

A web shell is a malicious script written in any of the popular web application languages - PHP, JSP, or ASP. They are installed on a web server operating system to facilitate remote administration.

When weaponized, a web shell could allow threat actors to modify files and even access the root directory of the targeted webs server.

Both internet-facing and non-internet-facing servers (such as resource hosting servers) could fall victim to web shell attacks.

Web shell attacks are a convenient cyber attack tactic because their execution doesn't require additional programs. A communication channel can be simply achieved through the HTTP protocol in web browsers - this is why it's so important to preference HTTPS protocols.

How Do Web Shell Attacks Work?

Cyber attackers first locate servers with exposures that are vulnerable to web shell attacks through scanning software, such as Shodan.io.

Shodan surfaces all internet-connected devices, including web servers and endpoints, that could serve as attack vectors to hidden web servers.

Once a vulnerability is discovered, cyberattackers immediately launch a web shell attack before a patch for the exposure is installed.

The exploitation of vulnerability CVE-2020-5902 is an example of how fast cybercriminals take advantage of exposures that facilitate web shell injections.

On June 30, 2020, F5 Networks released a patch for its Traffic Management User Interface (TMUI). The vulnerability facilitated Remote Code Execution (RCE) - a type of cyber attack involving the remote injection of malicious codes into a targeted system.

After publishing the vulnerability on June 30, on July 4 (just four days later), an exploit code being used to abuse the exposure was discovered.

 CVE-2020-5902 exploit code - Source: Microsoft.com
CVE-2020-5902 exploit code - Source: Microsoft.com

The first stage of a server infection is to penetrate the outer layer of its ecosystem. This is usually achieved by pushing corrupted web shells through file upload web pages.

After this, a Local File Include (LFI) vulnerability is used to connect the web shell to a selected web application page.

There are many other web shell injection strategies including the detection and compromise of Exposed Admin Interfaces, Cross-Site Scripting (XSS), and SQL injections.

After the web shell has been installed, a backdoor is naturally established, giving cybercriminals direct remote access to the compromised web server at any time.

The efficiency of back door creation with web shells is the reason why web shell attacks are primarily used as persistence mechanisms - the establishment of a long-term malicious internal network presence.

Because of this, data breaches and ransomware injections rarely immediately follow a web shell attack. Hackers are usually just establishing an access channel for a future attack or reconnaissance mission.

Example of a Web Shell Attack

The recent major web shell attack making headlines was executed by Chinese Cybercriminal group, Hafnium, in March 2021. The web shell involved in the attack was a malware known as China Chopper that was injected via a critical vulnerability in Microsoft Exchange Servers.

What made the China Chopper web shell particularly venomous was that the backdoor it established into the infected system remained, even after the server vulnerability was patched.

How to Detect Web Shells

Web shells are difficult to detect because they can be hidden within seemingly innocuous files.

For example, a web shell script could be embedded within a photo and uploaded to the target webserver. When this upload is analyzed, nothing unusual is detected - it is, after all, just a photo.

But because web servers reference media files for server-side execution, the photo can be requested from a web browser which then activates its malicious coding.

To overcome this challenge, security controls must be implemented at the interface of internet-facing servers and the internet to analyze all script file writes and process executions.

This layer of protection can be achieved through Defender for Endpoints by Microsoft.

Another method with impressive accuracy is to compare files suspected of corruption against a database of known web shell syntax. This can be achieved with Shell Detector.

How to Block Web Shell Injections

It's much easier to address the vulnerabilities that facilitate web shell injection than it is to intercept web shell attacks.

The following suggested controls and security tools should be used to locate and remediate all possible web shell injection points in your IT ecosystem.

1. Stay Updated with the Latest Security Patches

Security vulnerabilities are the most common pathways for web shell attacks. To block these entry points, be sure to keep all web applications, Content Management Systems, web server software, and third-party software updated with the latest security patches.

Regularly refer to the Common Vulnerabilities and Exposures directory to remain informed of the latest exposures that could be impacting your software solutions.

2. Disable Unnecessarily Web Server Functions  

If a web shell is injected, its execution could be blocked if the functions that communicate with web server scripts are disabled in php.ini.

Such web server functions include:

  • exec ()
  • eval()
  • shell _exec()
  • assert()

3. Modify the Names of Sensitive Directories

To prevent the upload of corrupted images files, the directories that facilitate such uploads should ideally be completely disabled.

If such an upload mechanism is necessary, the default names of these sensitive directories should be modified to make them harder to discover. Only privileged users should have permission to access these modifications to mitigate insider threat attacks.

In addition to this, specify a filter for the permitted file types that can be uploaded to your web server.

4. Disable All Unnecessary WordPress Plugins

WordPress plugins are common attack vectors because anyone is permitted to develop them - even cybercriminals.

To secure these vectors, be sure to only install plugins from trusted developers and uninstall all unnecessary plugins.

5. Implement a Firewall

A Web Application Firewall (WAF) is designed to prevent web shells and malicious payloads from being injected into an ecosystem by filtering all network traffic.

Like antivirus software, it's important to keep your firewall updated with the latest cybersecurity patches.

6. Implement File Integrity Monitoring

A file integrity monitoring solution will compare directory updates against the timestamps of clean directory scripts. If a discrepancy is detected, the requested installation on the code directory of the targeted web server will either be blocked or activate a security alert.

7. Monitor Your Attack Surface

An attack surface monitoring solution completes vulnerability scans of the entire attack surface - both internally and throughout the vendor network. This allows security teams to remediate exposure before they're discovered and exploited by cyber attackers.

Ready to see
UpGuard in action?

Ready to save time and streamline your trust management process?