Wazuh 4.14: Warum deine local_rules.xml „nicht lädt“ – Sysmon Event ID 3 korrekt matchen, data.*-Feldfallen vermeiden und EventChannel-Logs richtig mit wazuh-logtest testen

von

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh)

Windows Sysmon Event ID 3 („Network connection“) ist eine der wichtigsten Telemetriequellen für Threat Hunting, IOC-Matching und Threat-Intel-Enrichment (z. B. via OpenCTI). In Wazuh wirkt das auf den ersten Blick trivial: „Ich schreibe eine Rule auf EventID 3, dann bekomme ich Alerts.“ In der Praxis scheitert es aber häufig an zwei Details:

  1. Feldnamen im Ruleset sind nicht identisch mit dem, was du im Dashboard unter data.* siehst.
  2. wazuh-logtest ist für unanalysierte Rohlogs gebaut – nicht für alerts.json-Records.

Dieser Beitrag zeigt anhand eines realen Troubleshooting-Threads, warum ein Test irreführend sein kann, wie du Sysmon EID 3 zuverlässig als Alert erzeugst und wie du das so gestaltest, dass Integrationen (OpenCTI/MISP/Custom Scripts) selektiv und performant bleiben.

Ausgangslage / Problemstellung (Zusammenfassung, Symptome, Umgebung)

  • Wazuh Version: 4.14
  • Ziel: Jeder Sysmon Netzwerk-Event (Event ID 3) soll als Alert erzeugt werden (zum Testen einer OpenCTI-Integration).
  • Custom Rules liegen unter /var/ossec/etc/rules/local_rules.xml (vorhanden, Rechte plausibel).
  • logtest zeigt ein Match – aber es fühlt sich an, als würde Wazuh die lokalen Regeln nicht laden oder im Live-Betrieb keine Alerts generieren.

Im local_rules.xml existieren u. a. Regeln wie:

<rule id="199996" level="10">
  <field name="data.win.system.eventID">^3$</field>
  <description>TEST direct Sysmon event 3 match</description>
  <group>sysmon_event3,</group>
</rule>

Und als „Testlog“ wird ein JSON eingefügt, das erkennbar bereits ein alerts.json-Record ist (inkl. decoder.name, agent, manager, data.win..., full_log etc.).

Technische Analyse (Ursachen, betroffene Komponenten, Architekturbezug, Stolpersteine)

1) wazuh-logtest erwartet Rohlogs, nicht alerts.json

wazuh-logtest ist dafür gedacht, unanalysierte Events gegen Decoder/Rules zu prüfen. Wenn du stattdessen einen bereits analysierten alerts.json-Record einfügst, testest du nicht das reale Parsing/Ruleset-Verhalten, sondern einen Artefaktzustand, der sich stark vom echten Eingangspfad unterscheidet. Genau deshalb wirken Tests manchmal „magisch“ oder widersprüchlich. (Das Vorgehen, Windows-Events sauber zu testen, wird in Praxisguides explizit thematisiert.)

Konsequenz: Ein logtest-Match auf Basis eines alerts.json-Records ist kein Beweis, dass deine Regel den Roh-EventChannel-Input korrekt matcht.

2) Die data.*-Falle: Im Ruleset heißt es win.system.eventID, nicht data.win.system.eventID

Im Wazuh Dashboard erscheinen dekodierte Felder unter data.*, weil Wazuh so Kollisionen zwischen Metadatenfeldern und dynamischen Feldern vermeidet. Für Rules gilt jedoch: Du referenzierst die Felder ohne den data.-Prefix.

Das heißt:

  • Falsch (im Ruleset): <field name="data.win.system.eventID">^3$</field>
  • Richtig (im Ruleset): <field name="win.system.eventID">^3$</field>

Diese Diskrepanz ist einer der häufigsten Gründe, warum Rules in der Praxis „nicht greifen“, obwohl man im Dashboard scheinbar genau dieses Feld sieht.

3) Du willst „alle Sysmon 3“, aber die Standardruleset-Logik ist selektiver

Bei Sysmon/EventChannel ist es üblich, dass eine Level-0-Basisregel (Parent) vieles einsortiert, und nur bestimmte Kinder Alerts erzeugen. Wenn du wirklich alle Event ID 3 als Alerts willst (PoC/Testing), ist der robuste Weg, eine bestehende Regel gezielt zu überschreiben (overwrite) statt eine neue, isolierte Regel „daneben“ zu bauen.

Wazuh dokumentiert genau dieses Muster: Default-Regeln werden updatesicher überschrieben, indem man die Regel nach /var/ossec/etc/rules/ kopiert und overwrite="yes" setzt.

4) Integrationen sind nicht für High-Volume gedacht

Wazuh Integrations laufen nicht parallelisiert „beliebig“, sondern seriell – eine hohe Alertfrequenz kann zu Drops führen. Für einen PoC mit wenigen Events ist das okay, für „jeden Network Connect“ in einer produktiven Umgebung meist nicht. Deshalb ist es sinnvoll, früh zu entscheiden: Welche Alerts (selektiv) sollen Enrichment triggern? – statt alle Logs.

Lösung / Best Practices (konkrete Schritte, Konfigurationen, Reihenfolge, Side-Effects)

A) Sysmon Event ID 3 zuverlässig als Alert erzeugen (updatesicher via overwrite)

Wenn du wirklich jede Sysmon Network Connection als Alert brauchst, überschreibe die passende bestehende Sysmon-Rule (im Thread war das als „61605“ adressiert) mit overwrite="yes" und korrektem Feldnamen ohne data..

Beispiel (als Custom Rule unter /var/ossec/etc/rules/local_rules.xml oder einer eigenen Datei in /var/ossec/etc/rules/):

<group name="windows,sysmon,">
  <rule id="61605" level="3" overwrite="yes">
    <if_sid>61600</if_sid>
    <field name="win.system.eventID">^3$</field>
    <description>Sysmon 3: Network connection</description>
    <options>no_full_log</options>
    <group>sysmon_event3,</group>
  </rule>
</group>

Warum diese Strategie stabil ist:

  • overwrite="yes" sorgt dafür, dass deine Definition die Default-Definition ersetzt, ohne Stock-Dateien anzufassen.
  • Level 3 ist ein praxistauglicher Default, damit Alerts sichtbar werden (unter Standard-log_alert_level).
  • Das Setzen einer dedizierten Gruppe (sysmon_event3) ist wichtig, um Integrationen oder weitere Child-Rules sauber daran zu hängen.

B) Child-Rules nicht „entkoppeln“: Gruppenlinie beibehalten

Wenn du unter dieser Rule später spezifische Fälle baust (z. B. nur wenn win.eventdata.destinationIp vorhanden ist), dann sollte jede Child-Rule die Basiskategorie weiterhin tragen:

<group>sysmon_event3,</group>

So kann eine Integration auf sysmon_event3 hören und wird sowohl bei Parent als auch bei Children getriggert.

C) wazuh-logtest richtig nutzen: Rohinput testen, nicht alerts.json

Für EventChannel/Sysmon ist der wichtigste Punkt: Testdaten müssen dem Rohformat entsprechen, das Wazuh tatsächlich analysiert. Wenn du aus dem Dashboard kopierst, kopierst du oft bereits analysierte Records. Für reproduzierbare Tests sind Script-/Helper-Ansätze sinnvoll, die genau den Rohinput nachstellen und in logtest einspeisen.

Pragmatische Best Practice:

  • Teste mit einem repräsentativen Roh-Event (oder mit einem Tool/Script, das ihn korrekt formt), nicht mit dem kompletten alerts.json-Datensatz.

D) Integrations-Design: lieber „wenige Alerts täglich“ als „alle Logs“

Für OpenCTI/Threat Intel ist der professionelle Weg:

  • Erzeuge Alerts nur für Events mit relevanten Feldern (z. B. win.eventdata.destinationIp, hash, domain)
  • Trigger die Integration auf Gruppen/Rules, die diese Qualität garantieren
  • Vermeide „all Sysmon 3“ im Dauerbetrieb, außer du hast sehr strikte Filter (z. B. nur extern, nur ungewöhnliche Ports, nur aus kritischen Prozessen).

Lessons Learned / Best Practices (präventive Maßnahmen, Betrieb, Skalierung)

  • data.* ist Dashboard-/Storage-Sicht, nicht Ruleset-Sicht. Rules referenzieren Feldnamen ohne data..
  • wazuh-logtest ist kein alerts.json-Replay-Tool. Teste Rohlogs/realen Inputpfad, sonst werden Ergebnisse irreführend.
  • Für „Default-Regel anpassen“ ist overwrite="yes" der richtige, updatesichere Weg – nicht das Editieren von Stock-XML.
  • Integrationen sind betrieblich empfindlich bei hohem Durchsatz. Besser: selektiv alerten und gezielt enrichern.

Fazit (knappe Zusammenfassung mit Mehrwert)

Die Regeldatei „lädt“ in solchen Fällen meist sehr wohl – das Problem sitzt fast immer in der Testmethode und im Feldnaming: data.win... funktioniert im Ruleset nicht, und alerts.json-Records sind keine geeigneten logtest-Inputs. Wenn du Sysmon Event ID 3 wirklich flächig als Alerts brauchst (PoC), überschreibe die passende Sysmon-Rule updatesicher mit overwrite="yes" und referenziere win.system.eventID. Danach kannst du per Gruppen-Tagging (sysmon_event3) Integrationen sauber und selektiv triggern, ohne dir später die Pipeline zu überlasten.

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

https://wazuh.slack.com/archives/C0A933R8E/p1768918020746199