Sigma
Documentation

Appearance

Sigma Modifiers ​

Introduced in 2019, Sigma modifiers were incorporated into the Sigma specification, allowing detection engineers to perform more complex operations on Sigma rules. These operations, including Regex, Boolean logic, and cidr notation, are supported by most SIEMs.

Overview ​

The values of given fields contained within Sigma rules can be changed using Value Modifiers. Value modifiers (or more simply, "modifiers") are appended after the field name with a pipe character | to each field you want to modify.

Example:

yaml
detection:
    selection:
        TargetFilename|endswith: '.cmdline'
splunk
TargetFilename="*.cmdline"

Modifiers can also be chained together to perform more complex operations.

Available Field Modifiers ​

Below is a list of available field modifiers.

all ​

yaml
title: Exchange ProxyShell exploitation attempt in web logs
logsource:
  category: webserver
detection:
  selection:
    c-uri|contains|all:
      - "/ecp/default.aspx"
      - "__VIEWSTATEGENERATOR="
      - "__VIEWSTATE="
  condition: selection
splunk
"c-uri"="*/ecp/default.aspx*" "c-uri"="*__VIEWSTATEGENERATOR=*" "c-uri"="*__VIEWSTATE=*"

Normally, lists of values are linked with OR in the generated query.
The all modifier changes this to AND.

This modifier is useful if you want to express a command line invocation with different parameters where the order may vary and removes the need for some cumbersome workarounds.

Note:

Single item values are not allowed to have an all modifier as some backends cannot support it. If you use it as a workaround to duplicate a field in a selection, use a new selection instead.

base64 / base64offset ​

yaml
title: Base64 shell usage in HTTP web traffic
logsource:
  product: linux
detection:
  selection:
    fieldname|base64offset|contains:
      - /bin/bash
      - /bin/sh
      - /bin/zsh
  condition: selection
splunk
fieldname="*L2Jpbi9iYXNo*" OR fieldname="*9iaW4vYmFza*" OR fieldname="*vYmluL2Jhc2*" OR fieldname="*L2Jpbi9za*" OR fieldname="*9iaW4vc2*" OR fieldname="*vYmluL3No*" OR fieldname="*L2Jpbi96c2*" OR fieldname="*9iaW4venNo*" OR fieldname="*vYmluL3pza*"

The base64 modifier-set will encode the provided values as base64 encoded strings. Often used alongside contains to identify malicious injection into applications.

This technique is often used by malicious actors to hide behaviour by executing commands, or sending HTTP parameters, using base64, sometimes preventing traditional detection methods.

Tip:

The base64offset modifier is usually preferred over the base64 modifier, because an ASCII value encoded into base64 can have 3 different offsets (or shifts) that can occur when completing the encoding process.

cased ​

yaml
title: Example of cased modifier
logsource:
  product: example
detection:
  selection:
    fieldname|cased: "CaseSensitiveValue"
  condition: selection
sql
SELECT * FROM <TABLE_NAME> WHERE fieldname GLOB 'CaseSensitiveValue' ESCAPE '\'

The cased modifier indicates that the value is applied in a case-sensitive manner. Sigma's default behavior is case-insensitive matching.

Not every backend supports case-sensitive matching

Some query languages — including Splunk SPL and Elasticsearch — have no native case-sensitive operator, so the cased modifier produces no additional query constraint there. Backends like SQL (GLOB) and Grafana Loki do honour it, which is why this example is restricted to those targets.

cidr ​

yaml
title: Example of cidr modifier with IPv4 subnets
logsource:
  product: example
detection:
  selection:
    first_ip_address|cidr: 192.0.0.0/8
    second_ip_address|cidr: 192.168.0.0/23
  condition: selection
splunk
first_ip_address="192.0.0.0/8" second_ip_address="192.168.0.0/23"
yaml
title: Example of cidr modifier with an IPv6 subnet
logsource:
  product: example
detection:
  selection:
    ipaddress|cidr: 2a03:2880:f132:83:face:b00c::/96
  condition: selection
splunk
ipaddress="2a03:2880:f132:83:face:b00c::/96"

The cidr modifier allows for CIDR-formatted subnets to be used as field values, where any IPv4 or IPv6 addresses are supported.

contains ​

yaml
title: Example of contains modifier
logsource:
  product: example
detection:
  selection:
    fieldname|contains: needle
  condition: selection
splunk
fieldname="*needle*"

The contains modifier will insert a wildcard token (usually *) around the provided value(s), such that the value is matched anywhere in the field.

endswith ​

yaml
title: Example of endswith modifier
logsource:
  product: example
detection:
  selection:
    fieldname|endswith: needle
  condition: selection
splunk
fieldname="*needle"

The endswith modifier will insert a wildcard token (usually *) at the start of the provided value(s), such that the value is matched at the end of the field.

exists ​

yaml
title: Administrator Usage
logsource:
  product: windows
detection:
  selection:
    user|exists: true
  condition: selection
text
user exists
yaml
title: Administrator Usage
logsource:
  product: windows
detection:
  selection:
    user|exists: false
  condition: selection
text
user !exists

The exists modifier will generate a query to check if fieldname exists. The value for the modifier can either be true or false. Setting the value to false will result in a not exists query.

expand ​

yaml
name: value_placeholder_pipeline
vars:
  administrator_name: Administrator
transformations:
  - type: value_placeholders
yaml
title: Administrator Usage
logsource:
  product: windows
detection:
  selection:
    user|expand: "%administrator_name%"
  condition: selection
splunk
user="Administrator"

The expand modifier can be used with Sigma Pipelines in order to replace placeholder values with another value common across that processing pipeline.

fieldref ​

yaml
title: Example of fieldref modifier
logsource:
  product: example
detection:
  selection:
    fieldname|fieldref: fieldasString
  condition: selection
splunk
*
| where 'fieldname'='fieldasString'

The fieldref mofidier will convert a plain string into a field reference. fieldname and fieldasString must have the same value. A field reference can be used to compare fields of matched events directly at query/matching time.

gt ​

yaml
title: Example of gt modifier
logsource:
  product: example
detection:
  selection:
    fieldname|gt: 15
  condition: selection
splunk
fieldname>15

The gt modifier will provide a search where the value of fieldname is greater than the value provided.

gte ​

yaml
title: Example of gte modifier
logsource:
  product: example
detection:
  selection:
    fieldname|gte: 15
  condition: selection
splunk
fieldname>=15

The gte modifier will provide a search where the value of fieldname is greater than or equal to the value provided.

lt ​

yaml
title: Example of lt modifier
logsource:
  product: example
detection:
  selection:
    fieldname|lt: 15
  condition: selection
splunk
fieldname<15

The lt modifier will provide a search where the value of fieldname is less than the value provided.

lte ​

yaml
title: Example of lte modifier
logsource:
  product: example
detection:
  selection:
    fieldname|lte: 15
  condition: selection
splunk
fieldname<=15

The lte modifier will provide a search where the value of fieldname is less than or equal to the value provided.

re ​

yaml
title: Example of re (regex) modifier
logsource:
  product: example
detection:
  selection:
    fieldname|re: .*needle$
  condition: selection
splunk
*
| regex fieldname=".*needle$"

The re modifier will provide a search where the value of fieldname matches the provided regex.

There are re sub-modifiers re|?:

  • i: (insensitive) to enable case-insensitive matching.
  • m: (multi line) to match across multiple lines. ^/$ match the start/end of line.
  • s: (single line) to enable that dot (.) matches all characters, including the newline character.

startswith ​

yaml
title: Example of startswith modifier
logsource:
  product: example
detection:
  selection:
    fieldname|startswith: needle
  condition: selection
splunk
fieldname="needle*"

The startswith modifier will insert a wildcard token (usually *) at the end of the provided value(s), such that the value is matched at the beginning of the field.

utf16 / utf16le / utf16be / wide ​

yaml
title: Example of wide (utf16) modifier
logsource:
  product: example
detection:
  selection:
    CommandLine|wide|base64offset|contains: "ping"
  condition: selection
splunk
CommandLine="*cABpAG4AZw*" OR CommandLine="*AAaQBuAGcA*" OR CommandLine="*wAGkAbgBnA*"

Prepends a byte order mark and encodes UTF16, (only used in combination with base64 modifiers)

Don't end with utf16, utf16le, utf16be or wide

The value modifier chain must not end with character set encoding modifiers (utf16, utf16le, utf16be and wide). The resulting values are internally represented as byte sequences instead of text strings and contain null characters which are usually difficult to handle in queries. Therefore the should be followed by an encoding modifier (base64, base64offset)

windash ​

yaml
title: Example of windash modifier
logsource:
  product: example
detection:
  selection:
    fieldname|windash|contains:
      - " -param-name "
      - " -f "
  condition: selection
splunk
fieldname="* -param-name *" OR fieldname="* /param-name *" OR fieldname="* –param-name *" OR fieldname="* —param-name *" OR fieldname="* ―param-name *" OR fieldname="* -f *" OR fieldname="* /f *" OR fieldname="* –f *" OR fieldname="* —f *" OR fieldname="* ―f *"

The windash modifier will convert any provided command-line arguments or flags to use -, as well as /, – (En Dash), — (Em Dash), and ― (Horizontal Bar).

This is incredibly useful in the the Windows ecosystem, where Windows has two standards for passing arguments to commands, usually - for PowerShell (e.g. -a), and / for cmd.exe (e.g. /a), but a large number of commands will commonly accept both. Many tools, including PowerShell, will not only accept a normal hyphen, but other similar looking dashes like – (En Dash), — (Em Dash), and ― (Horizontal Bar)

Copyright © 2020-present SigmaHQ