SIEM Detection Rules schreiben: Von Sigma zu KQL und SPL

Die meisten SIEMs werden mit Default-Rules ausgeliefert, die entweder zu viele False Positives erzeugen oder einfach nie ausgelöst werden. Effektive Detection Engineering ist eine Disziplin: sie kombiniert Kenntnis aktueller Angriffstechniken, Verständnis der eigenen Infrastruktur und Messung von Alert-Qualität. Das Ziel ist nicht die maximale Anzahl an Rules - es ist die maximale Signal-to-Noise-Ratio.

Detection Engineering Framework

Systematischer Ansatz zu Detection Rules:

Schritt 1: Threat Modeling
  Fragen:
  → Welche Threat Actors greifen unsere Branche an?
    (Dragos, Mandiant, CrowdStrike Threat Reports!)
  → Welche TTPs nutzen diese Akteure?
    (MITRE ATT&CK Groups: groups.mitre.org)
  → Was sind unsere wertvollsten Assets?
  → Welche TTPs könnten diese Assets gefährden?

  Ergebnis: Priorisierte Liste von ATT&CK-Techniken

Schritt 2: Datenquellen kartieren
  MITRE ATT&CK → Datenquellen:
  T1078 Valid Accounts → Windows Security Event Log (4624, 4625)
  T1059.001 PowerShell → Windows PowerShell Logs (4103, 4104)
  T1003.001 LSASS Memory → Sysmon Event 10 (ProcessAccess)
  T1021.001 Remote Services RDP → Windows Security (4648, 4624 Type 10)

  Tool: ATT&CK Navigator Layering
  → attack.mitre.org/resources/attack-navigator
  → Zellen einfärben nach: "haben wir Datenquelle" und "haben wir Rule"

Schritt 3: Rule schreiben und testen
  → Sigma als primäres Format (vendor-agnostisch)
  → Konvertieren in SIEM-spezifisches Format (KQL, SPL, YARA-L)
  → Testen: echte Angriffssimulation (Atomic Red Team)

Schritt 4: Tuning (False Positives reduzieren)
  → Alert läuft 2 Wochen → wie viele FP?
  → Ausschlüsse hinzufügen (bekannte gute Prozesse, IT-Systeme)
  → Threshold anpassen: 1 Event vs. 10 Events in 5 Minuten

Schritt 5: Dokumentation
  → Rule Purpose: welche Technik wird detected?
  → Expected False Positives: was löst diese Rule auch aus?
  → Response: was macht der Analyst wenn Alert ausgelöst?

Sigma Rules (Vendor-agnostisches Format)

Sigma = "YARA für Logs" - einmal schreiben, überall nutzen

Sigma-Struktur:

title: Suspicious PowerShell Encoded Command Execution
id: a9c23a37-1f3c-4bec-bc3f-3d0fcc81b6a0
status: stable
description: Detectiert PowerShell-Ausführung mit Base64-kodierten Commands
  - häufig für Obfuskation genutzt
references:
  - https://attack.mitre.org/techniques/T1027/
author: AWARE7 Team
date: 2026/03/04
tags:
  - attack.execution
  - attack.t1059.001
  - attack.defense_evasion
  - attack.t1027
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine|contains:
      - '-EncodedCommand'
      - '-enc '
      - '-ec '
  filter_legitimate:
    ParentImage|endswith: '\WindowsPowerShell\v1.0\powershell.exe'
    CommandLine|contains: 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
  condition: selection and not filter_legitimate
falsepositives:
  - Administratoren die legitim Encoded-Commands nutzen
  - Software-Deployment-Systeme (SCCM, Intune)
  - Chocolatey Package Manager
level: medium

---

Konvertierung mit sigmac (pySigma):
  # Installation:
  pip install pysigma pysigma-backend-splunk pysigma-backend-microsoft365defender

  # Zu KQL (Microsoft Sentinel) konvertieren:
  sigma convert -t microsoft365defender rule.yml

  # Zu SPL (Splunk) konvertieren:
  sigma convert -t splunk rule.yml

  # Zu QRadar AQL konvertieren:
  sigma convert -t qradar rule.yml

KQL für Microsoft Sentinel

KQL (Kusto Query Language) - Grundlagen und Security-Anwendungen:

Basis-Syntax:
  TableName
  | where TimeGenerated > ago(24h)          // Zeitfilter
  | where EventID == 4625                    // Filter
  | summarize count() by Account            // Aggregation
  | order by count_ desc                    // Sortierung
  | take 10                                 // Limit

Detection Rule: Brute Force Angriff (T1110):
  SecurityEvent
  | where TimeGenerated > ago(1h)
  | where EventID == 4625  // Failed Logon
  | summarize FailedAttempts = count(),
              UniqueAccounts = dcount(TargetAccount),
              SourceIPs = make_set(IpAddress)
    by Computer, IpAddress
  | where FailedAttempts > 20  // Threshold: 20 Fehlversuche
  | extend AlertTitle = "Brute Force Detected"
  | project AlertTitle, Computer, IpAddress, FailedAttempts, UniqueAccounts, SourceIPs

Detection Rule: Pass-the-Hash (T1550.002):
  // Zeichen: Network Logon mit NTLM ohne Passwort-Eingabe
  SecurityEvent
  | where TimeGenerated > ago(1h)
  | where EventID == 4624  // Successful Logon
  | where LogonType == 3   // Network Logon
  | where AuthenticationPackageName == "NTLM"
  | where not(TargetUserName endswith "$")  // Kein Computer-Account
  | where not(TargetUserName in ("ANONYMOUS LOGON"))
  // Verdächtig: Logon als Admin ohne vorherigen Interactive Logon auf diesem Computer
  | join kind=leftouter (
    SecurityEvent
    | where EventID == 4624
    | where LogonType in (2, 10)  // Interactive oder Remote Interactive
    | project InteractiveTime = TimeGenerated, InteractiveHost = Computer,
              InteractiveUser = TargetUserName
    ) on $left.TargetUserName == $right.InteractiveUser
  | where isempty(InteractiveTime) or abs(datetime_diff('hour', TimeGenerated, InteractiveTime)) > 1

Detection Rule: DCSync (T1003.006):
  // DCSync: GetChanges + GetChangesAll Rechte = Passwort-Hash-Extraktion
  SecurityEvent
  | where TimeGenerated > ago(1h)
  | where EventID == 4662  // Active Directory Object Access
  | where ObjectType has "domainDNS"
  | where AccessMask == "0x100"  // ReadControl
  | where Properties has "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"  // GetChanges
    and Properties has "1131f6ab-9c07-11d1-f79f-00c04fc2dcd2"   // GetChangesAll
  | where SubjectDomainName != "MSOL_"  // Azure AD Connect Ausschluss
  | where not(Computer has "DC")  // Kein DC → suspekt!

Detection Rule: Kerberoasting (T1558.003):
  SecurityEvent
  | where TimeGenerated > ago(1h)
  | where EventID == 4769  // Kerberos Service Ticket Request
  | where TicketEncryptionType == "0x17"  // RC4 - veraltet, typisch bei Kerberoasting!
  | where not(ServiceName endswith "$")   // Kein Computer-Account
  | where not(TargetUserName endswith "$")
  | summarize count() by TargetUserName, Computer, ServiceName
  | where count_ > 5  // Mehrere Tickets = wahrscheinlicher Angriff

Correlating Rules (Angriffskette):
  // Erkennt: Reconnaissance → Credential Access → Lateral Movement in Sequenz
  let recon = SecurityEvent
    | where EventID in (4776, 4625)  // NTLM + Failed Logons
    | summarize ReconCount = count() by IpAddress, bin(TimeGenerated, 1h);
  let cred = SecurityEvent
    | where EventID == 4769 and TicketEncryptionType == "0x17"  // Kerberoasting
    | project CredTime = TimeGenerated, IpAddress = ClientAddress;
  let lateral = SecurityEvent
    | where EventID == 4624 and LogonType == 3  // Network Logon nach Kompromiss
    | project LateralTime = TimeGenerated, IpAddress;
  recon
  | join kind=inner cred on IpAddress
  | join kind=inner lateral on IpAddress
  | where ReconCount > 10 and CredTime > bin(TimeGenerated, 1h) and LateralTime > CredTime
  | extend AlertTitle = "Attack Chain: Recon → Credential Access → Lateral Movement"

SPL für Splunk

SPL (Search Processing Language) - Splunk-spezifische Detection Rules:

Basis-Syntax:
  index=wineventlog EventCode=4625
  | stats count by src_ip, user
  | where count > 20
  | eval alert_title="Brute Force Detected"
  | table alert_title, src_ip, user, count

Detection: PowerShell Script Block Logging (T1059.001):
  index=powershell EventCode=4104
  (ScriptBlockText="*IEX*" OR ScriptBlockText="*Invoke-Expression*"
   OR ScriptBlockText="*DownloadString*" OR ScriptBlockText="*Net.WebClient*"
   OR ScriptBlockText="*-encodedcommand*" OR ScriptBlockText="*-enc *")
  NOT ScriptBlockText="*WindowsDefender*"
  NOT ScriptBlockText="*PSWindowsUpdate*"
  | eval risk_score=case(
    ScriptBlockText LIKE "%IEX%", 80,
    ScriptBlockText LIKE "%DownloadString%", 90,
    true(), 60
  )
  | table _time, Computer, UserID, ScriptBlockText, risk_score
  | sort -risk_score

Detection: Lateral Movement via WMI (T1047):
  index=wineventlog EventCode=4688
  (Process_Command_Line="*wmic*" AND (
    Process_Command_Line="*/node:*" OR
    Process_Command_Line="*process call create*"
  ))
  NOT (ParentProcessName="msiexec.exe" OR ParentProcessName="setup.exe")
  | stats count by Computer, User, Process_Command_Line
  | where count < 5  // Selten = verdächtiger als häufig
  | eval severity="High"

Correlation Search - Account Takeover:
  // Combines mehrere Events zu Alert
  (index=wineventlog EventCode=4625 src_ip=*) OR
  (index=wineventlog EventCode=4624 LogonType=3)
  | transaction maxspan=1h src_ip
  | where eventcount > 5
  | eval failed=mvcount(mvfilter(match(EventCode, "4625")))
  | eval success=mvcount(mvfilter(match(EventCode, "4624")))
  | where failed > 10 AND success > 0
  | eval description="Successful login after " + tostring(failed) + " failures"
  | table _time, src_ip, description, failed, success

Risk-Based Alerting (Splunk Enterprise Security):
  // Akkumuliert Risk-Scores über Zeit
  | tstats summariesonly=true
    count FROM datamodel=Endpoint.Processes
    WHERE Processes.process_name IN ("mimikatz.exe", "procdump.exe", "pwdump*")
    BY Processes.user, Processes.dest
  | foreach Processes.user [eval risk_score=mvappend(risk_score, 100)]
  | risk_send to risk_object_field=user score_field=risk_score

Testing und Qualitätssicherung

Detection Rules testen bevor Deployment:

Atomic Red Team (Open Source):
  # Installation:
  Install-Module -Name invoke-atomicredteam -Force
  Import-Module invoke-atomicredteam

  # Technik T1059.001 (PowerShell Execution) testen:
  Invoke-AtomicTest T1059.001 -TestNumbers 1

  # Prüfen: Hat unser SIEM einen Alert erzeugt?
  # Wenn nicht: Rule fehlt oder Log-Quelle fehlt!

MITRE Caldera (Automated Adversary Emulation):
  # Docker:
  docker run -d -p 8888:8888 -p 7010:7010 mitre/caldera:latest
  # Interface: http://localhost:8888
  # Agent auf Test-VM deployen → Adversary-Profil ausführen → SIEM prüfen

Detection Rule Qualitätskriterien:
  True Positive Rate (TPR):
    → Anteil echter Angriffe die detected werden
    → Test: bekannte Angriffe simulieren → Rule triggered?
    → Ziel: > 90% für kritische Techniken

  False Positive Rate (FPR):
    → Anteil normaler Aktivität die fälschlich als Alert gilt
    → Messen: Alert in Produktion 7 Tage beobachten
    → Ziel: < 20% FP-Rate

  Latenz:
    → Wie schnell nach dem Event kommt der Alert?
    → Ziel: < 5 Minuten für kritische Alerts

Alert Dokumentation Template:
  Name:        [Technik-Name] - [Kurzbeschreibung]
  ATT&CK:      T[Nummer].[Sub-Technik]
  Severity:    Critical/High/Medium/Low
  Data Source: Windows Security Events / Sysmon / PowerShell Logs / etc.
  Description: Was detectiert diese Rule?
  Why relevant: Warum ist diese Technik für uns relevant?
  False Positives: Was löst diese Rule legitim aus?
  Tuning:      Welche Ausschlüsse sind konfiguriert?
  Response:    Playbook-Link für Analyst
  Test:        Atomic Test-ID oder Caldera-Profil zum Testen
  Last Tested: Datum letzter erfolgreicher Test

Detection Engineering ist eine permanente Aufgabe - Angreifer entwickeln neue Techniken, Sigma-Community veröffentlicht neue Rules, eigene Infrastruktur ändert sich. AWARE7 unterstützt SOC-Teams beim Aufbau eines Detection-Engineering-Programms - von der MITRE-ATT&CK-Priorisierung über Rule-Entwicklung bis zum Testing mit Atomic Red Team.

SOC-Beratung anfragen | Penetrationstest für Detection Validation