Published in


Exploring Sigma Rules

0x0: Introduction

The last blog which was dedicated to YARA rules and missing out of the Sigma Rules, lies one of the main reason of writing this small blog about Sigma Rules, similar to the earlier blog this one too will focus on the very basic steps on what exactly are sigma rules, why are they used and how can we test them against targets.

0x1: Getting started

After a small search, we come up with the official GitHub which leads us to the definition that Sigma is a generic and open signature format which helps to analyze the log files. As YARA rules help us to analyze files and snort rules for the network traffic, similarly Sigma rules help us to analyze log events and is generally having a file format of .YML or basically a YAML source file.

0x2 : General specifications of Sigma Rules

The sigma rule consists of the following sections, we will understand it with one of third party Sigma Rule, which has been downloaded from the official repository.

id [optional]
related [optional]
- type {type-identifier}
id {rule-id}
status [optional]
description [optional]
author [optional]
references [optional]
category [optional]
product [optional]
service [optional]
definition [optional]
{search-identifier} [optional]
{string-list} [optional]
{field: value} [optional]
timeframe [optional]
fields [optional]
falsepositives [optional]
level [optional]
tags [optional]
[arbitrary custom fields]

Let us look into the structure of a sigma rule:

  • Title : The title field consists of status which somehow denotes the stability of the rule, in simple words the rule is stable enough to use against log files, the status is consisting of three types stable which denotes the rule is stable enough for use in production, the test status denotes that the rule although is enough stable requires some refactoring, and experimental status denotes that rule can lead to false positives, and it’s better to be avoided for use in production system.
  • Identification: The identification field denotes aggregation of various info like the UUID, cross-references with other UUID of sigma rules in the related attribute, and the type of the rule which denotes either the rule has been derived from some other rule, or has been derived from obsolete rules or merged from other existing or obsolete rule or has been renamed due to some other rule which includes reasons like dissolving of the previous UUID of the rule and others. The UUID of the rules are randomly generated.
  • Description & Author : The description field denotes short info on the rule and the malicious activity which is to be detected, and the author field denotes the creator of the rule.
  • References & Tags : The reference field denotes information on various sources like blogs or articles and similar and tags denote the information on various categories the rule can be categorized into, for example attack.t1574 here refers to the technique also known as Hijack Execution Flow and .001 refers to the sub technique also known as DLL Search Order Hijacking, more info can be found here.
  • Log Source & Detection : The log detection field denotes the log data on which the detection rule is to be applied, the log source further contains a few other subfields like product, category & service, here the category is defined as file_event which means selecting all log files written by a certain group of products like for web server logs here, here in this rule it’s of file events, the product subfield is used for selecting all log outputs of certain products like the Windows, the detection field denotes search identifiers that represents searches on log data, the condition subfield denotes the specification and what exactly are the needs and are filtered with various expressions like logical AND/OR, not, brackets, Pipes and lot more.
  • False Positives & Level : The false positive field denotes the list of false positives which can occur, and the level field denotes the degree of the criticality of the tool, for example in this tool it is set to high, which means that any relevant event should trigger an internal alert and requires a prompt review.

0x3 : Sigmac

So, how we went through the fields of a sigma rule, now how do we test the rules? Moving ahead to the tools folder we have the sigmac tool which helps us to test our rules against targets like splunk, kibana, logpoint etc. Sigmac needs python3 to run.

$python3 sigmac -h

This command shows us help & options for using the tool.

Now let us test the existing rule with target splunk:

$python3 sigmac -t splunk ../sigma-master/rules/windows/sysmon/sysmon_pingback_backdoor.yml 

So, that was a speed run overview of an sigma rule, and testing it, a guide to writing your first Sigma Rule can be found here.

0x4 : References

Blog by Nerd of AX1AL, till then happy analyzing. Join our discord server!

A community for the nerds by the nerds related to:Reverse Engineering, Malware analysis, Web security, CTFs & various other domains of security research.

Recommended from Medium

Is the Need Of Mobile Application Still Relevant In 2021?

How To Create Transparent Glass Materials In Unity

Join our Community Builders Program

Containership Cloud Alternative: Move to Cloud 66

Keys and Constraints in Relational Database

What is Git? How to use Git commands?

Agile Flow Metrics — Arrivals x Departures

#NoProcesses — Two Key Activities

3d Clip art image representing the delivery of packages

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


A community for the nerds by the nerds .

More from Medium

BoxHero Feature Improvements

#AlumoftheWeek — James J. Njong, AIMS Cameroon ’19

Good beginner exercise for improving programming: Monte Carlo simulation of the approximation of…

How To Make The Fastest, Most Reliable And Most Accurate IIS Migration?