In this Article: |
Non-Agnostic User Profiles - Name
It is common for SIGMA authors to pull results from malware sandboxes and write detections against the command line arguments used by the malware. Commonly malware drops & executes artifacts from user profiles. However, we must anticipate that these user profiles will change. We must use a wildcard when specifying that artifacts will drop in user profiles. Unless that profile is the public profile.
Incorrect Example
In this example, an analyst meant to match on malware running from a user profile’s appdata\roaming folder. However, this will only match in environments where users are named “admin”.
title: Incorrect Non-Agnostic User Profile
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
Image|endswith: ‘\users\admin\appdata\roaming\malware.exe’
condition: selection
Correct Example
The corrected version of this rule will match on ANY user profile.
title: Correct Matches on Any User Profile
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
Image|endswith: ‘\appdata\roaming\malware.exe’
condition: selection
Non-Agnostic User Profiles - Security Identifier
Not nearly as common but still poses a similar problem is the use of Security Identifiers (SIDs). SIDs for user accounts are highly unique, when we maintain them in a rule we are limiting the rule to work for a single user account on a single workstation or domain.
Exclusions to this problem are rules that depend on “well known SIDs” for detection purposes. https://docs.microsoft.com/en-us/windows/win32/secauthz/well-known-sids
Incorrect Example - SID Specific
In this example, a SID belonging to the local system administrator account of a specific host means this rule will only work for a single user on a single machine.
title: Incorrect - SID Dependant Rule
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
TargetObject|contains: ‘\user\S-1-5-21-6841020553-7100022413-6101150552-500\Software\Microsoft\Windows\CurrentVersion\Run\’
condition: selection
Correct Example - SID Agnostic
In this corrected version of the rule, we’ve used a wildcard to allow the rule to match on any user’s SID.
title: Correct - SID Agnostic
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
TargetObject|contains: ‘\Software\Microsoft\Windows\CurrentVersion\Run\’
condition: selection
Not Using Existing Mappings
SIGMA takes advantage of named fields and via SIGMAC configurations the field names are updated to reflect those in use by the user. If we don’t use the existing mappings, then this automation breaks and users will either have to update their configurations or manually change the mappings after conversion.
Whenever possible we must use the existing mappings as defined in the taxonomy. https://github.com/Neo23x0/sigma/wiki/Taxonomy
Incorrect Example - Non-existent “Command” mapping used
In this example, the non-existent mapping “command” is used. “CommandLine” is already defined in the taxonomy.
title: New mapping “Command” used instead of “CommandLine”
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
Command|contains: ‘sekurlsa’
condition: selection
Correct Example - Correct “CommandLine” mapping used.
In the corrected example the correct field “CommandLine” is used.
title: CommandLine used correctly
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
CommandLine|contains: ‘sekurlsa’
condition: selection
‘Normal’ Windows Activity Accidentally Included
Incorrect Example - werfault included
Often the results of sandbox reports are made into SIGMA rules. Sometimes these rules include “normal” windows behavior such as “werfault.exe” being spawned. Certain executables such as “werfault.exe”, “conhost.exe” when executed from their normal locations can rarely be used in a detection without creating a massive amount of noise.
title: Normal “werfault” Activity Included
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
ParentImage|endswith:
- ‘\cmd.exe’
- ‘\powershell.exe’
Image|endswith:
- ‘\werfault.exe’
- ‘\ornerypegasus.exe’
- ‘\shortcarriage.exe’
- ‘\lingocontemporary.exe’
condition: selection
Correct Example
title: Normal Activity Excluded
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
ParentImage|endswith:
- ‘\cmd.exe’
- ‘\powershell.exe’
Image|endswith:
- ‘\ornerypegasus.exe’
- ‘\shortcarriage.exe’
- ‘\lingocontemporary.exe’
condition: selection
Drive letters
Not every Windows system is using the “C” drive as its “system drive”. For instance, it is common for Windows based web servers to use “D '' as the system drive. Therefore we should not limit rules by forcing them to use the “C” drive.
Incorrect Example: C as Drive
title: C as drive letter only
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
Image: ‘C:\users\\*\appdata\roaming\malware.exe’
condition: selection
Correct Example
title: any drive letter
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
Image|endswith: ‘\appdata\roaming\malware.exe’
condition: selection
Alerting on Innocuous Webserver/Proxy URI Paths, Queries, Etc.
Unfortunately, the SIGMA specification & taxonomy doesn’t have a field for matching on the contents of an HTTP POST/PUT body. c-uri and other webserver/proxy category fields do not contain any part of the HTTP POST/PUT request body. c-uri only contains the URI (e.g. https://example.com/example?a=example) requested by a client (e.g. Mozilla Firefox). These types of rules are better written in the Snort® Rule language.
There are some exceptions to this guidance:
Sometimes URI paths/queries are not innocuous or are generally rare-enough that the path/query itself can be used to trigger on a rule. Typically the only way to know if these paths are rarely accessed is to have a copy of the web server software in production to test rules.
Often exploits may have to repeatedly access a URI path/query in a unique way (e.g. an innocuous path is accessed 500 times in 1 minute by the same IP). When this is the case please use SIGMA correlations to more precisely identify probable exploit attempts.
Note: SOC Prime may rarely accept a rule that uses keywords to identify suspicious terms in the POST body, however this will be for only the most critical of exploits.
Example:
The following wireshark screenshot of a packet capture will be used to further describe the issue. The packet capture shows the contents of a “malicious” file uploaded to a web server via /info.php.
Incorrect Example
An incorrect approach is to flag only on the c-uri path /info.php. While /info.php may be exploitable, it will presumably mostly be used for legitimate purposes. Therefore, the path itself is innocuous and it is incorrect to create a rule with the logic c-uri|contains: /info.php.
title: Incorrect Webserver Rule Flagging on Innocuous Path
description: /info.php (an innocuous path) is being alerted on. This rule has been stripped down to minimal components.
logsource:
category: webserver
detection:
selection:
c-uri|contains: ‘/info.php’
condition: selection
Correct Example
In this example, writing a valid SIGMA rule is not possible.
Multi-Event Dependant SIGMA Rules Without Correlation
Often adversaries perform tasks that cause multiple correlatable events. For instance, we may care if net.exe, wmic.exe, and nltest.exe are executed on the same Windows host within one minute. SOC Prime supports detecting this via legacy correlations as defined by the SIGMA specification https://github.com/SigmaHQ/sigma-specification/blob/main/archives/wiki.md.
Incorrect Example
This example fails to use correlation logic, and assumes that SIGMA is able to automatically correlate events. This is not the case, without specifying the correlation this rule can’t work. No single event will contain the net.exe, wmic.exe, nltest.exe within the Image field.
title: Incorrect Correlated net.exe, wmic.exe, and nltest.exe
description: This incorrect example assumes net.exe, wmic.exe, and nltest.exe occur within one process_creation event. This rule has been stripped down to minimal fields.
logsource:
product: windows
category: process_creation
detection:
selection_net:
Image|endswith: '\net.exe'
selection_wmic:
Image|endswith: '\wmic.exe'
selection_nltest:
Image|endswith: '\nltest.exe'
condition: selection_net AND selection_wmic AND selection_nltest
Corrected Example
In this corrected example correlations are used to ensure 3 unique Image paths exist.
Challenge: Notice a fuller path is provided to net.exe, wmic.exe, and nltest.exe. Can you Identify why? Hint: syswow64
title: Correct Correlated net.exe, wmic.exe, and nltest.exe
description: This corrected rule takes advantage of correlation within SIGMA to obtain the desired trigger condition.
logsource:
product: windows
category: process_creation
detection:
selection_net:
Image|endswith: ':\windows\system32\net.exe'
selection_wmic:
Image|endswith: ':\windows\system32\wmic.exe'
selection_nltest:
Image|endswith: ':\windows\system32\nltest.exe'
timeframe: 1m
condition: selection_net OR selection_wmic OR selection_nltest | count(Image) by ComputerName > 2
Weak Rule Resilience
Adversaries have control over certain parts of a log. For instance, they can rename a file from the obvious “evil.exe” to something more benign “7za.exe”. Different parts of their tooling are more difficult to change than others. For instance, an open source tool can have parameters/arguments changed, but it takes a little more effort to do that. So, it is more useful to flag on unique arguments to a binary than it is to flag on the binary name. When possible rules should match on unique terms that are difficult to change, these rules are more resilient.
However, sometimes it is in our interest to decrease rule resilience to increase the rule availability. For instance, it may be better to write a rule without regular expressions even though the rule may end up being less resilient. This is because backend support for regular expressions isn’t universal.
Example:
The following rules are based off of the commonly abused freeware tool “WebBrowserPassView” by Nir Sofer:
Weak Rule Resilience Example
This rule can easily be evaded by changing the name of the executable.
title: Weak WebBrowserPassView Rule
description: This rule matches on an easily changed term. This rule has been stripped down to minimal fields.
logsource:
product: windows
category: process_creation
detection:
selection:
Image|endswith: '/webbrowserpassview.exe'
condition: selection
More Resilient Example
title: Resilient WebBrowserPassView Rule
description: This rule uses unique terms passed to WebBrowserPassView. Because the tool is not open source, it is more difficult for adversaries to change the terms WebBrowserPassView expects.
logsource:
product: windows
category: process_creation
detection:
selection:
Image|endswith: '/webbrowserpassview.exe'
selection2:
CommandLine|contains: 'LoadPasswords'
condition: selection or selection2
Unintentionally Escaped Wildcard
SIGMA allows for the use of * (asterisk) and ? (question mark) as wildcards. A common mistake is to accidentally escape these characters when their use as a wildcard was intended. Using a single \ (backslash) before an asterisk or question mark will cause it to be treated as the character instead of a wildcard. Instead, we must escape the trailing backslash with another backslash (\\* instead of \*).
Incorrect Example
In this example, an analyst meant to match on any user profile, but instead, they unintentionally escaped the wildcard character so that it will match an asterisk (*) literally.
title: Unintentional Escaped Wildcard Example
description: This rule has been stripped down to minimal fields to show the effect of unintentional escaped wildcards
detection:
selection:
Image|endswith: '\users\*\appdata\roaming\malware.exe'
condition: selection
Correct Example
In this corrected example we’ve correctly escaped the backslash before the wildcard so that the asterisk is treated as a wildcard.
title: Correct Wildcard Example
description: This rule has been stripped down to minimal fields to show the effect of unintentional escaped wildcards
detection:
selection:
Image|endswith: '\users\\*\appdata\roaming\malware.exe'
condition: selection
Rule Description Not Specifying Intent of the Rule
WARNING: It is a violation of copyright law to directly copy and paste a description from the original source without permission.
The description field within SIGMA should provide the rule user with context about the intention of the rule itself. For instance, rules are submitted containing relevant malware campaign information, but nothing about how the rule is intended to detect said campaign. Ensure the intention of the detection is clear in the rule description.
Incorrect Example - No Detection Intent
title: Bad Description of ShimmeringTurnip Detection
description: In May 2027, Acme Corp Released a report on ShimmeringTurnip, a commercial espionage campaign targeting various Lawn Mower Repair Businesses and Related Educational Institutions around the world.
Logsource:
product: linux
category: process_creation
detection:
selection:
CommandLine|contains: ‘-p’
selection_target_id:
CommandLine|re: ‘.*[A-Za-z\-\_]{4,40}[0,1]{0,1}[0-9]{0,1}202[4,5,6,7,8].*’
condition: selection AND selection_target_id
Correct Example - Detection Intent Described
In this corrected version of the rule, we’ve added the ‘contains’ transformation and the original intention of the rule has been met.
title: Complete Description of ShimmeringTurnip Detection
description: In May 2027, Acme Corp Released a report on ShimmeringTurnip, a commercial espionage campaign targeting various Lawn Mower Repair Businesses and Related Educational Institutions around the world. This detection is intended to find the malware IcedChaiLatte which according to Acme Corp accepts a password at execution to decrypt the malware. Several passwords are known and they all follow the format [TargetName][2 Digit Month]202X (e.g. Bens-Fine-Lawns042026).
Logsource:
product: linux
category: process_creation
detection:
selection:
CommandLine|contains: ‘-p’
selection_target_id:
CommandLine|re: ‘.*[A-Za-z\-\_]{4,40}[0,1]{0,1}[0-9]{0,1}202[4,5,6,7,8].*’
condition: selection AND selection_target_id
Matching on Randomly Generated Object Names
Malware will often create named objects (e.g. files, registry keys, pipes) within victim environments. The attacker often has complete control of what these object names will be and can set the names to random values upon execution of their malware. When reading reports on adversary activity, it is best to assume that random looking object names are randomly generated at execution. However, if the reporting indicates or the author is able to show that the “random” object names are consistent across multiple samples and execution environments, or are campaign specific, then it is fair to use these ‘random’ names.
Note: Sometimes the “random” object names will follow a pattern or be placed in an unusual path that can lead to a more acceptable detection.
Incorrect Example - Random File Object Name
A malware analysis sandbox service showed the file ‘ghn93opfj.txt’ being created in the directory ‘users\public\temp\’. The author wrote the below rule without performing additional analysis of the malware sample (reverse engineering the file creation) or reviewing sandbox logs of multiple samples & environments.
title: ShimmeringTurnip File Name Indicator July 2027
description: This rule has been stripped down to minimal fields
Logsource:
product: windows
category: file_event
detection:
selection:
TargetFilename|endswith: ‘:users\public\temp\ghn93opfj.txt’
condition: selection
Corrected Example - File Name & Path
A malware analysis sandbox service showed the file ‘ghn93opfj.txt’ being created in the directory ‘users\public\temp\’. After performing some reverse engineering, the author was able to identify that the path will always be “\users\public\temp” and that the file name will always follow a pattern that fits the regular expression ‘.*[a-z]{9}.txt’, which is unique enough to match on.
title: ShimmeringTurnip File Name Indicator July 2027
description: Shimmering Turnip HotChaiLatte malware was observed creating a dll file with the extension .txt using a detectable pattern in the relatively uncommon directory \users\public\temp.
Logsource:
product: windows
category: file_event
detection:
selection:
TargetFilename|re: ‘.*[a-z]{9}.txt’
selection_path:
TargetFilename|contains: ‘:\users\public\temp\’
condition: selection AND selection_path
Low Value Rules, Tired Behaviors, Short Lived Rules
There are certain behaviors that seem to be abused by malware campaigns over and over. Typically, these behaviors are already caught by a generic rule. However, sometimes the threat actor includes a unique term that uniquely identifies that they are the likely actor (e.g. a specific scheduled task name). These rules are not necessarily incorrect, but they will be judged with more scrutiny for their value. For instance, if a malware campaign is identified creating a unique scheduled task named “NotAnEvilTask” but that campaign is targeting a specific extremist cult leader in Fiji, then we will probably not accept the rule as relevant to SOC Prime’s customer base.
Here is a list of examples:
Scheduled Task Creation
Rundll32.exe/RegSrv32/etc launching unique Dynamic Link Library Name (e.g. evil.dll)
Run/RunOnce registry path creation
Service Creation
Discovery Commands/Utilities (Net, wmic, nltest, netstat, ipconfig, route, etc)
Anti-Recovery Utilities (bcdedit, vssadmin, etc)
Detecting Offensive Powershell by easily changed module names (Invoke-Mimikatz)
Forgotten Modifiers
Modifiers such as “contains” and “all” are very useful to simplify rule creation. However, if modifiers are intended to be used in the match but are not included in the field name the rule logic breaks entirely.
Incorrect Example - Forgotten Contains Transformation
In this rule the “contains” transformation is missing. Since no registry key begins with “\software” this rule should never hit.
title: Forgotten Transformation
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
TargetObject: ‘\Software\Microsoft\Windows\CurrentVersion\Run\’
condition: selection
Correct Example - Contains Transformation
In this corrected version of the rule, we’ve added the ‘contains’ transformation and the original intention of the rule has been met.
title: Transformation “contains” included
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
TargetObject|contains: ‘\Software\Microsoft\Windows\CurrentVersion\Run\’
condition: selection
Slash and Dash Interchangeability Bypass
Executables often accept slashes / and dashes - interchangeably even if the usage is not documented. Typically the slash or dash can be excluded entirely without affecting the intent of the rule. If this is the case for your rule, remove the slash/dash.
Incorrect Example - Incorrect Slashes Only
title: Whoami /all with slashes only
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
CommandLine|contains: ‘/all’
Image|endswith: ‘\whoami.exe’
condition: selection
Correct Example
title: Correct whoami slash/dash agnostic
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
CommandLine|contains: ‘all’
Image|endswith: ‘\whoami.exe’
condition: selection
Regular Expressions
The primary rule for regular expressions is to “keep it simple”. Regex support differs widely between platforms. You should attempt to keep your regular expressions to the standard operators. . ? + * {} | () [] ^ \ this will ensure reusability across platforms.
Incorrect Example
This regular expression will not work in databases using “lucene”.
title: Rule that uses more than standard operators
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
CommandLine|contains: '.*(?i)malware[0-9]\.exe.*'
condition: selection
Correct Example
This equivalent regular expression will work in any platform that supports regex.
title: Equivalent logic only using standard operators
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
CommandLine|re: ‘.*[Mm][Aa][Ll][Ww][Aa][Rr][Ee][0-9]\.[Ee][Xx][Ee].*’
condition: selection
Attacker’s Box Rules
The commands in this kind of rules are the commands run on the attacker's box (executed by the attacker's side) So they will never show up on the log source of the client.
Incorrect Example
In this example, the rule was made in order to detect the execution of Bad Blood tool (an exploit for CVE-2021-20038). If you look at the parameters, you’ll see that this specific tool tries to establish connection with victim’s machine, so the action occurs on adversarie’s side.
title: Bad Blood Usage on Attacker’s Box
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
CommandLine|contains|all:
- 'badblood'
- '--rhost'
- '--lhost'
condition: selection
Correct Example
In this corrected example we’ve used a tool that could be detected on the Victim's machine, so clients can use the content properly. In this case, the values are unique and related to Sharphound tool.
title: Possible Sharphound usage on Victim’s machine
description: This rule has been stripped down to minimal field as an example
detection:
selection:
CommandLine|contains:
- 'LDAPFilter'
- 'CollectionMethod'
- 'PortScanTimeout'
condition: selection
Kernel Paths & User Land Paths
There are two basic types of registry paths: Kernel Paths and User-land Paths. Kernel paths will be consistent, they do not use any kind of symbolic linking (more on this in user-land).
They always start with \REGISTRY\
They never use symbolic paths (CurrentControlSet)
User-land paths may NOT be consistent.
CurrentControlSet
Some datasources (such as Sysmon) use CurrentControlSet in place of ControlSet001
Others may not.
HKLM vs HKEY_LOCAL_MACHINE
These are links, and may be interchangeable depending on the dataset.
Example: These paths are 'equivalent' and all are possible depending basically only on the datasource:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\ThisIsAService - User land
HKLM\SYSTEM\ControlSet001\Services\ThisIsAService - User land
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ThisIsAService - User land
HKLM\SYSTEM\CurrentControlSet\Services\ThisIsAservice - User land
\REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\ThisIsAService - Kernel land
In order to make this path "agnostic" to all the possibilities it must be written as
TargetObject|endswith: \System\\*ControlSet*\Services\ThisIsAService
OR
TargetObject|endswith: \Services\ThisIsAService
Incorrect Example
In this example, the rule was made to put an example of incorrect use of CurrentControlSet.
title: Kernel Paths & Land Paths - Incorrect Usage
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
TargetObject|contains:
- '\System\ControlSet001\Services\ThisIsAService'
- '\System\CurrentControlSet\Services\ThisIsAService'
condition: selection
Correct Example
In this corrected example we’ll use wildcards to make those paths more “agnostics”.
title: Kernel Paths & Land Paths - Correct Usage
description: This rule has been stripped down to minimal field as an example
detection:
selection:
TargetObject|endswith:
- '\Services\ThisIsAService'
condition: selection
Ransomware Content
In this case, in order to make the rule approvable and useful, it’s important to consider creating content to cover ransomware behavior instead of encryption activity. This is because clients could use a good ransomware rule to detect previous steps before infection and they probably have an opportunity to avoid the action of being victims.
Incorrect Example - Encryption Activity Detection
In this rule we’ll detect encryption activity of a fake ransomware.
title: Ransomware File Encryption Activity
description: This rule has been stripped down to minimal fields as an example.
detection:
selection:
TargetFilename|endswith:
- '.myrans0m56'
condition: selection
Correct Example - Ransomware Activity
In this corrected version of the rule, we’ll detect ransomware activity in order to stay one step ahead of adversaries.
title: Suspicious Backup Service Stoppage
description: This rule has been stripped down to minimal fields as an example.
detection:
Selection:
Image|endswith:
- 'net1.exe'
- 'psservice.exe'
CommandLine|contains:
- 'stop'
- 'pause'
- 'disable'
condition: selection