The parts of a Sigma rule

Sigma is a format for writing detection rules for log events. A rule says which log it applies to and which field values it looks for. Tools such as pySigma convert the same rule into the query language of a SIEM (Splunk, Microsoft Sentinel, QRadar, Elastic), so a rule is written once and used in several products. This site runs the rule directly on events in your browser.

A rule is a YAML document. The smallest useful rule has four parts:

title: mshta started
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: '\mshta.exe'
  condition: selection

• title: a short description of what the rule detects.
• logsource: which events the rule is about. product: windows with category: process_creation means "a process was started on Windows". On this site those are Sysmon Event ID 1 records.
• detection: one or more named searches (here selection) and a condition that combines them. A search is a set of field conditions; it matches an event when every condition in it is true.
• condition: which searches must match. With one search it is just its name.

Rules published in the Sigma repository also carry id (a UUID that stays the same when the rule is edited), status, description, author, date, references, tags, falsepositives and level. They do not change which events match; the last lesson covers them.

Reading the exercise

The table below the editor shows the events of the exercise: a few dozen process starts from real machines. Three of them are mshta.exe starts from an attack simulation; the rest are ordinary programs. Run rule shows how many of the three were caught and which other events matched. A matching ordinary event is a false positive.