How to Detect Web Shells With a SIEM

During the recent campaign targeting Microsoft Exchange OWA vulnerabilities, one piece of tradecraft came up again and again. Threat actors deployed web shells that were potentially present for months. 

A web shell is a malicious script that enables remote access and control to a web server, allowing for the execution of arbitrary commands. They can be used to escalate and maintain persistent access by attackers.

So this begs the question: why were none of these web shells identified?

Web shells haven’t received much attention from cybersecurity vendors. It’s commonplace for many malicious shells to fly under the radar, like the case below.

What a nice surprise!
China chopper like #webshell appended to PNG file with malformed magic header

> often used to bypass upload filtershttps://t.co/a2EcDxGZmH pic.twitter.com/nBIZwxGNRY

— Nextron Systems (@thor_scanner) March 25, 2019

That doesn’t mean you need to give up when it comes to detecting web shells. Even if the big vendors can’t catch them, there are still plenty of things you can do to detect web shell attacks.

There are several low-cost methods you can use to identify the creation, use, and interaction with web shells. All you need are web server access logs, some scripts, a file integrity monitoring tool, and a SIEM (security information and event management) solution, like Blumira’s detection and response platform.

Identifying Web Shell Creation

During a web shell attack, a threat actor will drop the web shell in a web accessible directory. 

What does this look like from a defender’s perspective? 

Web shells need to interact and run code on the system, so the files will be in formats that support this, like .php, .asp, .aspx, .jsp, etc. This can quickly narrow things down.

Review web accessible directories for newly created .php, .asp, .aspx, and .jsp files for indication of web shell creation. 

Which Tools to Use: 

• File Integrity Monitoring (FIM) tools like OSSEC, Wazuh
• AuditD on Linux via SIEM
• Sysmon on Windows via SIEM
• Custom Scripts

Identifying Web Shells in Use

Once a shell is present, the threat actor will want to use it. Typically, a threat actor will use the web shell to interact with the underlying operating system.

You can observe this activity on Windows servers by monitoring processes spawned from the IIS server process w3wp.exe. Many web shells will call from w3wp.exe to cmd.exe to interact with the operating system at a lower level and act on threat actor objectives.

Which Tools to Use:

• Sysmon (System Monitor) on Windows via a SIEM

Identifying Web Shell Interaction

A threat actor needs to connect to the web shell on the server to interact with that shell. You can look for anomalies in web server access logs to spot web shell interaction.

For the majority of web traffic, the server requests will be in the form of GET requests. So, you can identify potentially malicious traffic by filtering web server access logs to look for the highest POST traffic and then searching for calls to URLs that include one of the common web shell file types (.php, .asp, .aspx, .jsp).

Some URLs may produce this behavior during the normal operations of the application, like login pages. Once you filter this out, though, you can quickly spot threat actors interacting with web shells.

Which tools to use:

• IIS Access Logs on Windows via a SIEM
• Apache/Nginx Access Logs on Linux via a SIEM

Blumira’s cloud SIEM can help you to identify web shells and spot abnormal behavior within your environment. Sign up for a free trial to see Blumira in action.  

To learn more about web shell detection, download our on-demand webinar.