Web shell attacks have doubled over the last 6 months according to Microsoft’s Detection And Response Team.  But, what are Web Shell Attacks and how can you defend against them?

In a recent blog post, Microsoft’s DART detailed the rise in Web Shell Attacks that have been uncovered in Windows Defender telemetry- growing from an average 77,000 detections per month to over 140,000 in January 2021.

What is a Web Shell?

Most Web Servers execute server-side code which is processed (interpreted) at runtime when the URL that points to that code is requested by a client’s web browser.  This includes PHP, JSP and ASP based webservers, for example. Rather than there being a monolithic software application that responds to every client request, there is usually one code file that is ‘executed’ in response to each different URL requested by the client.

For example: When the client’s browser requests a URL, such as: www.mysite.com/myapp/welcome the webserver interprets/executes the code in the file ‘welcome’ and returns the response generated by the code to the client browser.  In other words, each time a URL is requested from the webserver you could consider the browsers request as simply an instruction to ‘execute this file on the server.’

A web shell attack happens when a malicious user is able to inject their own file into the web server’s directory so they can later instruct the webserver to execute that file simply by requesting it from their web browser.

How do Web Shells get installed on servers?

Web Shells get installed in servers by exploiting vulnerabilities in the web server software or vulnerable plug-ins added to the web server.   Since the web server is visible on the internet, it can be located using scanning services such as shodan.io in order to quickly locate servers exposed by newly reported vulnerabilities.  Microsoft’s report includes a typical example of a vulnerability disclosed and patched in TMUI software from F5 Networks and within 5 days malicious users were observed uploading web shell exploits to unpatched servers.

The speed with which the malicious user community is able to respond to vulnerabilities is a challenge for Security Managers who may be constrained to work to monthly patch cycles with large networks to maintain and many systems to patch each month.  Patching needs to prioritise web server vulnerabilities that could be leveraged to insert files into the web server’s directory for later exploitation.  Typically, the rush to install a web shell into vulnerable servers is aiming only to secure a persistent beachhead on the server – the attackers may have no other current plans to attack the organisation.  Once the persistent access has been established by the installation of the web shell, the attackers may not return for some time or simply sell the access to another criminal for a fee.

Plug-ins are a particular concern as they appear often to be less secure than the core web server. For example, most WordPress related vulnerabilities disclosed recently are actually problems with plug-ins rather than the core WordPress platform:

• Vulnerable File Manager plug-in affects 300,000 WordPress sites
• Severe Vulnerabilities Patched in NextGen Gallery Affect over 800,000 WordPress Sites

How to mitigate the risk of a Web Shell?

There are several steps you can take in order to mitigate the risk of a web shell being installed on one of your servers and to detect one if it is installed already.

Prompt patching of webserver and plugin vulnerabilities

Malicious users need an initial attack vector into your network in order to be able to install the Web Shell.  Prompt patching of web servers and any plug-ins will help close the window of opportunity for vulnerabilities to be exploited.  Regular vulnerability scanning of internet facing systems will help identify vulnerabilities even before patches are available allowing for mitigating steps to be taken until the patch is installed.

Reduce the use of plug-ins

Reducing the attack surface of the web server by eliminating un-used or unnecessary plugins will reduce the number of vulnerabilities that could impact the security of the network.

File Integrity Monitoring

A Web Shell is a file that must necessarily reside in the live code directory of the web server.  By implementing File Integrity Monitoring, the arrival of unexpected files into that directory can be identified in real time – allowing security staff to remove the web shell promptly.

Malware scanning / endpoint protection software

If File Integrity Monitoring was not always in place, how can you tell if a Web Shell is already installed onto a web server?  Modern web applications can be comprised of hundreds or even thousands of files.  Scanning by malware detection software may be able to detect the web shell file on the web server. However, since the code of the web shell script is usually very similar to legitimate code within a modern web application this approach is unlikely to be 100% reliable.

According to Microsoft:

Another challenge in detecting web shells is uncovering intent. A harmless-seeming script can be malicious depending on intent. But when attackers can upload arbitrary input files in the web directory, then they can upload a full-featured web shell that allows arbitrary code execution—which some very simple web shells do.

As a result of these challenges, it is the behaviour of the Web Shell while it is executing that can be used to detect it by using Intrusion Detection techniques. For example, Microsoft’s Defender for Endpoint will spot the IIS web server instance (w3wp.exe) running suspicious commands or processes (such as: cmd or powershell) and flag these as indicators of compromise.

Republish the Application from source

A manual reconciliation of every file in the application directory against your source code repository may be necessary to identify any unexpected files.  As a last resort, you may have to wipe the application directory and republish the application  from the development environment. However, that development environment should also be checked carefully to ensure the Web Shell has not also be inserted into the source code repository in order to ensure its persistence (as happened in the SolarWinds hack).

Network segmentation prevents lateral movement

If a web server is compromised, then keeping it on a segregated network segment will prevent the attackers from being able to move laterally across the rest of the network.

Server configuration review and hardening

Perform a thorough Server Configuration Review to ensure vulnerabilities and misconfigurations in both the operating system and web appliction server are identified and remediated.

Web Shell attacks are a vector that appears to be gaining popularity with organised crime and nation state actors who desire persistent access to their target’s networks.  Only through careful and consistent security practices can you mitigate the risk of being a victim of a web shell attack and spot it quickly if one does happen.