Einleitung
Sysmon-basierte Detection Rules in Wazuh liefern wertvolle Telemetrie für sicherheitsrelevante Dateioperationen. Gleichzeitig erzeugen sie in der Praxis häufig False Positives, insbesondere bei legitimen Betriebssystemmechanismen. Ein klassisches Beispiel ist PowerShells Execution Policy Test, bei dem temporäre Dateien im Benutzer-Temp-Verzeichnis erstellt werden. Ohne gezielte Filterung führen diese Events zu unnötigem Alert-Noise auf hohem Severity-Level.
Ausgangslage / Problemstellung
Eine Wazuh-Installation erzeugt wiederkehrend Alerts mit:
- Rule ID: 92213
- Level: 15
- Beschreibung: Executable file dropped in folder commonly used by malware
Ausgelöst werden diese Alerts durch Sysmon Event ID 11 (FileCreate), wenn PowerShell automatisch Testdateien wie folgende erzeugt:
C:\Users\<user>\AppData\Local\Temp\__PSScriptPolicyTest_<random>.ps1Charakteristik des Problems:
- Präfix ist konstant:
__PSScriptPolicyTest_ - Suffix ist zufällig generiert
- Event stammt von
powershell.exe - Technisch legitimes Verhalten (Execution Policy Check)
- Detection wird durch generische Malware-Heuristik ausgelöst
Ein bestehender Versuch, das Problem über <if_group>sysmon_event_11</if_group> zu lösen, bleibt wirkungslos. Zusätzlich zeigt wazuh-logtest nur Phase 2 (Decoding), aber keine Regelverarbeitung.
Technische Analyse
Warum <if_group> nicht funktioniert
Die ursprüngliche Regel 92213 basiert auf einer Kette von Parent-Regeln:
- EventChannel Decoder → Rule 61600
- Event ID 11 → Rule 61613 → Gruppe
sysmon_event_11 - Detection Rule → 92213
Ein <if_group>-Match greift jedoch zu früh in dieser Kette. Es referenziert nur die Gruppenzuordnung, nicht die konkrete Detection Rule. Dadurch wird die ursprüngliche Regel nicht überschrieben oder beeinflusst.
Richtiger Ansatz: Child-Rule mit <if_sid>
Wazuh folgt bei Rule Overrides einem klaren Prinzip:
Ausnahmen werden als Child-Regeln der ursprünglichen Rule definiert.
Das bedeutet:
- Referenz auf die konkrete Rule ID (
92213) - Setzen von
level="0"(komplette Unterdrückung) oder reduziertem Level - Ergänzung spezifischer Filterkriterien
Nur so wird die bestehende Detection sauber überschrieben.
Problem bei wazuh-logtest
Dass wazuh-logtest bei Phase 2 stoppt, liegt typischerweise daran, dass:
- vollständige JSON-Events statt roher Logs verwendet werden
- EventChannel-Decoder nicht korrekt simuliert wird
Standardmäßig erwartet wazuh-logtest keine bereits dekodierten JSON-Strukturen. Deshalb greift die Rule Engine nicht.
Lösung / Best Practices
1. Korrekte Suppression Rule definieren
Die funktionierende Minimalvariante basiert auf <if_sid>:
<group name="sysmon,windows,false_positive,">
<rule id="100010" level="0">
<if_sid>92213</if_sid>
<field name="win.eventdata.targetFilename" type="pcre2">(?i)__PSScriptPolicyTest_</field>
<description>False Positive - PowerShell Execution Policy Test file</description>
</rule>
</group>Diese Regel unterdrückt alle entsprechenden Events vollständig.
2. Präzisere Variante mit vollständigem Regex
Für mehr Kontrolle sollte der vollständige Pfad berücksichtigt werden:
<group name="sysmon,windows,false_positive,">
<rule id="100010" level="0">
<if_sid>92213</if_sid>
<field name="win.eventdata.image" type="pcre2">(?i)\\powershell\.exe$</field>
<field name="win.eventdata.targetFilename" type="pcre2">(?i)^C:\\Users\\[^\\]+\\AppData\\Local\\Temp\\__PSScriptPolicyTest_[^\\]+\.ps1$</field>
<description>False Positive - PowerShell Execution Policy Test file auto-created in Temp</description>
</rule>
</group>Vorteile:
- Einschränkung auf PowerShell als Quelle
- präzises Matching des Dateipfads
- keine Unterdrückung anderer potenziell relevanter Events
3. Alternative: Level reduzieren statt unterdrücken
Falls Sichtbarkeit erhalten bleiben soll:
<rule id="100010" level="5">So bleiben Events sichtbar, aber ohne kritische Priorität.
4. wazuh-logtest korrekt verwenden
Für EventChannel-Tests gibt es zwei Möglichkeiten:
Option A: Rohlog verwenden (empfohlen)
Nur den eigentlichen Event-Inhalt ohne Wazuh-JSON einfügen.
Option B: Decoder anpassen (temporär)
In 0575-win-base_rules.xml:
<rule id="60000" level="0">
<decoded_as>json</decoded_as>
<field name="win.system.providerName">\.+</field>
<options>no_full_log</options>
<description>Group of windows rules.</description>
</rule>Diese Änderung erlaubt Tests mit JSON, sollte aber nicht dauerhaft aktiv bleiben.
5. Regex schrittweise entwickeln
Bei komplexen Mustern empfiehlt sich ein iterativer Ansatz:
- Minimal:
<field name="win.eventdata.targetFilename">__PSScriptPolicyTest_</field> - Danach schrittweise verfeinern
- Erst am Ende PCRE2 einsetzen
So lässt sich sicherstellen, dass Matching grundsätzlich funktioniert.
Lessons Learned / Best Practices
- False Positives immer über
<if_sid>behandeln, nicht über Gruppen - Level 0 = vollständige Unterdrückung, bewusst einsetzen
- Sysmon Event ID 11 ist besonders anfällig für Noise
- Temp-Verzeichnisse enthalten viele legitime, aber verdächtig wirkende Aktivitäten
- Regex immer so spezifisch wie möglich halten
- wazuh-logtest ist für EventChannel nur eingeschränkt nutzbar
- Änderungen an Rules immer in
local_rules.xmldurchführen, nie im Core-Ruleset
Ein häufiger Fehler ist, zu breit zu filtern. Dadurch können echte Angriffe in ähnlichen Pfaden unbemerkt bleiben.
Fazit
Die saubere Unterdrückung von False Positives in Wazuh erfordert ein korrektes Verständnis der Rule-Hierarchie. Für Sysmon-basierte Detection Rules wie 92213 ist <if_sid> der entscheidende Mechanismus, um gezielte Ausnahmen zu definieren. In Kombination mit präzisen Regex-Filtern lassen sich legitime Systemaktivitäten wie PowerShell Execution Policy Tests effektiv ausblenden, ohne die Sicherheitsüberwachung zu beeinträchtigen.
Quellen
Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program
Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program