Windows PowerShell- oder Security-Events aus dem Microsoft-Windows-PowerShell/Operational Channel verhalten sich in Wazuh auf den ersten Blick merkwürdig:
- Sie werden korrekt verarbeitet.
- Im Wazuh Dashboard / logtest erscheint der Decoder windows_eventchannel.
- Aber in den Wazuh Decoder-Dateien (
/var/ossec/ruleset/decoders/*.xml) sieht man keinen Decoder mit diesem Namen. - Und der JSON-Decoder taucht bei Tests ebenfalls auf – obwohl es eigentlich EventChannel-Events sind.
Warum ist das so? Die Antwort steckt tief in der Architektur von Wazuh. Dieser Artikel erklärt:
- warum EventChannel-Events keine XML-Decoder verwenden
- welchen internen Mechanismus Wazuh nutzt
- wie man EventChannel-Events korrekt testen kann
- wo der Decoder im Quellcode versteckt ist
- und warum Windows-Events in Wazuh ein Sonderfall sind
1. Warum du den Decoder „windows_eventchannel“ nicht findest
Wazuh unterscheidet zwischen:
- XML-basierten Decodern (→ sichtbar in
/ruleset/decoders/*.xml) - internen Decodern, die direkt im C-Code implementiert sind
Der Windows EventChannel-Decoder gehört zur zweiten Kategorie.
Jakub Pacowski erklärt es so:
„event channel events are decoded by internal decoder (defined in source code). It’s not defined via .xml file.“
Das heißt:
Es gibt keinen windows_eventchannel.xml Decoder
Die gesamte Logik ist direkt im Wazuh-Agent/Manager implementiert
Deshalb taucht der Name nur in Logtest/Rules auf, nicht im Filesystem
2. Wo sich der Decoder wirklich befindet (für Neugierige)
Manuel Pedro Gomez Castro zeigt den genauen Speicherort:
📌 GitHub – Wazuh interner EventChannel Decodersrc/logcollector/read_win_event_channel.c
https://github.com/wazuh/wazuh/blob/main/src/logcollector/read_win_event_channel.c
Hier findet man:
- das Parsing der Event Records
- den JSON-Übersetzer
- die Strukturierung der Felder
- die Übergabe an die Analyse-Pipeline
Das bedeutet:
✔ Wazuh liest native Windows Event Logs (über WinAPI)
✔ übersetzt sie on the fly in JSON-Strukturen
✔ gibt sie danach an das Regelwerk weiter
Dadurch wirken EventChannel-Logs wie JSON – sind es aber original nicht.
3. Warum erscheinen Windows-Events als JSON im Logtest?
Das ist ein wichtiger Punkt:
- Im echten Betrieb kommt der EventChannel-Logstrom binär von Windows
- Wazuh wandelt ihn intern zu JSON-ähnlichen Strukturen um
Um EventChannel-Events im Logtest simulieren zu können, benutzt man JSON-Repräsentationen – aber das heißt nicht, dass der JSON-Decoder tatsächlich verwendet wird.
Jakub beschreibt es pragmatisch:
„JSON for eventchannel is just used for testing purpose to simulate the event.“
Das heißt:
In Logtest sieht es aus wie JSON
Der echte Decoder bleibt trotzdem windows_eventchannel
Logtest gaukelt JSON nur vor, damit man testen kann
4. Wie testet man EventChannel-Events richtig?
Standardmäßig kann man EventChannel-Events nicht einfach per JSON in wazuh-logtest testen – sie gehen dann sofort in den JSON-Decoder und nicht in den EventChannel-Decoder.
Um das Verhalten zu erzwingen, empfiehlt Jakub einen Trick:
Schritt 1: In 0575-win-base-rules.xml temporär ändern
<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>
Damit zwingt man:
- JSON-Testinput wird so behandelt, als sei er ein EventChannel-Ereignis
- EventChannel-Regeln greifen im Logtest
Achtung:
- Manager nicht neu starten, sonst beeinflusst es das Live-System
- Nach dem Test die Änderung wieder zurücksetzen
- Ideal: Testumgebung nutzen
5. Windows EventChannel in Wazuh: Der Sonderfall
Kevin Branch ergänzt einen wichtigen Aspekt:
Windows EventChannel events are translated into JSON format for analysis,
but they are classified separately as EventChannel in the ruleset.
Kurz gesagt:
Windows-Events sind hybride Logs
| Eigenschaft | EventChannel | JSON |
|---|---|---|
| echte Quelle | Windows Event Log API | textbasiertes JSON |
| wie Wazuh sie intern strukturiert | JSON | JSON |
| welcher Decoder angewendet wird | windows_eventchannel | json |
| in XML-Decoder-Dateien vorhanden? | ❌ nein | ✔ ja |
Das führt zu:
- guten Integrationen
- klaren strukturierten Feldern
- aber etwas verwirrendem Testverhalten
Kevin hat sogar ein Toolset geschrieben, um Windows-Events sauber in Wazuh zu testen:
🔗 „Ninja Script Suite for Windows Log Testing“
https://bluewolfninja.com/2025/09/13/ninja-script-suite-for-windows-log-testing-in-wazuh/
Auch Zafer Balkan hat darüber einen längeren Artikel geschrieben.
6. Fazit
Windows EventChannel-Verarbeitung in Wazuh ist ein Spezialfall:
Was du jetzt weißt:
Der Decoder windows_eventchannel ist kein XML-Decoder, sondern im C-Code eingebaut
Deshalb findest du ihn nicht im Decoder-Verzeichnis
EventChannel-Events werden intern zu JSON transformiert – aber nicht vom JSON-Decoder verarbeitet
Logtests zeigen JSON nur als Simulation
Um EventChannel-Regeln korrekt zu testen, muss man die Regeln kurzzeitig anpassen oder Tools nutzen
Windows-Logs sind deshalb in Wazuh sehr leistungsfähig, aber testseitig anspruchsvoller
Kurz:
Alles funktioniert wie es soll – Wazuh abstrahiert die Windows Event Logs clever, aber macht die Testbarkeit etwas spezieller.
https://wazuh.slack.com/archives/C0A933R8E/p1763976866388989