Sigma standard

Sigma rule format description and examples.

Sigma Structure

Sigma rules are created following a specific structure made with attributes (or fields, sections). Only few sections are mandatory and others are optional, which make Sigma standard very flexible.

Full documentation about Sigma specification can be found on Sigma Wiki : https://github.com/Neo23x0/sigma/wiki/Specification

Required attributes

Title

Title should be short and security teams should be able to know what the rule is supposed to detect with this one.

ID

Each rules need a unique identifier to be identified globally. Random generated UUIDs (Version 4) are recommended but other IDs/Methods can be used.

uuidgen #Command to randomly generate a UUID

Logsource

Logsource is used to described one which logs the rule is meant too be applied. It contains 3 attributes for this purpose:

  • category: is used to described a category of product and is not vendor-specific. Ex: firewall, web-server, ids, ...

  • product: is used to described source logs from specific products. Ex: WinEventLog:Security, Cisco ASA, Snort, ...

  • service: is used to described logs from specific services. Ex: sshd, mysqld, ...

At least one of these 3 attributes are required in the Logsource section.

Nybble use "category" and/or "product" attributes to match rules with corresponding events. So at least "category" and/or "product" value need to be also included in events.

In this way events with their corresponding rules are distributed among workers. This ensures that only useful events are matched against their associated rules, better processing power utilization and load-balancing.

If both "category" and "product" attributes are used, Nybble will check if there are corresponding rules for the three combinations (category | product | category + product) and will be matched against corresponding events. More information in Configuration chapter.

Detection

Contains the search identifiers which are used to specify what need to be find in events. A search identifier can contain either maps or lists.

In the 'List' and 'Maps' examples, the search identifier is 'selection'.

List:

Values of lists are linked by logical 'OR' and check event field values.

In the following example, event field is "EventID", event values are "4624" and "4625", so match will be : (EventID == 4624 OR EventID == 4625).

detection:
selection:
EventID:
- 4624
- 4625

Maps:

Maps are Key/Value pair in which the key is an event field and the value is simply the value for the selected event field.

Each maps are linked by a logcial 'AND'. List of values in maps are linked by a logical 'OR'.

In the following example, there are 2 maps and 1 list of values, so match will be : (TargetUsername == 'hseldon' AND WorkstationName == 'trantor-server' AND (EventID == 4624 OR EventID == 4625)).

detection:
selection:
- TargetUserName: 'hseldon'
WorkstationName: 'trantor-server'
EventID:
- 4624
- 4625

Value modifiers

Values contained in Sigma rules can be modified by value modifiers.

There is two type of value modifiers:

  • Transformation modifiers: used to modify the value or operator type of a field (Base64 encoding, wildcard add-on, ...)

  • Type modifiers: change the type of value. Currently the only type modifiers is "re" used to change value type to regular expression.

Nybble isn't compatible with all value modifiers yet. Here is the list of modifiers handled by Nybble:

  • contains

  • all

  • base64

  • base64offset

  • endswith

  • startswith

  • re

Timeframe

A relative time frame definition using the typical abbreviations for day (ex: 7d), hour (ex: 1h), minute (ex: 15m), second (ex: 30s).

In Nybble context, Timeframe is mainly used in addition to aggregation expression.

Condition

Condition attribute specify how search identifers defined in the detection attribute will be use to be matched against events.

Condition attribute offer a lot of possibilities for matching :

  • Logical 'AND'/'OR' - Ex: selection and domain-controller and users

  • '1/all of' can be used to select one or all values in list - Ex: 1 of users

  • '1/all of them' can be used to specify if 1 or all search identifiers need to match.

  • '1/all of search-identifers pattern' same as '1/all of them' but restricted to a subset of search identifiers define by pattern - Ex: 1 of domain-controller*

  • 'not' can be used to negate a search identifier - Ex: not selection and 1 of users

  • '|' can be used to specify an aggregation expression after the condition expression.

  • '( )' can be used to modify the operators precedence - Ex: (selection AND 1 of users) OR 1 of domain-controller*

detection:
selection:
EventID: 4624
domain-controller1:
WorkstationName|endswith: '-dc'
domain-controller2:
WorkstationName|startswith: 'dc-'
users:
- 'hseldon'
- 'dolivaw'
- 'ebaley'

Aggregation expression:

As mentionned, it's possible to add an aggregation expression besides the condition expressions by using the '|' operator.

Aggregation expressions are composed of 5 parts :

  • Aggregation function: can be 'count', 'min', 'max', 'avg' or 'sum'.

  • Aggregation field: specify on which field the aggregation is done. Required for all function except 'count'. In case of empty field with count function, all match are count.

  • Group by field: specify which field is used to group aggregation by field. Group field is optional.

  • Comparison operator: can be '<', '>', '>=', '<=' or '='.

  • Aggregation value: target value to trigger alert.

The following aggregation make the sum of bytes out group by destination address and trigger when value is more than 20000.

condition: selection|sum(bytes_out) by dest_addr > 20000

Optional attributes

Author

Creator of the rule.

Description

Contains information about the rule, what it's supposed to be detected, information about threats or malicious activities corresponding to the rule.

FalsePositives

List of the known false positives for the rule.

Fields

List of the useful fields for analysis.

Nybble use rule map to automatically retrieve and include fields from list to the generated alerts.

Level

Severity/criticality level of the rule, value can be :

  • low

  • medium

  • high

  • critical

References

Links to blog posts, technical papers, Twitter posts with information about vulnerability, threat actors,.. associated to the rule.

Status

Specify the status of the rule. A rule can be in development, testing, tuning or stable.

Default status are :

  • experimental

  • test

  • stable

Tags

Tags can be applied on rules and are automatically added by Nybble in alerts. They can contain useful information like technology/product concerned by the rule or corresponding MITRE Attack information.

Sigma rule : single event

title: Local User Creation
id: 66b6be3d-55d0-4f47-9855-d69df21740ea
description: Detects local user creation on windows servers, which shouldn't happen in an Active Directory environment. Apply this Sigma Use Case on your windows
server logs and not on your DC logs.
status: experimental
tags:
- attack.persistence
- attack.t1136
references:
- https://patrick-bareiss.com/detecting-local-user-creation-in-ad-with-sigma/
author: Patrick Bareiss
date: 2019/04/18
logsource:
product: windows
service: security
detection:
selection:
EventID: 4720
condition: selection
fields:
- EventCode
- AccountName
- AccountDomain
falsepositives:
- Domain Controller Logs
- Local accounts managed by privileged account management tools
level: low

This is a simple rule without any aggregation that match on Windows EventLog Security each time a event with ID 4720 is seen.

Useful fields are "EventCode", "AccountName" and "AccountDomain". They will be mapped and then retrieved from events to be included in alert.

Listed false positive can help analysts to classify the alerts.

In case it's a true positive, tags can help to categorize and start the investigation.

Sigma rule : aggregation

title: Zeek HTTP and HTTPS data exflitration rule
id: fce81c05-75b0-447a-a791-2b9a75827d8f
status: experimental
description: Sum the number of destination.bytes for a unique destination.address and trigger an alert when threshold is exceeded.
tags:
- attack.exflitration
- attack.t1048
author: Sebastien Lehuede
level: high
logsource:
category: network_monitoring
product: zeek
detection:
selection:
dest_port: 443
event_dataset: 'zeek.connection'
timeframe: 5m
condition: selection|sum(bytes_out) by dest_addr > 20000
fields:
- dest_addr
- src_host
- src_address

This rule use an aggregation and trigger when the sum of 'bytes_out' by destination address is greater than 20000 in a 5 minutes window.

Sigma rules repo

Here is list of repositories or websites where Sigma rules are available :

Original project repo : https://github.com/Neo23x0/sigma/tree/master/rules

SOC Prime repo : https://tdm.socprime.com/

(This list is probably not complete, leave a comment if you know other repositories)

Sigma rules development and resources

Rules creation tutorial : https://www.nextron-systems.com/2018/02/10/write-sigma-rules/

SANS Summit : https://www.sans.org/cyber-security-summit/archives/file/summit-archive-1544043890.pdf

(This list is probably not complete, leave a comment if you know other development and training resources)