How to define what to look for.
If you missed last weeks post, take a look at crafting the
logsource section of a Sigma rule.
The most important part of a Sigma rule is the
detection section. The
detection section contains a set of search-identifiers that represent searches on log data and how they should be evaluated:
- Selections — What you actually wish to select/search from the log data (search identifier)
- Conditions — How should the selection or filters are to be evaluated
A definition can consist of two different data structures - lists and maps.
Lists are the simplest way to define a selection. They contain strings that are applied to the full log message and are linked with a logical ‘OR’.
List Example 1: Matches on ‘EvilService’ or ‘svchost.exe -n evil’ in a log line
detection: keywords: - EVILSERVICE - svchost.exe -n evil condition: selection1
Maps (or dictionaries) consist of key/value pairs, in which the key is a field in the log data and the value a string or integer value.
They are different to lists, because lists do not allow you to define the key (search field) on which you want to match.
Lists of maps are joined with a logical ‘OR’. All elements of a map are joined with a logical ‘AND’.
Map Example 1: Matches on Eventlog ‘Security’ AND (EventID=517 OR EventID=1102)
detection: selection1: - EventLog: Security EventID: - 517 - 1102 condition: selection1
Map Example 2: matches on Eventlog=’Security’ AND EventID=4679 AND TicketOptions=0x40810000 AND TicketEncryption=0x17
detection: selection1: - EventLog: Security EventID: 4769 TicketOptions: '0x40810000' TicketEncryption: '0x17' condition: selection1
Maps can be made more advanced through the use of value modifiers.
Map Example 3: matches on CommandLine CONTAINS (DumpCreds OR invoke-mimikatz)
detection: selection1: CommandLine|contains: - DumpCreds - invoke-mimikatz condition: selection1
Here, the selection (search-identifier) matches the CommandLine field in the log data and uses the transformation modifier (
|contains) in order to check if the listed keywords are present.
The condition field shown in the examples above has always been the same (
selection1). Essentially we are saying; the detection defined as
selection1 must be true for the rule to trigger.
Though we can also add more complex conditions. These can prove useful in tuning the accuracy a rule.
Map Example 4: matches on (CommandLine CONTAINS DumpCreds OR invoke-mimikatz) OR (CommandLine CONTAINS rpc OR token OR crypto) OR (CommandLine CONTAINS bitcoin)
detection: selection1: CommandLine|contains: - DumpCreds - invoke-mimikatz selection2: CommandLine|contains: - rpc - token - crypto selection3: CommandLine|contains: - bitcoin condition: 1 of them
Here the condition
1 of them means that one of the defined search identifiers (
selection3) must appear.
Conversely, you could use the condition
all of them, ensuring all search identifiers are matched before the rules is triggered.
Once you deploy a rule to one of your security tools, for example to your SIEM, analysts will probably start to discover some incorrect detections.
These false positive alerts can be dealt with in 2 ways:
- Update the rule with a more highly tuned detection. but if that is not possible;
- Update the rule with false positive information
Choosing the second option, the
falsepositive field can be used to describe a list of known false positives which can occur from a detection.
False positive Example 1:
falsepositives: - PIM (Privileged Identity Management) generates this event each time 'eligible role' is enabled.
Whatever of the two options selected, you can use versioning in SIEM Rules to define and track the changes to the Rule.
When triggered, this information can help an analyst triaging alerts as to how they proceed (or if they follow up on it at all).
Detections are the most complex part of a Sigma rule. Take a deeper look at the Sigma wiki for the selections and conditions available as you start to write more complex rules.
In the final part of this post series I’ll show you how to put it all together and import rules into your downstream security tools.
Join the Signals Corps on Discord
Join our public community of intelligence analysts and researchers sharing new content hourly.
Turn any blog into structured threat intelligence.
Extract machine readable intelligence from unstructured data.
Know when software you use is vulnerable, how it is being exploited, and how to detect an attack.
View, modify, and deploy SIEM rules for threat hunting.