Windows DNS-Client/Operational mit Wazuh erfassen: Warum Events in archives.json landen, aber nicht als Alerts im Dashboard erscheinen

von

Einleitung

DNS-Telemetrie aus Windows-Endpoints ist für Threat Hunting und Incident Response extrem wertvoll: Sie liefert Domänenabfragen, Antwortcodes und Auflösungsfehler direkt vom Client und ergänzt klassische Netzwerk- oder Proxy-Logs. In Wazuh wird diese Datenquelle häufig über den Windows-Eventchannel Microsoft-Windows-DNS-Client/Operational angebunden. Ein typisches Praxisproblem: Die Events sind zwar auf dem Wazuh-Manager in den Archiven sichtbar, erscheinen aber nicht als Alerts bzw. sind im Dashboard nicht auffindbar. Dieser Beitrag erklärt die Ursachen entlang der Wazuh-Datenpipeline und zeigt die saubere Vorgehensweise basierend auf der offiziellen Dokumentation.

Ausgangslage / Problemstellung

Auf Windows-Agenten ist der Eventlog-Kanal Microsoft-Windows-DNS-Client/Operational aktiviert. In der Agent-Konfiguration wird die Eventchannel-Erfassung zentral ausgerollt:

<localfile>
  <location>Microsoft-Windows-DNS-Client/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

Zusätzlich werden Custom Rules erstellt, um EventIDs wie 3006/3008/3010 (Query/Response/Error) zu erkennen und Alerts zu generieren.

Die Validierung zeigt:

  • Events kommen an und sind im Manager unter /var/ossec/logs/archives/archives.json sichtbar (bei aktivierten Archiven).
  • wazuh-logtest zeigt „Alert to be generated“.
  • Im Dashboard/Index werden die Alerts trotzdem nicht gefunden.

Technische Analyse

1) Eventchannel-Ingestion vs. Alert-Generierung

Wazuh unterscheidet klar zwischen:

  • Eingehenden Roh-Events (können in Archiven gespeichert werden)
  • Alerts (werden nur erzeugt, wenn Regeln mit Alert-Level greifen)

Die Eventchannel-Erfassung über <localfile> ist der erste Schritt: Sie sorgt lediglich dafür, dass der Agent den Windows-Eventkanal abonniert und Events an den Manager sendet. Wazuh Dokumentation+1

Ob daraus ein Alert entsteht, entscheidet ausschließlich das Ruleset.

2) Warum archives.json Events zeigt, das Dashboard aber „leer“ bleibt

Wenn in <global> die Archivierung aktiviert ist, schreibt Wazuh auch Events weg, die keinen Alert auslösen:

  • <logall> → /var/ossec/logs/archives/archives.log
  • <logall_json> → /var/ossec/logs/archives/archives.json Wazuh Dokumentation

Damit ist es möglich, DNS-Client-Events im archives.json zu sehen, obwohl sie durch das Ruleset (noch) nicht als Alert klassifiziert werden.

Wichtig ist außerdem: Das Standard-Dashboard zeigt primär Alerts (aus wazuh-alerts-*), nicht automatisch Roh-Archivevents. Rohdaten werden erst dann „dashboardfähig“, wenn man die Wazuh-Archive-Weiterleitung/Indexierung explizit aktiviert und entsprechende Index-Patterns verwendet. Wazuh Dokumentation+1

3) Der häufigste Stolperstein: falscher Input für wazuh-logtest

wazuh-logtest erwartet einen Log-Sample so, wie er vom Decoder/Ruledriver verarbeitet wird. In realen Pipelines sind Windows-Eventchannel-Daten im Archiv häufig als JSON-Hülle mit Feldern wie full_log eingebettet.

Offiziell unterstützt Wazuh das Testen von Decodern und Regeln über wazuh-logtest (CLI, Dashboard oder API). Damit lässt sich nachvollziehen:

  • welcher Decoder matched,
  • welche Felder extrahiert werden,
  • welche Regel schließlich feuert. Wazuh Dokumentation+1

Wenn beim Test aber nicht der tatsächlich relevante Logteil verwendet wird (z. B. die umschließende JSON-Hülle statt des Eventchannel-Payloads), kann der Test irreführend sein oder Regelbedingungen greifen anders als in der Live-Pipeline.

4) „Nicht indexiert“ ist oft ein Symptom, nicht die Ursache

Wenn ein Alert wirklich generiert wird, muss er auch als JSON-Alert geschrieben werden, weil die Standard-Indexierung in Wazuh die Datei alerts.json als Quelle nutzt. Das ist in der Doku explizit beschrieben: Wird das Schreiben von JSON-Alerts deaktiviert, werden Alerts nicht mehr indexiert. Wazuh Dokumentation

Das erklärt typische „Ich sehe es in logtest, aber nicht im Index“-Situationen: Entweder ist es kein echter Alert (nur Archiv), oder die Alert-Ausgabe/Indexierungskette ist unterbrochen.

Lösung / Best Practices

Schritt 1: Eventchannel-Erfassung korrekt und minimal halten

Die offizielle Empfehlung für Windows-Eventchannels ist genau der konfigurierte <localfile>-Block mit location = Channel-Name und log_format = eventchannel. Wazuh Dokumentation+1

Schritt 2: Rohdaten-Sichtbarkeit sauber verifizieren (Archive nur temporär aktivieren)

Für die Eingangsprüfung ist logall_json ideal, weil es auch Events ohne Alert-Regel speichert:

<ossec_config>
  <global>
    <logall_json>yes</logall_json>
  </global>
</ossec_config>

Das Verhalten und die Dateien (archives.json) sind in der globalen Konfiguration dokumentiert. Wazuh Dokumentation+1

Nach erfolgreicher Verifikation sollte man die Archivierung wieder deaktivieren, um unnötiges Datenvolumen zu vermeiden.

Schritt 3: Regeln auf Basis der tatsächlich extrahierten Felder bauen (Ruleset-Syntax)

Custom Rules gehören in die vorgesehenen Custom-Rule-Dateien (z. B. local_rules.xml), und sollten die im Decoder erzeugten Feldnamen verwenden. Die Doku beschreibt Aufbau und Pflege von Custom Rules sowie die Ruleset-XML-Syntax (u. a. field, if_sid, Gruppierung). Wazuh Dokumentation+1

Best Practice für Eventchannel-Use-Cases:

  • Eine Parent-Rule matcht stabil auf den Channel (z. B. data.win.system.channel)
  • Child-Rules matchen auf eventID und setzen gewünschte Alert-Level

Schritt 4: Regeln und Decoder reproduzierbar mit wazuh-logtest validieren

Nutze wazuh-logtest, um sicherzustellen, dass:

  • der erwartete Decoder greift,
  • Felder so heißen wie in der Regel referenziert,
  • die Regel wirklich einen Alert erzeugt. Wazuh Dokumentation+1

Dabei ist entscheidend, dass du den passenden Logsample testest (den Eventchannel-Payload, nicht nur eine umgebende Archiv-Hülle).

Schritt 5: Indexierung prüfen: JSON-Alerts müssen geschrieben werden

Stelle sicher, dass die JSON-Alert-Ausgabe aktiv ist (jsonout_output), da diese laut Doku die Grundlage für die Standard-Indexierung (Filebeat liest alerts.json) ist. Wazuh Dokumentation

Wenn du nicht Alerts, sondern Roh-Archivevents im Dashboard sehen willst, musst du die Archive-Weiterleitung/Indexierung gemäß Indexer-Dokumentation aktivieren (Konzept: Archive-Events sind nicht automatisch in wazuh-alerts-*). Wazuh Dokumentation+1

Lessons Learned / Best Practices

  • Eventchannel-Konfiguration sorgt nur für Ingestion, nicht für Alerts. Wazuh Dokumentation+1
  • logall_json ist ein Troubleshooting-Werkzeug, um Events unabhängig von Regelmatches sichtbar zu machen. Wazuh Dokumentation+1
  • wazuh-logtest ist der verbindliche Weg, um Feldnamen/Decoder/Rule-Matches zu verifizieren – aber nur mit dem korrekten Logsample. Wazuh Dokumentation+1
  • „Nicht indexiert“ bedeutet meist: Es gibt keinen Alert (nur Archiv) oder die JSON-Alert-Ausgabe/Indexierungskette ist unterbrochen. Wazuh Dokumentation+1
  • Archive-Events und Alert-Events sind unterschiedliche Datenströme und landen typischerweise in unterschiedlichen Indizes. Wazuh Dokumentation

Fazit

Wenn DNS-Client-Events aus Microsoft-Windows-DNS-Client/Operational in archives.json sichtbar sind, ist die Datenerfassung grundsätzlich erfolgreich. Fehlen sie im Dashboard, liegt die Ursache fast immer in der zweiten Hälfte der Pipeline: Ruleset-Matching (kein Alert-Level), falscher Testinput bei wazuh-logtest oder eine unterbrochene Alert-Ausgabe/Indexierung (z. B. deaktiviertes alerts.json). Mit der Kombination aus temporär aktivierten Archiven, sauberem wazuh-logtest und korrekt platzierten Custom Rules lässt sich der Use Case stabil produktiv bringen – ohne dauerhaft „Debug Logging“ im Betrieb.

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