A New Approach to Accelerate Threat Detection

This article explains the importance of early threat detection and illustrates in detail about how a SIEM solution like Splunk can be useful in threat detection and incident response. SIEM is one of the several technologies that are used to detect threats at various points in the network. In the later part of this article, we’ll look a little more into the SIEM solution that we have used in our research to detect threats using our detection patterns.

Let’s get started by listing down a few best practices to follow when implementing threat detection and response solutions.

• Log all endpoints that serve as network access points.
• Configure alerts for risky activities using proper tools and solutions that provide real-time protection. Although preventative measures like having firewalls, antivirus, etc. can be effective, but to continuously monitor real-time activity becomes essential.
• Have an incident response plan.

Automating the above processes can provide effective controls that exponentially increase the efficiency and allow us to integrate compliance data with other information as a part of threat detection and incident response processes. This will react to the most dangerous threats in an instant and provide the level of real-time identification and protection that today’s threats require.

Now let’s look at the key topic.

Even the best detection solutions and tools will ultimately miss some recent or advanced threats. In such scenarios, Log analysis often becomes one of a line of defense mechanisms. When logs are integrated into a SIEM, correlations between the events captured in these logs can help identify patterns and alerts missed by other detection mechanisms.

Let’s take an example of Nginx vulnerability from our research and learn more about how we can detect patterns from logs.

To demonstrate this, we have picked a CVE, as a part of our research, for which we have a publicly available exploit in the “exploit-DB“. Let’s have a detailed look into the research and the steps we have taken to reproduce the attack.

Detecting CVE-2010-2263

Vulnerability Analysis:

Nginx is vulnerable to “Exposure of Sensitive Information”. Nginx is a web server that can also be used as a reverse proxy, load balancer, mail proxy and HTTP cache. This application when running on Windows OS is vulnerable to disclosure/download of arbitrary files under the web document root since the app parser couldn’t handle ADS (Alternate Data Streams) and it treats a data stream as a usual file when appended by `::$data` to the URI. From our research and looking at the information provided in the advisories, it is quite clear that UNIX versions are not vulnerable to this vulnerability. We have tested this on WINDOWS XP SP3.

You can find more information about Alternate Data Streams in the reference below: https://searchsecurity.techtarget.com/definition/alternate-data-stream

Steps taken to Reproduce the Attack:

Since this vulnerability affects Windows OS, downloading and launching the Nginx server is quite simple.

To install Nginx for windows, download the vulnerable version of the “.zip” extension and unpack the distribution.

Let’s start Nginx service using the “start nginx” command.

To check if the server is up and running, visit : http://localhost/ or http://127.0.0.1/ on your browser. You should see the default Nginx page with the "Welcome to nginx!" message. Nginx runs on port 80 by default. 

Required Payload:  http://[IP or HOSTNAME]/[FILE]::$data 

By appending `::$data` to the file, you'll be popped up with a window requesting you to download the file. 

1. Now, start the server. 
2. Visit `http://localhost/index.html::$data` 
3. A dialogue box will be pop-up asking you to read/download the "index.html" file. 

4. You can go ahead and download it. 

5. If you open the file in an editor, you can view the raw contents of it.

Once done, you can use the `nginx -s stop` command to stop the nginx service.  

Note: This PoC doesn't work in Internet Explorer. 

Now that we have reproduced the attack, let's get back to the detection through log analysis that we mentioned earlier.   You can find the Nginx logs under the "logs" directory. 

Below is the access log from the vulnerable version of 0.7.65.  ‍

127.0.0.1 - - [04/Jun/2020:13:11:35 +0530] "GET /index.html::$data
HTTP/1.1" 200 151 "-" "Mozilla/5.0 (Windows NT 5.1; rv:52.0)
Gecko/20100101 Firefox/52.0"
  

‍For a better understanding, we ran the above PoC on the fixed version 0.7.66 as well and below is the access log. 

127.0.0.1 - - [04/Jun/2020:13:20:42 +0530] "GET /index.html::$data
HTTP/1.1" 400 0 "-" "-"
  

‍By looking at the above two logs, we can notice the similarities clearly with one major difference. 

• From the vulnerable log, we can see that the request having `::$data` as the payload in the URI has been parsed with a 200 OK response code. 
• It's the same scenario with the fixed log except that the response code is 400 Bad Request. 

  From these two points we can conclude the detection pattern as follows: 

• Access log having the payload(::$data) in the URI with 200 response code indicates a successful attack for CVE-2010-2263. 
• Access log having the payload(::$data) in the URI with 400 response code indicates an attempt made to exploit CVE-2010-2263. 

Now that we have identified the pattern for detecting malicious activity, these logs can be indexed into Splunk Enterprise for further analysis. As we have already analyzed and identified the pattern, we can write a Splunk query to fetch the events and save the search criteria as an alert or a report.

Search Query:

  sourcetype="nginx:plus:access" uri_path="*::$data" status=200 OR 400
  

‍A sourcetype determines how Splunk Enterprise formats the log data during the indexing process. Based on the source type, fields like “uri_path” and “status” will be extracted and using these fields the search query can be further refined. We can create or add custom sourcetypes based on the type of logs. 

Report: A report is considered as a saved search. Let’s say, we have created a search query based on our detection pattern which could indicate the attempts made for CVE-2010-2263. Now when we execute the query, the results are as follows.

If the results are as expected and informative, we can save this query as a report and can run it whenever we require this data. 

We can give it any title that we want. In this case, I’ve given it “CVE-2010-2263” and saved it. There are couple of other options that can be modified based on the requirement before saving it.  

Here is how the result of the reports would look like. 

We can later view the saved reports by navigating through Settings -> Searches, reports and alerts. We can run and even edit the report whenever required. 

Alerts: 

• Using this, we can proactively monitor the data in real-time and identify the attacks before they impact the customers and services. 

In this scenario, let’s say, we want an alert when the above search criteria is met instead of just viewing the data as a report.

So, we can save this search as an alert from the same “Save As” drop-down menu. There are multiple options to edit as required. 

There are two types of alerts we can choose from, "Scheduled" and "Real-time". As the names suggest, alerts can be scheduled to run at a particular time, or it can be configured to run in real-time. The alerts will be triggered each time the search condition is met. We can also configure the "Trigger actions", where we can select one or more ways to be notified of the alerts. These saved alerts can be viewed and edited from the Settings menu.

And the "Triggered Alerts" can be viewed from the Activity menu in the Splunk bar. 

Generating SIGMA for Splunk 

Splunk allows us to respond to the incidents quickly and focus more on remediation by collecting and analyzing relevant log data.  

Also, as a part of our research process, we have written a Sigma rule for the above detection which describes the log event in a simpler manner. This rule format is very flexible and is applicable to any type of log file. It gives a standardized format in which we can describe our detection method in Sigma and make it sharable. 

Sigma Rule for CVE-2010-2263: ‍

  title: CVE-2010-2263 Exploitation Attempt
id: af627227-6d80-49c9-bec4-d5cf344c6b39
status: experimental
description: Detects the source code disclosure exploit attempt
references:
  - https://www.exploit-db.com/exploits/13822
author: Loginsoft Research Unit
date: 2020/05/27
logsource:
  product: nginx
  category: webserver
detection:
  selection:
    c-uri: '*::$data'
    sc-status: 
      - 200
      - 400
  condition: selection
falsepositives:
  - Unknown
level: medium
  

‍The detection method described in the Sigma rule can be easily converted/ translated to other SIEM solution search languages using online tools like uncoder.io. This new approach to SIEM threat detection dramatically reduces the overhead associated with traditional development of correlation rules and searches. 

To view more detection rules, visit our Threat Detection base: https://research.loginsoft.com/threat-detection/