HackBlue

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.

12 min read · practice only with authorization

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.

Snippet
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: high

Lab: 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.

Snippet
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

  1. Describe

    Write the behavior in plain words and find a reference.

  2. Rule

    Express it as logsource plus detection selections and a condition.

  3. Convert

    Translate with sigma-cli for your SIEM.

    Command
    sigma convert -t splunk -p sysmon rule.yml
  4. 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?