Sigma Scanning with THOR

Our compromise assessment scanner THOR is able to apply Sigma rules during the local Eventlog analysis. This can help any customer that has no central SIEM system or performs a live forensic analysis on a system group that does not report to central monitoring. 

By running THOR on these systems with activated Sigma feature, THOR becomes a kind of a distributed and portable SIEM.

Since the Sigma scan module isn’t active by default, we thought it a good idea to explain how to activate an use it in the best possible way. 

Open Source Rule Set

By default THOR uses the open-source Sigma rule set with more than 500+ rules provided by the Sigma project on their Github page

Since our head of research is also one of the project maintainers, it was reasonable to combine the detection capabilities of Sigma with THOR’s scanning functionality on the endpoint. 

We comply with Sigma’s DRL (Detection Rule License) by including the rule authors in the event data produced by these rules.  

Custom Sigma Rules

You can easily add you own Sigma rules by placing them in the “./custom-signatures/sigma” sub folder.

THOR’s Sigma Config

The THOR default configuration for Sigma can be found in the Sigma repository. 

This configuration shows you, which Windows Eventlogs and Linux/Unix log files get analyzed by the Sigma module in THOR.

 

Sigma Scanning

To activate the Sigma module simply use the “–sigma” flag (or “sigma: True” in a YML config file).

You can start a THOR scan that analyzes the local Eventlog and activates the Sigma feature with:

thor64.exe -a Eventlog --sigma

To run a Sigma scan on a single Eventlog e.g. Sysmon’s log, use the “-n” flag.

thor64.exe -a Eventlog --sigma -n "Microsoft-Windows-Sysmon/Operational"

To include the Sigma feature in a standard THOR scan and check only the last 3 days of the Windows Eventlogs to reduce the scan duration, use:

thor64.exe --sigma -lookback 3

Sigma Matches

Once a Sigma rule matches on a log entry, you’ll see it listed in one of the REASON’s that lead to the classification of an event. 

The following example shows the detection of a China Chopper (Caidao) ASP web shell. That web shell has been detected by multiple Sigma rules. 

  1. Webshell Detection With Command Line Keywords 
  2. Shells Spawned by Web Servers
  3. Whoami Execution

Getting Started

Since this feature isn’t available in THOR Lite, please contact us via the “Get Started” button in the upper right corner and get a free trial voucher. Most customers that use THOR with Sigma choose one of our THOR license packs, especially the SOC Toolkit Pack, which was geared to the needs of today’s SOC teams. 

The Best Possible Monitoring with Sigma Rules

Some of you may already have heard of Sigma, a generic approach for signatures used in SIEM systems. Its main purpose is to provide a structured form in which researchers or analysts can describe their once developed detection methods and make them shareable with others.
Today I would like to describe another use case that helps us build the best possible signatures for any application.
In typical security monitoring projects, people integrate different log sources and threats/use cases they want to monitor in these logs. The selection of the log sources is determined by importance, availability and operational requirements. The central question is:

“What do I want to detect?”

There are several white papers and guides for the most common log sources like the Windows Eventlog. What you have to do is to read the documents, extract the interesting detection methods and define searches, panels and dashboards in your SIEM system. One of the main purposes of Sigma is to relieve you from this time consuming process. These public descriptions of detection methods are already part of Sigma or will be integrated by one of the contributors.
But today I’d like to point out a different use case that is less obvious but very useful.

The Best Possible Monitoring

Security analysts try to define useful searches and statistical analyses on the log data from all different log sources. They typically follow the public guides and create many different “failed logon” rules for all kinds of operating systems and applications.
But what happens when start integrating log sources and types that are not covered by public guidelines?
There are different approaches to this problem:

  • Cover failed authentication attempts
  • Monitor any failure event (with a base-lining)
  • Use statistic deviations (many new events of a certain type)
  • Look through the log data and select interesting messages
  • Talk to the application owners / administrators (often rather disappointing)
  • Talk with the application developers (in case of inhouse development)

All of these methods are valid and can help you setup useful searches on the available data. However, in order to create the best possible signatures we have to consider the following:

  • The most interesting and relevant fault conditions do not happen under normal conditions and therefore do not appear in everyday log data (the log data we have to select interesting events from)
  • Developers know the rarest or most relevant error conditions and the corresponding error IDs and messages
  • All possible error messages of that application appear in its source code

Imagine that we can extract the most interesting messages that the application is able to generate and define rules for these conditions. Imagine that this process is an easy task that any developer is able to perform.
Well, we have at our fingertips all the tools that are needed.

An Example: vsftpd

Let’s make this approach clearer. Under optimal conditions we ask the developers to extract the most relevant or abnormal error messages that the applications produces under conditions that indicate a manipulation or attack. Alternatively, we can do it ourselves and cross-check the results with the available log data to avoid false positives.
I checked the source code of the FTP server ‘vsftpd’ for error messages that indicate rare error conditions and fatal failures.

The resulting Sigma rule looks like this:

title: Suspicious VSFTPD error messages
description
: Detects suspicious VSFTPD error messages that indicate a fatal or suspicious error that could be caused by exploiting attempts
reference
: https://github.com/dagwieers/vsftpd/
author
: Florian Roth
date
: 2017/07/05
logsource
:
    product
: linux
    service
: vsftpd
detection
:
    keywords
:
        - 'Connection refused
: too many sessions for this address.'
        - 'Connection refused
: tcp_wrappers denial.'
        - 'Bad HTTP verb.'
        - 'port and pasv both active'
        - 'pasv and port both active'
        - 'Transfer done (but failed to open directory).'
        - 'Could not set file modification time.'
        - 'bug
: pid active in ptrace_sandbox_free'
        - 'PTRACE_SETOPTIONS failure'
        - 'weird status:'
        - "couldn't handle sandbox event"
        - 'syscall * out of bounds'
        - 'syscall not permitted:'
        - 'syscall validate failed:'
        - 'Input line too long.'
        - 'poor buffer accounting in str_netfd_alloc'
        - 'vsf_sysutil_read_loop'
    condition
: keywords
falsepositives
:
   - Unknown
level
: medium

After some testing we can now share the rule with the world in order to build a large signature database for the all different types of applications and services.
We could also try to convince developers to provide Sigma rules with their applications to help organisations establish the best possible monitoring of their software. I was thinking about an error message extractor that would parse a software project and extract error message strings that contain certain keywords like “failure”, “fatal”, “permission denied”, “refused” and others to facilitate this process for the rule writer.
If you want to support the project, create a pull request or send me your rules as gists or via pastebin to @cyb3ops. You could also become a contributor by providing a new backend for the rule converter “Sigmac” or become a member of our Slack team for threat hunters (references required).