From webshell weak signals to meaningful alert in four steps

Over the past decade, security products have matured from delivering tactical detections to expanding visibility across an enterprise. While seeing more events can lead to empowering discoveries, turning the volume of events into useful investigative leads has been primarily left to the security one-percenters.

In this post we’ll show you a practical example of how you can make a weak signal actionable by combining events from your endpoint and network security technologies into one meaningful alert. Specifically, we’ll walk through how you can create actionable detections for webshell activity.

We’ll use Sumo Logic as our SIEM; Palo Alto Networks firewall as our network security device; and the following endpoint detection and response (EDR) solutions:

• Tanium or
• Carbon Black

Step 0x00. Weak signals

A weak signal is an event that doesn’t contain enough context for you to easily determine the next investigative step. These types of alerts need an analyst to spend a lot of time validating them, and they tend to have a low true-positive rate.

In most cases, these alerts are the first to be overlooked or pushed to the bottom of the queue for analyst review. Weak signals can take many different forms, depending on what security devices are deployed.

For an endpoint product, weak signals often include:

• A file or registry modification on a host
• A module load by a process

On the network side, these alerts can take the shape of:

• Outbound web traffic from users
• Inbound HTTP traffic to a web server
• Scanning and exploit attempts from the Internet

On their own, any of these alerts — without additional context or analysis — are often useless and can be overwhelming.

But what happens when you correlate some of these time-intensive alerts to tell a more comprehensive story? Let’s take a peek at how this can benefit your organization with our webshell example.

Step 0x01. Know what you’re looking for (aka webshells 101)

(Skip to Step 0x02 if you’re familiar with webshells and already tell China Chopper jokes)

Webshells often serve as an initial foothold that attackers can use to compromise your internal network. They give an attacker access to a shell on a server in a victim’s environment via a web browser. To create one, an attacker compromises a web server or web-accessible directory. The attacker will drop a script  (or modify an existing page) which allows them to issue remote commands to the compromised system.

The scripts can be as small as a few bytes, and they exist in many language flavors (ASP, ASPX, CFM, JSP, and PHP, to name a few). Some contain additional features that help attackers perform reconnaissance, such as file browsers or scanning modules.

Webshells are primarily delivered through web application exploits or insecure practices, including:

• Web administrative interfaces with default or weak credentials
• Sites that allow arbitrary file uploads
• Web servers with remote file inclusion, SQL or cross-site scripting (XSS) vulnerabilities
• Content management system (CMS) vulnerabilities

Step 0x02. Alerts in Palo Alto Networks

Network vendors like Palo Alto Networks dedicate resources to researching vulnerabilities and developing rules that signal when someone attempts to use an exploit. However, external vulnerability scanning is now part of the normal white noise of the internet. Rarely does an attempted exploit mean that you were actually compromised. So you have to do more work to answer the question, “Was the system compromised?”

To answer that question, an analyst has to search for related network alerts from the target system. If a payload delivered to the system is detected, or the command-and-control (C2) method is known (via URL categorization or based on the contents of the packets), the analyst can determine that the exploit succeeded.

Keep in mind that absence of evidence is not evidence of absence. Attackers often use payloads or C2 methods to avoid these types of network detection. For example, passive backdoors like webshells won’t generate traffic until the attacker chooses to interact with the resource. In this case, if the attacker used a vulnerability to drop a webshell, we wouldn’t necessarily have network evidence indicating the host was compromised.

That’s why, in and of themselves, vulnerability alerts can be difficult to action. But… there is hope.

Here’s why. Even if we don’t have any related network alerts to analyze, we can build actionable alerts by combining network alerts for vulnerability attempts with relevant endpoint events, such as file modifications. By correlating these alerts you can quickly reduce the flood of vulnerability alerts and focus on the events where the vulnerability exploitation may have been successful.

First, we need to find all the exploit attempts. We’ll collect all the Palo Alto Network activity from hosts that generated an alert in the “Vulnerability” threat category. To accomplish this, we’ve configured Palo Alto Networks to forward “Vulnerability” alerts to Sumo Logic. Once you’ve done that, you can move on to step 0x03.

Step 0x03. Hi ho, hi ho, it’s off to the endpoint we go

Now that we know everywhere there could be a webshell, it’s time to combine the weak signals together. To do that, we need to correlate the network alerts with any servers that have had script file modifications in a web-accessible directory within 15 minutes of the alert. There are several ways to make the correlation. We’ll illustrate how you can do it with two of the most common endpoint detection and response tools.

Here are some specific examples of queries you can perform with an endpoint security product to capture webshell activity. Keep in mind that these queries are not comprehensive lists of web accessible locations. They’re just some ideas to get you off on the right foot.

Carbon Black Response

Carbon Black Response tracks network connections, module loads, remote threads, and file modifications on every endpoint where it’s deployed. You can query particular events within processes using a feature that Carbon Black calls “Watchlists”. The watchlists allow you to save queries, so Carbon Black can inform you whenever a process or binary matches certain event criteria. By creating a watchlist for file modifications in web-accessible directories, we can develop a weak signal to inform our security team when something resembling a webshell is created.

An example of a query for webshell creation with Carbon Black might look something like:

The data is sent to Sumo Logic by configuring the Carbon Black event forwarder. In our lab, we deployed the Event Forwarder on the Carbon Black Response Appliance and sent the output as JSON to a Sumo Logic HTTP Source.

Tanium

The Tanium Trace module uses a local datastore to record process events, network connections and file modifications on each endpoint where Trace is deployed. You query it by asking questions through the Tanium Console. Saved Questions are queries that are saved and recur on a predetermined basis. By using the Tanium “Trace File Operations” sensor to query for any new files created in web-accessible directories we can identify webshell-like activity. An example of a saved question for webshell creation with Tanium is:

The data is sent to Sumo Logic by configuring the Tanium Connect module to send the results of the saved question as JSON to a Sumo Logic HTTP Source.

Step 0x04. Correlation

The final step is to combine the weak signal alerts from the network device and the alert from the endpoint. To correlate these alerts we’ve used Sumo Logic as our SIEM.

Please note the following about the queries we’re providing:

• These queries are intended to work across Sumo Logic regardless of whether field extraction rules are set up. You shoulds use field extraction on ingestion; an example of this for Palo Alto Networks can be found here.
• The timewindow operator ensures we only join events that occurred within a 15-minute window of each other. This window of time may work for you, or you may need to tweak it depending on endpoint timestamps, clock skew, or other factors.

We configured logs to be sent to Sumo Logic in the following format:

• Palo Alto Networks – CSV
• Carbon Black – JSON
• Tanium – JSON

The query also assumes you’ve sent this data to Sumo Logic in the above formats.

Our query using Tanium and Palo Alto Networks is:

Our query using Carbon Black and Palo Alto Networks is:

—

If you’re interested in taking action on what was discussed in this post, below is a tearsheet with all the queries discussed to put this correlation into practice.

Executable Actions

Carbon Black Watchlist

Tanium Question

Sumo Logic Query Carbon Black

Sumo Logic Query Tanium

Happy Hunting!