Tools · SIEM and detection engineering · 06 / 24
Sigma rules tutorial: writing vendor-neutral detections in YAML
Learn the structure of a Sigma rule, write one for a suspicious process pattern, and understand logsource, detection selections, conditions, and false positive notes.
Why Sigma
Sigma is an open, generic signature format for log-based detections. A rule describes what to look for in terms of a log source and field values, and converters translate it into Splunk SPL, Microsoft Sentinel KQL, Elastic queries, and many other backends. That lets teams share detections without sharing SIEM-specific syntax. The SigmaHQ repository contains thousands of community rules.
Structure of a rule
title, id (a UUID), status, description, references, author, and date describe the rule. logsource names the product, category, or service, such as product: windows, category: process_creation. detection contains named selections of field-value maps and a condition that combines them. falsepositives and level help analysts triage. Field modifiers such as |contains, |endswith, |startswith, and |re change how a value matches; a list of values means OR.
title: Certutil Used to Download a File
id: 6d7a2b1e-4a1f-4c8e-9a3b-2f0c5d1e7a90
status: experimental
description: Detects certutil.exe with URL cache arguments, often used to fetch files.
references:
- https://attack.mitre.org/techniques/T1105/
author: HackBlue lab
date: 2026-11-02
tags:
- attack.command_and_control
- attack.t1105
logsource:
product: windows
category: process_creation
detection:
selection_img:
Image|endswith: '\certutil.exe'
selection_args:
CommandLine|contains:
- 'urlcache'
- 'verifyctl'
condition: selection_img and selection_args
falsepositives:
- Administrators using certutil for certificate tasks with URL fetches
level: highLab: write and validate
Write a rule for a behavior you can safely reproduce in a lab VM, such as whoami.exe launched by a web server process, or the certutil example above. Validate the YAML with sigma-cli’s check command, then convert it to a backend you use. Compare the output query with the rule to understand how modifiers become query syntax.
pip install sigma-cli sigma plugin install splunk sigma plugin install microsoft365defender sigma check rules/certutil_download.yml sigma convert -t splunk -p sysmon rules/certutil_download.yml sigma convert -t microsoft365defender rules/certutil_download.yml
Writing good rules
Describe one behavior per rule. Prefer fields that are hard to change, such as parent-child relationships and specific arguments, over file names alone. Document known false positives honestly and include ATT&CK tags so coverage can be measured. Set status to experimental until the rule has run in production without surprises.
Diagram
From behavior to deployed query
- Describe
Write the behavior in plain words and find a reference.
- Rule
Express it as logsource plus detection selections and a condition.
- Convert
Translate with sigma-cli for your SIEM.
sigma convert -t splunk -p sysmon rule.yml
- Test and tune
Run against lab data and production history; record false positives.
Check yourself
1. Which part of a Sigma rule says which kind of log the rule applies to?
2. A field in a selection has a list of three values. How are they combined?
3. Which tool translates a Sigma rule into a SIEM query?