loader

SIGMA format is one of the common languages ​​of security systems such as EDR and SIEM. According to this format, we can create rules to identify threats. Note that SOC engineers are constantly dealing with security equipment, including SIEM. SIEMs have different languages, each of which follows a specific format. For example, to detect the Microsoft Follina vulnerability,

We use the following rule for Splunk.

Index=* sourcetype=wineventlog:security EventCode=4688 process_name=”msdt.exe”
| regex Creator_Process_Name=(“winword.exe|excel.exe|powerpnt.exe”)
| regex CommandLine=(“ms-msdt:/id|ms-msdt:-id|PCWDiagnostic”)
| stats count by _time, host, process_name, Create_Process_Name, CommandLine

Here we use the following rule for IBM QRadar.

SELECT UTF8(payload) from events where LOGSOURCETYPENAME(devicetype)='Microsoft Windows Security Event Log' and ("Process CommandLine" ilike '%WINWORD.EXE%') and ("Process CommandLine" ilike '%msdt.exe%') and ("Process CommandLine" ilike '%sdiagnhost.exe%' or "Process CommandLine" ilike '%csc.exe%' or "Process CommandLine" ilike '%PCWDiagnostic%' or "Process CommandLine" ilike '%IT_ReBrowserForFile%' or "Process CommandLine" ilike '%IT_BrowserForFile%' or "Process CommandLine" ilike '%conhost.exe%')
GrayLog
(CommandLine.keyword:WINWORD.EXE AND CommandLine.keyword:msdt.exe AND CommandLine.keyword:(sdiagnhost.exe csc.exe PCWDiagnostic IT_ReBrowserForFile IT_BrowserForFile conhost.exe))
Sumologic
(_sourceCategory=windows AND (CommandLine = "WINWORD.EXE") AND (CommandLine = "msdt.exe") AND (CommandLine = "sdiagnhost.exe" OR CommandLine = "csc.exe" OR CommandLine = "PCWDiagnostic" OR CommandLine = "IT_ReBrowserForFile" OR CommandLine = "IT_BrowserForFile" OR CommandLine = "conhost.exe"))

Now the question is, how should SOC engineers completely understand all the languages ​​related to SIEMs? This is where Sigma comes to the aid of SOC engineers. Thanks to SIGMA, instead of writing two rules, one for Splunk and one for IBM Arsight, we create a rule in SIGMA format and easily convert it to any other language that our desired SIEM can understand through SIGMA Converter.

How Can Write Sigma Rule?

Now let’s talk about how I can create Sigma Rules. Writing rule in Sigma is much easier than writing rules in SIEM. Sigma uses Yaml Based writing mode for its Rules. To write the Sigma rule, you must first use a text editor (I use VSCode). In the Text Editor, we first create a file in YAML format because of the format for the Sigma Rules in Yaml.

YAML File

Note: Install the YAML plugin in VSCode before creating the YAML file.

YAML VSCode Plugin

Structure Of a Sigma Rule

The structure of a rule in Sigma is straightforward. In writing Sigma Rules, there are three parts for us, each of which does a specific job and has mandatory and optional features, these three parts in the Rules:

  • Metadata
  • Log Source
  • Detection

Each of the above sections has many features, some of which are optional; there is no need to write them, and some of the features are mandatory, so they must be specified.

Metadata Field

In this section, we provide information about the Rule that we wrote, such as the time it was written, the author’s name, descriptions, and references can be specified in this section. This section has various features as follows:

  • Date section (optional) – In this section, we specify the rule creation time.
  • Status section (optional) In this section, we specify the status of the rule, which usually has three choices for this section.
  • Description section (optional) In this section, we describe the rule; for example, I say that this rule is to identify the vulnerability of Microsoft Follina.
  • Reference section (optional) – We can introduce a reference in this section.
  • Tag section (optional) – we can enter a tag of attacks related to our rule.
    • Note: Usually, MITER ATT&CK Tag is Placed in this section.
  • Level section (optional) – In this section, we specify the level of the attack.

Example:

title: Possible DNS Tunneling

id: 1ec4b281-aa65-46a2-bdae-5fd830ed914e

status: test

description: Normally, DNS logs contain a limited amount of different dns queries for a single domain. This rule detects a high amount of queries for a single domain, which can be an indicator that DNS is used to transfer data.

author: Patrick Bareiss

references:

  – https://zeltser.com/c2-dns-tunneling/

  – https://patrick-bareiss.com/detect-c2-traffic-over-dns-using-sigma/

date: 2019/04/07

modified: 2021/11/27

LogSource Field

This section specifies the source of our logs and the type from which source. Sigma has four categories for LogSources, which are ready below, along with their examples.

  • Category – e.g., Firewall, Proxy, Web, Antivirus, Process_Creation
  • Product – e.g., Windows, Apache, Symantec
  • Service – e.g., System, AppLocker, Security, Sysmon
  • Definition – e.g., Information that describes the log source

Example:

logsource:
service: apache
category: dns

Detection Field

that the most important part of our Sigma Rule is the Detection part. This part determines the factors that identify the intended attack.

Example:

detection:
keywords:
– ‘exit signal Segmentation Fault’
condition: keywords

Full Example

Consider the example below. In the following example, we want to search for Exit Signal Segmentation Fault in our logs through Sigma Rule. In the diagnosis section, we use keywords, put our expression at the bottom, and our Sigma rule is prepared to identify Segmentation Fault Error in our logs.

title: Apache Segmentation Fault
id: 1da8ce0b-855d-4004-8860-7d64d42063b1
status: test
description: Detects a segmentation fault error message caused by a creashing apache worker process
author: Florian Roth
references:
- http://www.securityfocus.com/infocus/1633
date: 2017/02/28
modified: 2021/11/27
logsource:
service: apache
detection:
keywords:
- 'exit signal Segmentation Fault'
condition: keywords
falsepositives:
- Unknown
level: high
tags:
- attack.impact
- attack.t1499.004

How can translate Sigma Rule into other languages?

Note that we said that when we write a Sigma Rule, we can translate it into the languages ​​of other security equipment, including SIEMs. To do this, we have two main ways:

  • 1 – uncoder.io
  • 2 – Sigmac

Uncoder.io

To use the Uncoder.io site to translate our Sigma Rule into another language, it is enough to enter this website and select the Sigma option on the left side and specify SIEM or the desired format on the right side.

undoer.io

Here, our goal is to convert our desired Sigma Rule into a Splunk SPL. Just select the Splunk option on the right side and click the Translate option.

Uncoder.io

Sigmac

To use Sigmac, you can do the following.

./sigmac -t [Target Format] -c [Configuration File Path] [Rule File Path]

Leave a Reply

Your email address will not be published. Required fields are marked *