Office 365 und Microsoft Graph in Wazuh: Wo die Module sitzen und wie du Mapper-Parsing-Fehler bei ModifiedProperties sauber behebst

von

Einleitung

Bei Wazuh-Integrationen rund um Microsoft 365 (Office 365 Audit Logs) und Microsoft Graph entstehen Probleme oft nicht im „Abrufen“ der Daten, sondern in der Indexierung: Filebeat liefert Events an den Indexer, doch einzelne Felder passen nicht zum erwarteten Mapping. Das Resultat sind mapper_parsing_exception-Fehler, verworfene Dokumente und am Ende „fehlende Alerts“, obwohl der Manager eigentlich Events erzeugt. Der folgende Beitrag ordnet ein, wo die betreffenden Module/Artefakte auf dem System und im Code typischerweise liegen – und wie du das klassische ModifiedProperties-Problem so löst, dass es auch nach Upgrades stabil bleibt.

Ausgangslage / Problemstellung

Symptom: Filebeat/OpenSearch meldet Indexing-Fehler wie:

  • mapper_parsing_exception für data.office365.ModifiedProperties
  • Index erwartet keyword, bekommt aber ein Objekt (START_OBJECT)

Dadurch werden Dokumente nicht geschrieben. Je nach Pipeline bedeutet das:

  • Wazuh-Alerts werden zwar am Manager erzeugt, kommen aber nicht im Index an
  • Dashboards/Discover zeigen Lücken oder gar keine Treffer für diese Datenquelle

Umgebung im Thread: Wazuh 4.12.0, mehrfach upgradiert, keine bewussten Template-/Decoder-Modifikationen, Problem tritt nur bei Office 365/MS Graph Events auf.

Technische Analyse

1) Welche Komponenten wirklich beteiligt sind

Bei Office 365/MS Graph hast du grob vier Schichten:

  1. Collector/Module (zieht Daten aus Microsoft APIs)
  2. Wazuh Manager (normalisiert in Alerts/Events, schreibt Archives/Alerts lokal)
  3. Ship/Forward (Filebeat nimmt Wazuh-JSON/Alerts und sendet an den Indexer)
  4. Indexer Mapping (Index-Template entscheidet Feldtypen, z. B. keyword vs object)

Der gezeigte Fehler ist Schicht 4: Das Mapping passt nicht zur tatsächlichen Feldstruktur. Der Hinweis Can't get text on a START_OBJECT bedeutet konkret: Das Feld ist (mindestens bei manchen Event-Typen) kein String, sondern ein Objekt/Array von Objekten – OpenSearch kann das nicht in ein keyword pressen.

2) Warum das nach Upgrades häufiger sichtbar wird

In Upgradestrecken ändern sich oft:

  • Event-Schemata (Microsoft erweitert Felder / andere Event-Typen liefern strukturiertere Daten)
  • Templates/Index Patterns (Wazuh liefert neue Template-Versionen aus)
  • Dynamische Mappings im Cluster (erste Dokumente „prägen“ Feldtypen; später kommt eine abweichende Struktur)

Gerade ModifiedProperties ist ein typischer Kandidat, weil es je nach Event mal „string-artig“ aussieht, aber semantisch eigentlich eine Struktur ist (OldValue/NewValue/Name …).

Lösung / Best Practices

Schritt 1: Klären, was ModifiedProperties wirklich ist (String vs Objekt)

Bevor du irgendwas am Template festnagelst, prüfe exemplarisch ein Raw-Event (aus Archives oder aus dem Filebeat-Event), ob data.office365.ModifiedProperties aussieht wie:

  • "ModifiedProperties":"...irgendein Text..." → String
    oder
  • "ModifiedProperties":[{...},{...}] bzw. "ModifiedProperties":{...} → Objekt/Array

Der Fehler deutet auf Objekt/Array hin. Dann ist keyword als Zieltyp grundsätzlich falsch.

Schritt 2: Template so anpassen, dass strukturierte Daten indexierbar bleiben

Für strukturierte Felder gibt es drei robuste Strategien (von „forensisch sicher“ bis „search-friendly“):

A) flattened (sehr praxistauglich für variable JSON-Strukturen)
Wenn dein Indexer/OpenSearch flattened unterstützt, ist das oft die beste Wahl: Du kannst Inhalte suchen/filtern, ohne ein starres Unter-Mapping definieren zu müssen.

B) object mit expliziten Subfeldern
Wenn das Objekt stabil ist (OldValue/NewValue/Name), kannst du das sauber modellieren. Ist aber upgrade-anfälliger.

C) object mit "enabled": false (Indexierung aus, aber Speicherung bleibt)
Wenn du nur verhindern willst, dass Events verworfen werden, ist das der „Airbag“: Daten bleiben im Dokument, aber du kannst darauf nicht sinnvoll aggregieren.

Konkreter, upgrade-stabiler Fix-Ansatz (empfohlen): flattened oder enabled:false
Beispiel (prinzipiell, Pfad kann je nach Template leicht variieren):

# Backup
cp /etc/filebeat/wazuh-template.json /etc/filebeat/wazuh-template-back.json

# Variante 1: flattened
jq '
  .mappings.properties.data.properties.office365.properties +=
  {"ModifiedProperties": {"type":"flattened"}}
' /etc/filebeat/wazuh-template-back.json > /etc/filebeat/wazuh-template.json

Oder „Airbag“-Variante:

jq '
  .mappings.properties.data.properties.office365.properties +=
  {"ModifiedProperties": {"type":"object", "enabled": false}}
' /etc/filebeat/wazuh-template-back.json > /etc/filebeat/wazuh-template.json

Wichtig: Der im Thread vorgeschlagene Wechsel auf keyword löst ein echtes START_OBJECT-Problem in der Regel nicht – das ist genau der Typ, der bereits fehlschlägt. Wenn der Payload objektförmig ist, brauchst du einen objektfähigen Typ.

Schritt 3: Template anwenden und Index-Lifecycle berücksichtigen

Nur das Template zu ändern reicht nicht immer, weil:

  • bestehende Indizes bereits ein Mapping „eingefroren“ haben
  • Konflikte weiter auftreten, wenn der Index bereits mit falschem Feldtyp existiert

Best Practice:

  1. Template aktualisieren
  2. Neuen Index erzeugen lassen (z. B. per Roll-over / nächster Tagesindex) oder testweise einen frischen Testindex nutzen
  3. Wenn nötig: betroffene Indizes (mit falschem Mapping) rotieren oder reindexen
  4. Filebeat-Pipelines/Templates sauber neu laden (je nach Setup z. B. filebeat setup --pipelines und/oder Template-Loading)

Schritt 4: Verifizieren, dass keine Dokumente mehr verworfen werden

  • Filebeat-Logs: keine 400er mapper_parsing_exception mehr
  • Indexer: _count steigt, keine „failed indexing“ mehr
  • Wazuh Dashboard: Office 365/MS Graph Events erscheinen wieder in Discover/Alerts

Lessons Learned / Best Practices

  • Schema-Drift einplanen: Microsoft-Event-Schemata ändern sich – plane Mappings so, dass variable Strukturen nicht alles blockieren (flattened ist hier oft Gold).
  • Templates versionieren und dokumentieren: Jede lokale Template-Anpassung sollte nachvollziehbar sein, sonst „verschwindet“ sie beim nächsten Upgrade oder Paket-Reinstall.
  • Indexing-Fehler sind Datenverlust: Ein 400er beim Indexing ist nicht nur „Logspam“, sondern bedeutet: Dokumente fehlen – inklusive Alerts/Detections.
  • Feldkonflikte früh erkennen: Monitoring auf Filebeat-Indexing-Errors und Indexer-Rejections spart dir „Warum sind keine Alerts da?“-Fehlersuchen.

Fazit

Die Wazuh-Module für Microsoft Graph/Office 365 sind meist nicht der Kern des Problems, wenn du mapper_parsing_exception siehst. In der Praxis ist es ein Mapping-Konflikt, weil Felder wie ModifiedProperties je nach Event-Typ als Objekt/Array geliefert werden. Die nachhaltige Lösung ist, das Template objektfähig zu machen (idealerweise flattened oder als Minimalvariante enabled:false) und anschließend sicherzustellen, dass neue Indizes das korrigierte Mapping übernehmen. So verschwinden die 400er, Dokumente werden wieder indexiert – und die Daten tauchen wieder in Alerts und Dashboards auf.

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