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.

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

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.

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.

Sigmac
To use Sigmac, you can do the following.
./sigmac -t [Target Format] -c [Configuration File Path] [Rule File Path]