Sigma rules! The generic signature format for SIEM systems.

Published: 2020-06-19
Last Updated: 2020-06-19 09:58:05 UTC
by Remco Verhoef (Version: 1)
0 comment(s)

What Snort is to network traffic, and YARA to files, is Sigma to logs. By creating and using Sigma rules you’ll have generic rules which can be shared and run against different targets (e.g. SIEMs).

Sigma solves the issue of everyone working on their own analysis, searches and dashboards of log data they’ve collected by having a standardized format to create rules to be reused and shared with others, supporting many different target systems. Many targets are supported currently: Splunk (plainqueries and dashboards),  ElasticSearch Query Strings,  ElasticSearch Query DSL, Kibana, Elastic X-Pack Watcher, Logpoint, Microsoft Defender Advanced Threat Protection (MDATP), Azure Sentinel / Azure Log Analytics, Sumologic, ArcSight, QRadar, Qualys, RSA NetWitness, PowerShell, Grep with Perl-compatible regular expression support, LimaCharlie, ee-outliers.

Some of the use cases for Sigma are:

  • Describe the detection methods and make it available.
  • Invest in generating rules for Sigma and use on many different (e.g. SIEM) systems.
  • Share the signature as an appendix of your analysis.
  • Use Sigma to share the signature with other threat intel communities.

A Sigma rule is a YAML file, following the specification which be found here, having the following sections:

  • metadata (id, tags, author, title, references, level)
  • status (experimental or normal), the status is being used to filter on experimental or normal rules.
  • the log source, which defines the source of the log data
  • detections (one or more selectors, timeframe and condition)
  • optional tags
  • false positives, describing scenarios where false positives could be triggered as help for the analyst

The detection is the most important part of the rule, defining when the rule will be triggered. It consists of one or more selectors, each selector can be a map (all joined with a logical function and) or list (logical function or) and be nested. The map or list will contain the column to test (using wildcards for fields) and a value, with optional transformations (contains, all, base64, startswith, endswith, etc.) or type modifiers (regular expression). An optional timeframe will define the period for the selector to be aggregated on. The condition will tie everything together, evaluating the selectors using an expression that is usually complex. Within the condition, logical functions like and/or, not, one of, any of and aggregations expressions (count, min, max, avg and sum) on selectors (which can use wildcards) can be used.

As an example, this rule detects the removal of immutable file attributes on linux systems logged by auditd. The selection will evaluate logs where the field type equals ’EXECVE’, and a0 contains “chattr” and a1 contains “-i”. (a0 and a1 are both arguments to execv). If the condition (in this case, if selection evaluates to true) applies, the rule will trigger.

title: Remove Immutable File Attribute
id: a5b977d6-8a81-4475-91b9-49dbfcd941f7
description: Detects removing immutable file attribute
status: experimental
    - attack.defense_evasion
    - attack.t1222
author: Jakob Weinzettl,
date: 2019/09/23
    product: linux
    service: auditd
        type: 'EXECVE'
        a0|contains: 'chattr'
        a1|contains: '-i'
    condition: selection
    - Administrator interacting with immutable files (for instance backups)
level: medium


Selections and conditions can become very sophisticated, allowing fine grained control and evaluations. A more complex detection is given below, where it will trigger if the sum of the question lengths, grouped by src_ip within 1m meeting the “selection” criteria (on each dns query).

        query: '*'
    timeframe: 1m
    condition: selection | sum(question_length) by src_ip > 300000


The Sigma repository contains besides many rules, also sigmac, the sigma compiler. The sigma compiler compiles the Sigma rule to a different target system, e.g. Elasticsearch. If you want to play around with Sigma, it will be easiest to setup a docker container. As an example, we will use sigmac to compile the rule to an elasticsearch query, with as configuration of elk-windows resulting into the following query:

$ git clone
$ docker run -v $(pwd):/work python:3
$ cd /work/sigma
$ python tools/ install
$ tools/sigmac -I -t es-qs -c elk-windows ./rule.yaml
(type:"EXECVE" AND a0.keyword:*chattr* AND a1.keyword:*\-i*)


Another way to test and play with Sigma and the results it transforms into, is by using the website (powered by SOC Prime). can convert Sigma (and other rules and queries) to many different formats, allowing easy experimenting.


Remco Verhoef (@remco_verhoef)
ISC Handler - Founder of DutchSec


0 comment(s)
ISC Stormcast For Friday, June 19th 2020


eweew<a href="">mashood</a>
dwqqqwqwq mashood
[ |]
What's this all about ..?
password reveal .
<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission

Diary Archives