BitLocker WARNING/INFO verschwinden in Wazuh: Warum Events im archives.log landen, aber nicht im Index – und wie Regeln für 60009–60012 korrekt bauen

von

Einleitung

Windows BitLocker ist in vielen Umgebungen ein Sicherheitsanker – gerade deshalb sind Events wie „BitLocker was suspended“ operativ relevant: Sie können auf Wartungsfenster, policy-gesteuerte Änderungen oder auch auf ein Risiko (Schutz temporär deaktiviert) hinweisen. Wenn solche Ereignisse in Wazuh zwar in archives.log auftauchen, aber im Dashboard nicht sichtbar sind und Custom Rules nur bei ERROR greifen, entsteht schnell der Eindruck „Wazuh verliert Logs“. In der Realität ist es meist eine Kombination aus Rule-Chain/Severity-Mapping und Indexing-Entscheidungen (Alerts vs. Archives). Wazuh unterscheidet diese Datenpfade explizit. Wazuh Dokumentation+1

Ausgangslage / Problemstellung

Es liegt ein Windows EventChannel-Event vor (BitLocker-API, Channel „Microsoft-Windows-BitLocker/BitLocker Management“) mit severityValue:"WARNING" und Message „BitLocker was suspended for volume C:.“.

Beobachtungen:

  1. Das Event ist in archives.log sichtbar, erscheint aber nicht im wazuh-archives* Index im GUI.
  2. Eine Custom Rule auf Basis <if_sid>60000</if_sid> feuert nicht – bei BitLocker ERROR hingegen schon.
  3. Das Problem tritt nur bei WARNING und INFORMATION auf.

Zusatzkontext: Microsoft empfiehlt für BitLocker-Fehleranalyse ausdrücklich die BitLocker-API Logs (Management/Operational). Das ist genau der Channel, der hier verarbeitet wird. Microsoft Learn+1

Technische Analyse

1) Warum die Regel nicht feuert: 60000 ist nicht der „letzte Match“

Im Wazuh-Windows-Event-Flow ist 60000 der generische Einstieg („parent“), danach erfolgt eine Severity-Aufspaltung über Folge-Regeln:

  • 60009 für INFORMATION
  • 60010 für WARNING
  • 60011 für ERROR
  • 60012 für CRITICAL

Das Muster ist in der Wazuh-Ruleset-Logik etabliert (und taucht auch in Wazuh-Issue-Diskussionen auf, weil nachgelagerte Regeln sonst nie erreicht werden, wenn die Severity-Stufe „dazwischen“ matched). GitHub+1

Konsequenz:

  • Ein WARNING-Event triggert 60010 (level 0) – nicht mehr „nur“ 60000.
  • Wenn deine Custom Rule nur auf <if_sid>60000</if_sid> aufsetzt, kann sie in diesem Pfad schlicht nie „drankommen“, weil die Auswertung bereits in der Severity-Verzweigung landet.

2) Warum WARNING/INFO im Dashboard „fehlen“: Level 0 wird ignoriert

Wazuh klassifiziert Rule Levels von 0 bis 16. Level 0 bedeutet „Ignored“ (keine Aktion, typischerweise keine Alert-Generierung). Wazuh Dokumentation+1
Wenn also WARNING/INFO standardmäßig auf Regeln mit level="0" gemappt sind (60009/60010), entsteht kein Alert-Event – und ohne Alert gibt es in der Regel auch keinen Eintrag in wazuh-alerts-* (Dashboard/Discover). Das erklärt, warum ERROR (60011, level > 0) „funktioniert“, WARNING/INFO aber nicht.

3) Warum archives.log ≠ wazuh-archives-* ist

Hier liegt ein häufiger Denkfehler:

  • archives.log ist ein Textlog und primär für lokale Archivierung/Debugging.
  • Für Indexing/Shipping ist in Wazuh das JSON-Archiv (/var/ossec/logs/archives/archives.json) relevant – und dafür muss logall_json aktiviert sein. Wazuh Dokumentation+1

Wazuh dokumentiert außerdem klar: Alerts gehen standardmäßig nach alerts.json und in wazuh-alerts-*; Archive-Indexing ist optional und muss bewusst aktiviert/konfiguriert werden. Wazuh Dokumentation+1
Wenn du also nur siehst, dass archives.log gefüllt wird, heißt das noch nicht, dass archives.json aktiv ist – oder dass Filebeat/Indexer-Pipelines Archive-Dokumente tatsächlich indexieren.

Lösung / Best Practices

1) Custom Rule korrekt an WARNING/INFO anbinden (60009–60012)

Wenn du alle BitLocker-Events (INFO/WARNING/ERROR/CRITICAL) in eine gemeinsame „BitLocker-Gruppe“ aggregieren willst, ist der robuste Ansatz:

  • Erst eine Gruppierungsregel, die an alle Severity-Mappings angebunden ist (60009–60012) und auf Provider/Channel matcht
  • Dann Child Rules für konkrete Messages/Use Cases („suspended“, „resumed“, etc.)

Beispiel (minimal, update-sicher in local_rules.xml oder eigener Custom-Datei):

<group name="windows,bitlocker,">
  <!-- Sammelregel: bindet alle Severity-Branches an -->
  <rule id="119001" level="0">
    <if_sid>60009,60010,60011,60012</if_sid>
    <field name="win.system.providerName">^Microsoft-Windows-BitLocker-API$</field>
    <field name="win.system.channel">^Microsoft-Windows-BitLocker/BitLocker Management$</field>
    <options>no_full_log</options>
    <description>BitLocker: Baseline (alle Severities)</description>
  </rule>

  <!-- Use Case: Suspended -> bewusst als Alert-Level >0 -->
  <rule id="119002" level="10">
    <if_sid>119001</if_sid>
    <field name="win.system.message">BitLocker was suspended</field>
    <description>BitLocker: $(win.system.message)</description>
  </rule>
</group>

Warum so?

  • Du umgehst das Problem „Custom Rule hängt am falschen Parent“.
  • Du erzeugst bewusst einen Alert (level 10) für „suspended“, unabhängig davon, ob Windows das als WARNING oder INFORMATION liefert.
  • Du nutzt Wazuh-Regelsyntax wie vorgesehen. Wazuh Dokumentation+1

2) Sichtbarkeit im Index: Entscheide dich für „Alerting“ oder „Archiv-Indexing“

Du hast zwei saubere Betriebsmodelle:

A) Du willst nur relevante Events sehen → Alerting erzwingen
Dann reicht es, für WARNING/INFO, die wichtig sind, Rules mit level > 0 zu bauen (wie oben). Das bringt sie zuverlässig in wazuh-alerts-* (weil Alerts generiert werden). Wazuh erklärt die Rolle des Rule-Levels und die Alert-Erzeugung in der Rules-Dokumentation. Wazuh Dokumentation+1

B) Du willst wirklich alle Events im wazuh-archives-* Index
Dann musst du Archive-Indexing korrekt aktivieren:

  • logall_json einschalten, damit alle Events in archives.json geschrieben werden. Wazuh Dokumentation
  • Filebeat/Wazuh-Indexer-Setup so konfigurieren, dass wazuh-archives-* auch tatsächlich befüllt wird (Wazuh beschreibt die Indizes und den Unterschied Alerts/Archives). Wazuh Dokumentation+1

Wichtig für Troubleshooting: archives.log allein ist kein Beleg dafür, dass Archive-Events in OpenSearch/Indexer landen; der relevante Payload für Indexing ist archives.json. sbarjatiya.com+1

3) Validierung: Logtest richtig einsetzen

  • Prüfe im wazuh-logtest, welche Rule-ID tatsächlich matched (du wirst bei WARNING typischerweise 60010 sehen).
  • Danach Rule-Chain entsprechend bauen (wie oben).
    Wazuhs Ruleset-Struktur für Windows Event Channels (Base Rules + Channel-spezifische Rules) ist dokumentiert, inklusive Hinweis auf die zentrale Base-Datei, aus der solche Parent-/Branch-Mechanismen stammen. Wazuh Dokumentation+1

Lessons Learned / Best Practices

  • Severity-Mapping beachten: Bei Windows EventChannel entscheidet win.system.severityValue über den Pfad (60009–60012). Custom Rules sollten an den tatsächlich gematchten Branch gekoppelt werden, nicht nur an 60000. GitHub+1
  • Level 0 ist „Ignored“: Wenn du WARNING/INFO im Dashboard sehen willst, brauchst du entweder (a) eigene Alert-Rules mit level > 0 oder (b) aktiviertes Archive-Indexing. Wazuh Dokumentation+1
  • Archives korrekt verstehen: Indexing aller Events läuft über archives.json und passende Pipeline/Shipping-Konfiguration – archives.log ist nicht der maßgebliche Index-Input. Wazuh Dokumentation+1
  • BitLocker-API-Kanäle sind die richtige Quelle: Microsoft verweist für BitLocker Troubleshooting explizit auf die BitLocker-API Logs (Management/Operational) – genau dort sollte man in Wazuh sauber gruppieren und selektiv alarmieren. Microsoft Learn+1

Fazit

Die Events sind nicht „weg“: WARNING/INFO landen in Wazuh häufig auf Level 0 (ignored) und erzeugen daher keine Alerts – entsprechend fehlen sie in wazuh-alerts-*. Zusätzlich ist archives.log nicht automatisch gleichbedeutend mit einem gefüllten wazuh-archives-* Index; dafür braucht es archives.json und korrekt aktiviertes Archive-Indexing. Die operative Lösung ist klar: Custom Rules an 60009–60012 anbinden, eine Baseline-Gruppe bauen und relevante BitLocker-Messages mit level > 0 gezielt alarmieren.

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