How to detect and prevent web shells: New guidance from the NSA and the Australian government

Introduction

It’s not every day that governments of different countries draft guidance rules about any subject together. It is even rarer that they create joint guidance for cybersecurity reasons. It may come as a surprise to many that the United States government (NSA) and the Australian government (Australian Signals Directorate or ASD) have issued joint advisory guidance rules for how to detect and prevent web shells. 

This article will detail the CSI between NSA and ASD and will explore guidance for how to detect web shells, prevent web shells and response and recovery.

Become a certified reverse engineer!

Get live, hands-on malware analysis training from anywhere, and become a Certified Reverse Engineering Analyst.

Start Learning

A meeting of the minds between the United States government (NSA) and the Australian government

On April 22, 2020, the NSA and ASD released a Cybersecurity Information Sheet (CSI) addressing a common threat — web shell malware. 

Web shells are malware used by attackers, normally on the victim’s web server, that are capable of executing arbitrary system commands. They are deployed by exploiting vulnerabilities of web applications or are uploaded to compromised machines and can serve as backdoors (for persistence). 

The CSI categorizes their advisory guidance into three categories: detection, prevention and response and recovery. These categories will be used to present these pieces of guidance to you in the most organized way possible. While this article will provide the top guidance suggestions, it is not an exhaustive list. For the full CSI, click here. 

Detection

Comparing with “known-good” web applications

Web shells are known to rely upon modifying or creating files within web applications. What is considered the best method of web shell detection is comparing the production version of a web application against that of a web shell that is verified to be benign. Any discrepancies should be reviewed manually for authenticity. For more information click here.

It should be noted that during authenticity review, timestamps should not be trusted. Attackers are known to modify legitimate timestamps in order to increase their own legitimacy and to avoid detection.

Using signatures for detection

From the points of view of both the host and the network, web shell detection based on signatures is unreliable. Web shells are easy to modify and obfuscate, so unless you are dealing with a minimally modified web shell where you can use expression-based or fingerprint detection, it is not a good idea to rely on signatures from the host perspective. 

From the network perspective, using signatures to detect web shells is unreliable because they are easily encrypted.

Anomalous web traffic detection

Web shells are designed to blend in to traffic when made well, but there are some proverbial chinks in their armor which should be focused on for detection.

• User agent strings and client IP address space — without advanced knowledge, web shell requests will appear anomalous
• Traffic routing web shells default to the user agent strings or IP addresses. This should appear as unusual
• Attackers may forget to disguise web shell requests by not using referral headers or using unusual referral headers, which may be indicative of web shell presence

Prevention

Harden those web servers!

Hardening web servers, meaning securing configurations of web servers and applications, can prevent web shells. Other measures to make your hardening more effective include:

• Block access to used services and ports
• Services that are used should be restricted to legitimate clients
• Deploying an advanced, host-based security product with features like machine learning

Mother, may I?

Privileges for web services should be aligned with the least privilege security paradigm. This means that you should not give web applications permission to write to a web-accessible directory directly or permission to modify web-accessible code which would make attackers unable to upload a web shell to vulnerable web applications. This may not be available for web applications, so check your vendor for availability.

Monitoring file integrity

If you are not able to harden web application permissions, you can get a similar effect by monitoring file integrity. This is because file integrity solutions can allow you to block or alert you when changes to web accessible directories occur. Depending on your file integrity monitoring solution, you may be able to allow certain legitimate file changes and deny others.

Response/recovery

Web shells vary widely in their persistence mechanisms and other functionalities. They may indicate a larger intrusion. Once discovered, it is necessary to determine how far into the network that the attacker has penetrated. 

Network flow data and packet capture (PCAP) can help determine where the attackers are pivoting into the network. Do not clean up this pivot without discovering the full force of the instruction and supplanting the intruder or access can be regained later.

Conclusion

In April of 2020, the NSA and ASD of the Australian government joined forces to combat a common cybersecurity challenge that both countries face — web shells. While web shells are by no means new, they are still relied upon fairly heavily by attackers and still remain one of the most commonly used malware out there. 

For those looking to detect, prevent or respond to/recover from web shell activity in your environment, you will find this guidance to be as long overdue, as it is useful for administrators dealing with web shells.

Sources

1. Cybersecurity Information Sheet: Detect and Prevent Web Shell Malware, National Security Agency
2. How to Detect & Prevent Cyberattackers from Exploiting Web Servers via Web Shell Malware, Security Magazine