Q:CYBER Translating Sigma Rules

This is the sixth installment of our series on Q:CYBER. In part 1 we covered how to configure NXLog to forward Windows Event Logs (WEL) into Q:CYBER. In part 2 we described in more detail how our streaming rules engine works.  In part 3, we reviewed how to create simple rules using the Q:CYBER Rules Builder. In Part 4, we discussed how to use Q:CYBER rule templates to detect Pass-the-Hash attacks based on Windows Event Logs. And, in our last installment, we explored how to create windowed rules in Q:CYBER to support advanced detections (such as with password spraying attacks).

In this post, we're going to explore a related topic: how to use the open-source Sigma signature rule specification in Q:CYBER.

About Sigma

The security community has released many great resources to help with building an effective security program. One such example is the community-driven Sigma rule specification. According to the Sigma documentation, “Sigma is a generic and open signature format that allows you to describe relevant log events in a straightforward manner. The rule format is very flexible, easy to write and applicable to any type of log file. The main purpose of this project is to provide a structured form in which researchers or analysts can describe their once developed detection methods and make them shareable with others. Sigma is for log files what Snort is for network traffic and YARA is for files.”

The public Sigma repository is full of rules contributed by the security community which includes detections for Windows, Linux, and AWS services among many others. In this post we will show you an example how to translate a Sigma rule into a streaming Q:CYBER rule using the rules builder workflow. The example below will cover basic components of the Sigma specification. For more detailed information see the Sigma wiki which is well documented and easy to read.

Sigma on Overpass-the-Hash

In this example we will look at a common variation on a Pass-the-Hash attack called Overpass-the-Hash (OPtH) which involves upgrading a NT hash into a full Kerberos ticket. Sigma rules are specified in YAML format and describe detection conditions within a log record or group of logs. Let’s look at the associated Sigma rule definition to detect an OPtH attack.

title: Successful Overpass the Hash Attempt
id: 192a0330-c20b-4356-90b6-7b7049ae0b87
status: experimental
description: Detects successful logon with logon type 9 (NewCredentials) which matches the Overpass the Hash behavior of e.g Mimikatz's sekurlsa::pth module.
references:
    - https://cyberwardog.blogspot.de/2017/04/chronicles-of-threat-hunter-hunting-for.html
author: Roberto Rodriguez (source), Dominik Schaudel (rule)
date: 2018/02/12
tags:
    - attack.lateral_movement
    - attack.t1075          # an old one
    - attack.s0002
    - attack.t1550.002
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4624
        LogonType: 9
        LogonProcessName: seclogo
        AuthenticationPackageName: Negotiate
    condition: selection
falsepositives:
    - Runas command-line tool using /netonly parameter
level: high

Parsing Sigma Rules

Much of the information in the above rule is metadata about the detection including title, status, description, references, date, tags, logsource, false positives, and level. The most important parts to focus on are the logsource and the detection sections.

The logsource section tells you what logs are needed for this rule. For this rule we need the Security events from Windows Event Logs (WEL).  

The detection section requires that you understand the Sigma specification and how to translate it into logical statements. In this rule there are two parts in the detection section - selection and condition.

Sigma Detection Condition

The condition is the most complex part of the Sigma rule and specifies the logic for triggering a detection. Condition expressions support logical groupings of keyword references, aggregations, and search patterns. (Again we highly recommend reviewing the specification for each example to get a full understanding of what conditions are possible.)

Sigma Detection Selection

In Sigma, selection is a map or dictionary. Again referencing the the Sigma specification: “maps (or dictionaries) consist of key/value pairs, in which the key is a field in the log data and the value a string or integer value. Lists of maps are joined with a logical 'OR'. All elements of a map are joined with a logical 'AND'.”

Looking at the condition part of the section we can see that the only condition needed to trigger this detection is what’s contained in the keyword selection.

detection:
    selection:
        EventID: 4624
        LogonType: 9
        LogonProcessName: seclogo
        AuthenticationPackageName: Negotiate
    condition: selection

We now know that all elements of a map are joined with a logical AND and that maps are composed of key/value pairs where the keys reference fields in the log record.We can now translate the detection into a sentence and stated as:

“Alert me when a Windows event occurs with fields where EventID EQUALS 4624 AND LogonType EQUALS 9 AND LogonProcessName EQUALS seclogo AND AuthenticationPackageName EQUALS Negotiate”

Q:CYBER - Overpass-the-Hash

To create this rule in Q:CYBER select New Rule under the Detections and Rules menu item. This will open the rules builder workflow.

Select your Windows Event Log data source, give the rule a name like Overpass-the-Hash, and scroll down to the IF block. This is where we can translate our logic above using simple conditional statements as shown below.

Once you enable this rule, whenever our streaming rules engine evaluates a log record with these values an alert will be triggered.

For convenience a rule template to detect Overpass-the-Hash attacks is part of the Q:CYBER standard library of detections, so you do not need to build this rule from scratch.

This is just one example to get you started on creating your own rules or leveraging the established corpus of Sigma rules as higher performance streaming rules in Q:CYBER.