The rules consist of a few required sections and several optional ones.
title
id [optional]
name [optional]
related [optional]
- type {type-identifier}
id {rule-id}
taxonomy [optional]
status [optional]
description [optional]
license [optional]
references [optional]
author [optional]
date [optional]
modified [optional]
logsource
category [optional]
product [optional]
service [optional]
definition [optional]
...
detection
{search-identifier} [optional]
{string-list} [optional]
{map-list} [optional]
{field: value} [optional]
...
condition
fields [optional]
falsepositives [optional]
level [optional]
tags [optional]
scope [optional]
...
[arbitrary custom fields]
The rule files are written in yaml format In order to keep the rules interoperable use the following:
' . If the string contains a single quote, double quotes may be used instead.Below is a simple Sigma rule example:
title: Whoami Execution
description: Detects a whoami.exe execution
references:
- https://speakerdeck.com/heirhabarov/hunting-for-privilege-escalation-in-windows-environment
author: Florian Roth
date: 2019-10-23
logsource:
category: process_creation
product: windows
detection:
selection:
Image: 'C:\Windows\System32\whoami.exe'
condition: selection
level: high
To keep the file names interoperable use the following:
_ instead of a space.yml as a file extensionexample:
lnx_auditd_change_file_time_attr.ymlweb_cve_2022_33891_spark_shell_command_injection.ymlsysmon_file_block_exe.ymlThe Json schema is defined in sigma-detection-rule-schema.json. Check it out for additional details on the required fields, their types and other information.
Attribute: title
Use: mandatory
A brief title for the rule that should contain what the rule is supposed to detect (max. 256 characters)
Attributes: id, related
Use: optional
Sigma rules should be identified by a globally unique identifier in the id attribute.
For this purpose randomly generated UUIDs (version 4) is used.
An example for this is:
title: Test rule
id: 929a690e-bef0-4204-a928-ef5e620d6fcc
It is better to write a rule with a new id for the following reasons:
To be able to keep track of the relationships between detections, Sigma rules may also contain
references to related rule identifiers in the related attribute.
This allows to define common relationships between detections as follows:
related:
- id: 08fbc97d-0a2f-491c-ae21-8ffcfd3174e9
type: derived
- id: 929a690e-bef0-4204-a928-ef5e620d6fcc
type: obsolete
Currently the following types are defined:
derived: The rule was derived from the referred rule or rules, which may remain active.obsolete: The rule obsoletes the referred rule or rules, which aren’t used anymore.merged: The rule was merged from the referred rules. The rules may still exist and are in use.renamed: The rule had previously the referred identifier or identifiers but was renamed for whatever
reason, e.g. from a private naming scheme to UUIDs, to resolve collisions etc. It’s not
expected that a rule with this id exists anymore.similar: Use to relate similar rules to each other (e.g. same detection content applied to different log sources, rule that is a modified version of another rule with a different level)Attribute: name
Use: optional
name is a unique human-readable name that can be used instead of the id as a reference in correlation rules.
The goal is to improve the readability of correlation rules.
Attribute: taxonomy
Use: optional
Defines the taxonomy used in the Sigma rule. A taxonomy can define:
process_command_line instead of CommandLine.image_file_name that only contains a file name like example.exe and is transformed into ImageFile: *\\example.exe.category: ProcessCreation instead of category: process_creationThe Default taxonomy is sigma. A custom taxonomy must be handled by the used tool or transformed into the default taxonomy.
More information on the default taxonomy can be found in the Sigma Taxonomy Appendix file.
Attribute: status
Use: optional
Declares the status of the rule:
stable: the rule is considered as stable and may be used in production systems or dashboards.test: a mostly stable rule that could require some slight adjustments depending on the environement.experimental: an experimental rule that could lead to false positives results or be noisy, but could also identify interesting
events.deprecated: the rule is replaced or covered by another one. The link is established by the related field.unsupported: the rule cannot be use in its current state (old correlation format, custom fields)Attribute: description
Use: optional
A short and accurate description of the rule and the malicious or suspicious activity that can be detected (max. 65,535 characters)
Attribute: license
Use: optional
License of the rule according the SPDX ID specification.
Attribute: author
Use: optional
Creator of the rule. (can be a name, nickname, twitter handle…etc)
If there is more than one, they are separated by a comma.
Attribute: reference
Use: optional
References to the sources that the rule was derived from.
These could be blog articles, technical papers, presentations or even tweets.
Attribute: date
Use: optional
Creation date of the rule.
Use the ISO 8601 date with separator format : YYYY-MM-DD
Attribute: modified
Use: optional
Last modification date of the rule.
Use the ISO 8601 date with separator format : YYYY-MM-DD
Reasons to change the modified date:
deprecatedAttribute: logsource
Use: mandatory
This section describes the log data on which the detection is meant to be applied to.
It describes the log source, the platform, the application and the type that is required in the detection.
It consists of three attributes that are evaluated automatically by the converters and an arbitrary number of optional elements.
We recommend using a “definition” value in cases in which further explanation is necessary.
The category value is used to select all log files written of a logical group.
This may cover one or more sources of information depending on the system.
e.g. “antivirus” for the scan result, “webserver” for the web access logs.
The product value is used to select all log outputs of a certain product.
It can be as generic as an operating system or the name of a particular software package.
e.g. “windows” will include “Security”, “System”, “Application” and the other like “AppLocker” and “Windows Defender”…
The service value is used to select a more specific subset of logs.
e.g. “sshd” on Linux or the “Security” Eventlog on Windows systems.
The definition can be used to describe the log source, including some information on the log verbosity level or configurations that have to be applied.
It is not automatically evaluated by the converters but gives useful information to readers on how to configure the source to provide the necessary events used in the detection.
The category, product and service can be used alone or in any combination.
Their values are in lower case and spaces are replaced by a _ , characters . and - are allowed.
service: systemcategory: process_creationservice: onelogin.eventsservice: firewall-asYou can use the values of category, product and service to point the converters to a certain index.
In the configuration files, it can be defined that the category firewall converts to ( index=fw1* OR index=asa* ) during Splunk search conversion or the product windows converts to "_index":"logstash-windows*" in Elasticsearch queries.
The advantages of this abstract approach is that it does not limit the rule to a specific telemetry source.
Instead creating multiple rules for the different telemetry sources such as Sysmon, Microsoft-Windows-Security-Auditing, Microsoft-Windows-Kernel-Process and all the other possible product-specific sources, a generic log source may be used.
e.g.:
category: process_creation
product: windows
More details can be found in the Sigma Taxonomy Appendix file, and SigmaHQ Logsource Guides
Attribute: detection
Use: mandatory
A set of search-identifiers that represent properties of searches on log data.
A definition that can consist of two different data structures - lists and maps.
* and ? in strings (see also escaping section below).'.Wildcards are used when part of the text is random. You can use :
? to replace a single mandatory character.* to replace an unbounded length wildcard.example:
progA.exe or progB.exe or ... will be prog?.exeantivirus_V1.exe or antivirus_V21.2.1.exe or ... will be antivirus_V*.exeSigma has special modifiers to facilitate the search of unbounded strings
*something see endswith modifier.something* see startswith modifier.*something* see contains modifier.The backslash character \ is used for escaping of wildcards * and ? as well as the backslash character itself. Escaping of the backslash is necessary if it is followed by a wildcard depending on the desired result.
Summarized, these are the following possibilities:
\ or double backslash \\. For simplicity reasons the single notation is recommended.\*, \?.\\*.\\\*.\\\\ results in the plain value \\.Lists can contain:
Example for list of strings: Matches on ‘EvilService’ or ‘svchost.exe -n evil’
detection:
keywords:
- 'EVILSERVICE'
- 'svchost.exe -n evil'
Example for list of maps:
detection:
selection:
- Image|endswith: '\\example.exe'
- Description|contains: 'Test executable'
The example above matches an image value ending with example.exe or an executable with a description containing the string Test executable.
Maps (or dictionaries) consist of key/value pairs, in which the key is a field in the log data and the value is a string or integer value. All elements of a map are joined with a logical ‘AND’.
Examples:
The example below, matches on EventLog ‘Security’ and ( Event ID 517 or Event ID 1102 )
detection:
selection:
EventLog: Security
EventID:
- 517
- 1102
condition: selection
Matches on Eventlog ‘Security’ and Event ID 4679 and TicketOptions 0x40810000 and TicketEncryption 0x17
detection:
selection:
EventLog: Security
EventID: 4769
TicketOptions: '0x40810000'
TicketEncryption: '0x17'
condition: selection
Below is an example mapping sigma taxonomy name to built-in windows events:
fieldmappings:
Image: NewProcessName
ParentImage: ParentProcessName
Details: NewValue
ParentCommandLine: ProcessCommandLine
LogonId: SubjectLogonId
Example:
New Value -> NewValueSAM User Account -> SAMUserAccount<System> header of the events). The tag and attribute names have to be linked with an underscore character ‘_’.<EventData> body of the event the field name is given by the Name attribute of the Data tag.Examples i:
<Provider Name="Service Control Manager" Guid="[...]" EventSourceName="[...]" /> will be Provider_Name will be Execution_ProcessID`Examples ii:
<Data Name="User">NT AUTHORITY\SYSTEM</Data> will be User<Data Name="ServiceName">MpKsl4eaa0a76</Data> will be ServiceNameThere are special field values that can be used.
''nullThe application of these values depends on the target SIEM system.
To get an expression that say not null you have to create another selection and negate it in the condition.
Example:
detection:
selection:
EventID: 4738
filter:
PasswordLastSet: null
condition: selection and not filter
In some case a field can be optional in the event. You can use the exists modifiers to check it.
Example:
detection:
selection:
EventID: 4738
PasswordLastSet|exists: true
condition: selection
The values contained in Sigma rules can be modified by value modifiers. Value modifiers are
appended after the field name with a pipe character | as separator and can also be chained, e.g.
fieldname|mod1|mod2: value. The value modifiers are applied in the given order to the value.
There are two types of value modifiers:
Generally, value modifiers work on single values and value lists. A value might also expand into multiple values.
Placeholders are used as values that get their final meaning at conversion or usage time of the rule. This can be, but is not restricted to:
%Servers% is replaced with
the pattern srv* because servers are named so in the target environment.%servers% with a lookup expression LOOKUP(field, servers)
that looks up the value of field in a lookup table servers.From Sigma 1.1 placeholders are only handled if the expand modifier is applied to the value containing the placeholder. A plain percent character can be used by escaping it with a backslash. Examples:
field: %name% handles %name% as literal value.field|expand: %name% handles %name% as placeholder.field|expand: \%plain%name% handles %plain as plain value and %name% as placeholder.Placeholders must be handled appropriately by a tool that uses Sigma rules. If the tool isn’t able to handle placeholders, it must reject the rule.
The following standard placeholders should be used:
%Administrators%: Administrative user accounts%JumpServers%: Server systems used as jump servers%Workstations%: Workstation systems%Servers%: Server systems%DomainControllers%: Domain controller systemsCustom placeholders can be defined as required.
Contrary to the Field Usage, It’s a matter of searching for keywords across an entire event.
They are built by using a list under a search-identifiers.
detection:
mimikatz_keywords:
- 'event::clear'
- 'event::drop'
condition: mimikatz_keywords
Give : “event::clear” or “event::drop”
To have a and operator , we use the '|all': modifier
detection:
keywords_cmdlet:
'|all':
- 'OabVirtualDirectory'
- ' -ExternalUrl '
condition: keywords_cmdlet
Give : “OabVirtualDirectory” and “ -ExternalUrl “
Some rules use simply keywords as search-identifiers name to facilitate identification.
Attribute: condition
Use: mandatory
The condition is the most complex part of the specification and will be subject to change over time and arising requirements. In the first release it will support the following expressions.
Logical AND/OR
keywords1 or keywords2
1/all of them
Logical OR (1 of them) or AND (all of them) across all defined search identifiers not starting with an underscore _. The search identifiers
themselves are logically linked with their default behavior for maps (AND) and lists (OR).
The usage of all of them is discouraged, as it prevents the possibility of downstream users of a rule to generically filter unwanted matches. See all of {search-identifier-pattern} in the next section as the preferred method.
Example: 1 of them means that one of the defined search identifiers must appear. A search identifier _example
wouldn’t be included because detections starting with underscores are excluded by convention.
1/all of search-identifier-pattern
Same as 1/all of them, but restricted to matching search identifiers. Matching is done with * wildcards (any number of characters) at arbitrary positions in the pattern.
Examples:
all of selection*1 of selection* and keywords1 of selection* and not 1 of filter*Negation with ‘not’
keywords and not filters
Brackets
selection1 and (keywords1 or keywords2)
Operator Precedence (least to most binding)
The condition can be a list, in this case, each of them generates a query They are logically linked with OR.
Attribute: fields
Use: optional
A list of log fields that could be interesting in further analysis of the event and should be displayed to the analyst.
Attribute: falsepositives
Use: optional
A list of known false positives that may occur.
Attribute: level
Use: optional
The level field contains one of five string values. It describes the criticality of a triggered rule. While low and medium level events have an informative character, events with high and critical level should lead to immediate reviews by security analysts.
informational: Rule is intended for enrichment of events, e.g. by tagging them. No case or alerting should be triggered by such rules because it is expected that a huge amount of events will match these rules.low: Notable event but rarely an incident. Low rated events can be relevant in high numbers or combination with others. Immediate reaction shouldn’t be necessary, but a regular review is recommended.medium: Relevant event that should be reviewed manually on a more frequent basis.high: Relevant event that should trigger an internal alert and requires a prompt review.critical: Highly relevant event that indicates an incident. Critical events should be reviewed immediately. It is used only for cases in which probability borders certainty.Attribute: tags
Use: optional
A Sigma rule can be categorized with tags. Tags should generally follow this syntax:
Attribute: scope
Use: optional
A list of the intended scopes of the rule. This would allow you to define if a rule is meant to trigger on specific set of types of machines that might have a specific software installed.
For example , if you have a rule for a registry key being set, where the key only exists on windows server installations./
A scope with the value server can be added to limit this rule only to Windows Servers.
Correlation allows several events to be linked together. To make it easier to read these corelation rules, they are written in meta-rules.
Check out the Sigma Correlation Rules Specification for more details.
To adapt the rules to the environment, it is sometimes useful to put the same exclusion in several rules. / Their maintenance can become difficult, with a meta-filter it is possible to write it in a single place.
Check out the Sigma Filters Specification for more details.