Defender’s Toolkit 102: Sigma Rules

What is Sigma?

Sigma is the brainchild of Florian Roth and Thomas Patzke. To quote the GitHub page of the open-source tool, Sigma:

is a generic and open signature format that allows you to describe relevant log events in a straightforward manner.

Let’s reference back to our problem. One single use-case had to be converted for every single SIEM or centralized logging platform available to SOC’s all over the world. Luckily, Sigma rules (a use-case converted into the Sigma specification is called a rule) serve as a strict format for analysts to describe a particular use-case and convert it for whichever platform they want.

Writing Sigma Rules

We’ve previously discussed how a Sigma rule is encapsulated in a YAML file. This YAML file follows a standard or specification set by the authors of Sigma. It is available on the GitHub page as well. Just to summarize that information — the following sections constitute a good rule:

  • Log Source (Define the log source which will be used to collect the data from e.g. the Windows Security log channel)
  • Detections (selections, filters, and conditions)
  • False-positives
  • Optional (and custom) tags
A Sample Rule to Detect Mimikatz

How to Start Writing Sigma Rules?

Let’s break the process down into small, achievable steps.

Step 1: Acquire the Sigma repository [Optional]

The official Sigma repository contains all documentation, sample rules, and compilers required to convert the Sigma into queries. To get started, fetch the Sigma repository and store it on your disk:

git clone https://github.com/SigmaHQ/sigma

Step 2: Create a YAML file

Let’s start writing the Sigma rule by creating a new YAML file locally. You can use your favorite development environment or editor (even Notepad if you love excruciating pain). With code editors, you can easily format, syntax-check, and highlight your YAML file without hitting your head against a wall. Once the file is created, let’s copy the specification into the file: (excuse any mistakes you might notice as we’ll fix it while writing the rule)

title:
id:
status:
description:
author:
references:
logsource:
category:
product:
service:
definition:
detection:
condition:
fields:
falsepositives:
level:
tags:

Step 3: Provide Input to Attributes

Our next step is to fill the required attributes by acquiring information from the source of the detection use-case. For this particular example, I’ll cheat and open one of rules from the Sigma repository which are available under the .\rules\ directory.

title: Mimikatz Command Line
id: a642964e-bead-4bed-8910-1bb4d63e3b4d
description: Detection well-known mimikatz command line arguments
author: Teymur Kheirkhabarov, oscd.community
date: 2019/10/22
modified: 2020/09/01
references:
- https://www.slideshare.net/heirhabarov/hunting-for-credentials-dumping-in-windows-environment
falsepositives:
- Legitimate Administrator using tool for password recovery
level: medium
status: experimental
  • Test — Tuning is required if an FP is thoroughly vetted
  • Experimental — Usable in the test environment and needs tuning to reduce the noise and FPs
  • Medium
  • High
  • Critical
logsource:
category: process_creation
product: windows
  • Product — log files generated by a particular product e.g. windows (Eventlog), linux, splunk, etc.
  • Service — Subset of a product’s log e.g. security, powershell, sysmon, etc.
detection:
selection_1:
CommandLine|contains:
- DumpCreds
- invoke-mimikatz
selection_2:
CommandLine|contains:
- rpc
- token
- crypto
- dpapi
- sekurlsa
- kerberos
- lsadump
- privilege
- process
selection_3:
CommandLine|contains:
- '::'
condition: selection_1 or selection_2 and selection_3
  • Conditions — How should the selection or filters be evaluated
  • all
  • base64
  • endswith
  • startswith
  • 1 of (selection) OR all of (selection) — this you might recognize from Yara as well
  • Negation using ‘not’ — e.g. not selection
  • Grouping expressions by using parenthesis — e.g. (selection1 and selection2) or selection3

Step 4: Compiling the Rule

In order to convert the Sigma rule into searchable queries for your SIEM or logging platform, you can use the Sigmac tool shipped with Sigma itself. Head into the .\tools\ directory and execute Sigmac :

python .\sigmac -h
python .\sigmac --lists
python .\sigmac -t splunk -c splunk-windows ..\rules\windows\process_creation\win_mimikatz_command_line.yml

You can now go ahead and use the rule on your Splunk instance!

To read more about Configurations and Field Mapping — refer to the source: https://github.com/SigmaHQ/sigma/blob/master/tools/README.md

Using Uncoder.io

SOC Prime has also released a tool named Uncoder. Using the web interface, you can easily write and play around with Sigma rules on the web. It allows you to write, edit, test, and compile the rules for a variety of targets.

Sample Rule translated via Uncoder

Conclusion

Writing Sigma rules is quite easy. Though there are sophisticated conditions and selections as well, you can easily grasp them in time. The authors have done a tremendous job with the documentation of the tool and its compiler for newcomers to understand. Make sure to practice writing Sigma rules every now and then so you can write them to aid your Incident Response process or empower your SOC in the longer run.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store