Windows-Eventlogs über Graylog an Wazuh weiterleiten: Warum sie in archives.json landen, aber keine Alerts erzeugen

Einleitung

Windows-Eventlogs gehören zu den wichtigsten Datenquellen in einem SIEM. Sie liefern Informationen zu Authentifizierungen, Gruppenänderungen, Prozessstarts, Richtlinienänderungen und sicherheitsrelevanten Systemereignissen. In Wazuh werden solche Ereignisse normalerweise über die Windows-EventChannel-Integration des Wazuh-Agenten verarbeitet und anschließend durch die passenden Windows-Decoder und Rulesets analysiert.

Komplexer wird es, wenn Windows-Events nicht direkt vom Wazuh-Agenten, sondern über eine bestehende Log-Pipeline eingespeist werden, zum Beispiel über Winlogbeat, Graylog und einen Forwarder in Richtung Wazuh. In diesem Fall kommen die Events zwar häufig beim Wazuh-Manager an, werden aber nicht automatisch so behandelt wie native Windows-EventChannel-Logs. Das typische Symptom: Die Rohdaten sind in /var/ossec/logs/archives/archives.json sichtbar, erscheinen aber nicht als Alerts im Wazuh-Dashboard.

Ausgangslage / Problemstellung

In der beschriebenen Umgebung werden Windows-Eventlogs zunächst mit Winlogbeat gesammelt und an Graylog gesendet. Von dort werden die Events per Forwarder an Wazuh weitergeleitet. Auf dem Wazuh-Dashboard erscheinen jedoch keine passenden Windows-Security-Alerts.

Der erste wichtige Befund ist, dass die weitergeleiteten Logs im Wazuh-Manager unter folgendem Pfad vorhanden sind:

/var/ossec/logs/archives/archives.json

Damit ist klar: Die Events erreichen Wazuh grundsätzlich. Das Problem liegt daher nicht primär im Transportweg, sondern in der Analysephase. Wazuh speichert in den Archives alle empfangenen Events, unabhängig davon, ob sie eine Regel auslösen. Die JSON-Archive befinden sich unter /var/ossec/logs/archives/archives.json; die Wazuh-Dokumentation weist außerdem darauf hin, dass Archives standardmäßig deaktiviert sind und bei Aktivierung erheblichen Speicherplatz verbrauchen können.

Das eigentliche Problem ist daher: Die Events werden zwar archiviert, aber nicht so decodiert oder klassifiziert, dass die nativen Windows-Regeln greifen.

Technische Analyse

Wazuh unterscheidet zwischen dem Empfang eines Logs und dessen erfolgreicher Analyse. Der Wazuh-Manager nimmt Events entgegen, verarbeitet sie mit Decodern und prüft anschließend die Rulesets. Wazuh-Regeln sind XML-basierte Bedingungen, mit denen der Manager Muster in Logdaten erkennt und daraus Alerts oder Reaktionen ableitet. Jede Regel besitzt unter anderem eine ID und ein Level, wobei das Level die Schwere des ausgelösten Alerts bestimmt.

Bei nativen Windows-EventChannel-Logs erwartet das Windows-Ruleset eine bestimmte interne Struktur. Viele der Standardregeln hängen daran, dass das Event als windows_eventchannel erkannt wird und Felder wie diese verfügbar sind:

win.system.providerName
win.system.eventID
win.system.channel
win.eventdata.*

Wenn Windows-Events jedoch über Winlogbeat und Graylog weitergeleitet werden, liegen sie häufig als JSON-Events einer externen Pipeline vor. Inhaltlich handelt es sich zwar um Windows-Events, technisch betrachtet kommen sie aber nicht zwingend im exakt gleichen Format an wie native Wazuh-EventChannel-Events. Dadurch kann es passieren, dass die Standardregelgruppe für Windows-Events nicht matcht, obwohl die relevanten Informationen im Rohlog enthalten sind.

Die Diagnose lässt sich in zwei Fälle aufteilen:

cat /var/ossec/logs/archives/archives.json | grep "<Suchbegriff>"

Wenn passende Events in archives.json gefunden werden, ist der Empfang erfolgreich. Dann sollte der Fokus auf Decoder, Feldern, Regelbedingungen und Eventformat liegen.

Wenn keine passenden Events in archives.json gefunden werden, muss die Forwarder-Strecke geprüft werden: Graylog-Ausgang, Zielport, Protokoll, Wazuh-Remote-Konfiguration, Firewall, TLS beziehungsweise Syslog-Format und die Frage, ob Wazuh die Quelle überhaupt einliest.

Ein häufiger Stolperstein ist wazuh-logtest. Windows-EventChannel-Events lassen sich nicht immer direkt testen, wenn sie aus archives.json kopiert werden. Der Grund ist, dass die Testumgebung die Events anders interpretiert als der produktive EventChannel-Pfad. Für einen gezielten Test kann temporär eine Windows-Basisregel angepasst werden, damit das aus den Archives kopierte JSON als JSON analysiert wird.

Lösung / Best Practices

Der erste Schritt besteht darin, zu prüfen, ob die Logs wirklich im Wazuh-Manager ankommen:

cat /var/ossec/logs/archives/archives.json | grep "<Keyword>"

Geeignete Suchbegriffe sind zum Beispiel ein Hostname, eine Windows Event ID, ein Benutzername, der Name des Providers oder ein eindeutiger Text aus dem Event.

Falls Archives noch nicht aktiviert sind, kann dies temporär über /var/ossec/etc/ossec.conf erfolgen:

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>
    <logall>yes</logall>
    <logall_json>yes</logall_json>
  </global>
</ossec_config>

Danach muss der Wazuh-Manager neu gestartet werden:

systemctl restart wazuh-manager

Für die Visualisierung archivierter Events im Dashboard muss zusätzlich die Archiv-Weiterleitung in Filebeat aktiviert und ein Index Pattern für wazuh-archives-* erstellt werden. Die Wazuh-Dokumentation beschreibt dafür unter anderem die Aktivierung von archives.enabled: true in /etc/filebeat/filebeat.yml sowie das Index Pattern wazuh-archives-* mit timestamp als Zeitfeld.

Für die Regelanalyse sollte anschließend ein repräsentatives Event aus archives.json entnommen werden. Beim Kopieren aus JSON-Archives ist wichtig, Escaping zu bereinigen. Insbesondere Backslashes, die nur durch JSON-Escaping entstanden sind, können den Test verfälschen. Das Ziel ist, ein sauberes einzelnes Event zu erhalten, das in wazuh-logtest reproduzierbar getestet werden kann.

Für einen temporären Test von Windows-EventChannel-ähnlichen JSON-Events kann die Regel 60000 in folgender Datei angepasst werden:

/var/ossec/ruleset/rules/0575-win-base_rules.xml

Temporäre Testanpassung:

<rule id="60000" level="2">
  <!-- <category>ossec</category> -->
  <!-- <decoded_as>windows_eventchannel</decoded_as> -->
  <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 sollte ausschließlich für Tests verwendet werden. Nach Abschluss der Analyse muss die Regel wieder in den Originalzustand zurückgesetzt werden. Default-Ruleset-Dateien sollten nicht dauerhaft angepasst werden, weil Änderungen bei Updates überschrieben werden können und unerwartete Seiteneffekte auf andere Windows-Regeln haben können.

Nach der temporären Anpassung kann das Event mit wazuh-logtest geprüft werden:

/var/ossec/bin/wazuh-logtest

Dabei ist entscheidend, auf drei Punkte zu achten:

Erstens: Wird das Event überhaupt als JSON decodiert?

Zweitens: Sind die erwarteten Felder wie win.system.providerName, win.system.eventID oder win.system.channel vorhanden?

Drittens: Matcht eine bestehende Windows-Regel oder wird nur die Basisregel ausgelöst?

Wenn nur die Basisregel greift, ist das ein Hinweis darauf, dass die nativen Windows-Regeln die Feldstruktur nicht exakt so vorfinden, wie sie sie erwarten. In diesem Fall ist es meist stabiler, eigene Regeln auf Basis der tatsächlich vorhandenen Felder in archives.json zu erstellen, statt die Default-Decoder oder Default-Regeln dauerhaft zu verändern.

Ein Beispiel für eine einfache Custom Rule auf Basis eines Windows-Events könnte so aussehen:

<group name="windows,custom,">
  <rule id="100600" level="5">
    <if_sid>60000</if_sid>
    <field name="win.system.eventID">4624</field>
    <description>Windows successful logon detected from forwarded event pipeline</description>
    <group>authentication_success,windows_logon,</group>
  </rule>
</group>

Für fehlgeschlagene Logons:

<group name="windows,custom,">
  <rule id="100601" level="7">
    <if_sid>60000</if_sid>
    <field name="win.system.eventID">4625</field>
    <description>Windows failed logon detected from forwarded event pipeline</description>
    <group>authentication_failed,windows_logon,</group>
  </rule>
</group>

Custom Rules gehören typischerweise nach:

/var/ossec/etc/rules/local_rules.xml

Nach Änderungen an Rulesets sollte die Wazuh-Konfiguration geprüft und der Manager neu gestartet werden:

/var/ossec/bin/wazuh-logtest
systemctl restart wazuh-manager

Der bessere langfristige Ansatz ist jedoch, das Eventformat bereits vor Wazuh so zu normalisieren, dass die relevanten Windows-Felder konsistent vorhanden sind. Bei einer Pipeline über Winlogbeat und Graylog sollte geprüft werden, ob Feldnamen, Verschachtelung und JSON-Struktur mit dem übereinstimmen, was die Wazuh-Windows-Regeln erwarten. Besonders kritisch sind Felder unterhalb von win.system.* und win.eventdata.*.

Lessons Learned / Best Practices

Wenn Windows-Events über eine externe Log-Pipeline in Wazuh eingespeist werden, sollte nicht automatisch davon ausgegangen werden, dass die nativen Windows-EventChannel-Regeln vollständig greifen. Inhaltlich gleiche Events können analytisch unterschiedlich behandelt werden, wenn Transportweg und Datenstruktur abweichen.

Für den Betrieb empfiehlt sich ein dreistufiges Vorgehen. Zuerst wird mit archives.json geprüft, ob Wazuh die Events empfängt. Danach wird mit wazuh-logtest analysiert, welche Decoder und Regeln greifen. Erst danach sollten Custom Rules erstellt oder Pipeline-Anpassungen vorgenommen werden.

Archives sind ein starkes Diagnosewerkzeug, sollten aber in produktiven Umgebungen mit Vorsicht aktiviert werden. Wazuh weist ausdrücklich darauf hin, dass archivierte Logs von allen überwachten Endpunkten erhebliche Storage-Ressourcen verbrauchen können. Für produktive Systeme sollte deshalb eine klare Retention-Strategie existieren, etwa Rotation, Kompression, Auslagerung oder nur temporäre Aktivierung während einer Fehleranalyse.

Default-Ruleset-Dateien unter /var/ossec/ruleset/rules/ sollten nicht dauerhaft verändert werden. Temporäre Änderungen für Tests sind hilfreich, müssen aber dokumentiert und zurückgebaut werden. Dauerhafte Anpassungen gehören in lokale Custom Rules, damit sie updatefähiger und nachvollziehbarer bleiben.

Für skalierende Umgebungen ist außerdem wichtig, die Pipeline-Verantwortung klar zu trennen. Graylog oder Winlogbeat sollten nicht nur Logs weiterreichen, sondern ein konsistentes Schema liefern. Wazuh sollte anschließend auf stabile Feldnamen regeln können. Je weniger Sonderlogik im Wazuh-Default-Ruleset notwendig ist, desto wartbarer bleibt die Lösung.

Fazit

Wenn Windows-Eventlogs über Winlogbeat und Graylog an Wazuh weitergeleitet werden und nicht im Dashboard erscheinen, obwohl sie in archives.json vorhanden sind, liegt das Problem meist nicht am Empfang, sondern an Decoding und Rule-Matching. Die Events erreichen den Wazuh-Manager, werden aber nicht automatisch wie native Windows-EventChannel-Logs behandelt.

Der saubere Weg besteht darin, zuerst die Archives zu prüfen, anschließend repräsentative Events mit wazuh-logtest zu analysieren und darauf basierend Custom Rules oder eine bessere Normalisierung der Pipeline umzusetzen. Temporäre Anpassungen an Regel 60000 können beim Testen helfen, sollten aber niemals als dauerhafte Produktionslösung bestehen bleiben.

Quellenverweis

Wazuh Documentation: Event logging
https://documentation.wazuh.com/current/user-manual/manager/event-logging.html

Wazuh Documentation: Rules
https://documentation.wazuh.com/current/user-manual/ruleset/rules/index.html

Wazuh Documentation: Testing decoders and rules
https://documentation.wazuh.com/current/user-manual/ruleset/testing.html

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/p1782104556225639