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
Title should be short and security teams should be able to know what the rule is supposed to detect with this one.
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 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.
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.
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 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
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:
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 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: 4624domain-controller1:WorkstationName|endswith: '-dc'domain-controller2:WorkstationName|startswith: 'dc-'users:- 'hseldon'- 'dolivaw'- 'ebaley'
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
Creator of the rule.
Contains information about the rule, what it's supposed to be detected, information about threats or malicious activities corresponding to the rule.
List of the known false positives for the rule.
List of the useful fields for analysis.
Nybble use rule map to automatically retrieve and include fields from list to the generated alerts.
Severity/criticality level of the rule, value can be :
Links to blog posts, technical papers, Twitter posts with information about vulnerability, threat actors,.. associated to the rule.
Specify the status of the rule. A rule can be in development, testing, tuning or stable.
Default status are :
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.
title: Local User Creationid: 66b6be3d-55d0-4f47-9855-d69df21740eadescription: Detects local user creation on windows servers, which shouldn't happen in an Active Directory environment. Apply this Sigma Use Case on your windowsserver logs and not on your DC logs.status: experimentaltags:- attack.persistence- attack.t1136references:- https://patrick-bareiss.com/detecting-local-user-creation-in-ad-with-sigma/author: Patrick Bareissdate: 2019/04/18logsource:product: windowsservice: securitydetection:selection:EventID: 4720condition: selectionfields:- EventCode- AccountName- AccountDomainfalsepositives:- Domain Controller Logs- Local accounts managed by privileged account management toolslevel: 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.
title: Zeek HTTP and HTTPS data exflitration ruleid: fce81c05-75b0-447a-a791-2b9a75827d8fstatus: experimentaldescription: Sum the number of destination.bytes for a unique destination.address and trigger an alert when threshold is exceeded.tags:- attack.exflitration- attack.t1048author: Sebastien Lehuedelevel: highlogsource:category: network_monitoringproduct: zeekdetection:selection:dest_port: 443event_dataset: 'zeek.connection'timeframe: 5mcondition: selection|sum(bytes_out) by dest_addr > 20000fields:- 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.
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)
Rules creation tutorial : https://www.nextron-systems.com/2018/02/10/write-sigma-rules/
(This list is probably not complete, leave a comment if you know other development and training resources)