Wazuh: Wie man IP-Wechsel bei überwachten Office-365-Konten zuverlässig erkennt

Aus maxTechCorner

In komplexen Cloud-Umgebungen ist es essenziell, ungewöhnliche Aktivitäten frühzeitig zu erkennen. Eine häufige Herausforderung: Ein überwachter Benutzerin führt eine Operation plötzlich von einer neuen, bisher unbekannten IP-Adresse aus. Im Slack-Thread aus dem Wazuh-Community-Channel schilderte Marcin Strzyzewski genau dieses Problem – und erhielt hilfreiche Antworten, die wir hier zusammenfassen.

Ausgangssituation

Marcin wollte eine korrelierende Wazuh-Regel schreiben, die eine Warnung erzeugt, wenn:

  1. Ein Account aus einer Überwachungsliste (CDB list) enthalten ist
  2. Eine Operation ausgeführt wird
  3. Diese Operation im Vergleich zur vorigen Meldung von einer neuen IP-Adresse stammt

Die Basisregeln sahen so aus: 

<rule id="915311" level="0">
  <if_sid>91531</if_sid>
  <decoded_as>json</decoded_as>
  <list field="office365.UserId" lookup="match_key">etc/lists/o365/monitored-accounts</list>
  <group>office365,monitored-accounts,</group>
  <options>no_full_log</options>
  <description>Monitored account $(office365.UserId) event: $(office365.Operation) operation</description>
</rule>

<rule id="915312" level="7" timeframe="3600" frequency="2">
  <if_matched_sid>915311</if_matched_sid>
  <decoded_as>json</decoded_as>
  <same_field>office365.UserId</same_field>
  <different_field>office365.ClientIP</different_field>
  <group>office365,monitored-accounts,</group>
  <options>no_full_log</options>
  <description>Monitored account $(office365.UserId) performs $(office365.Operation) from a new IP $(office365.ClientIP)</description>
</rule>

Trotz korrekter Logformate wurde die zweite Regel nie ausgelöst.

Die Ursache: Regel-Level, Priorisierung und SIDs

Wazuh-Experte Jakub Pacowski identifizierte das Problem schnell:

1. Die erste Regel hatte Level 0

Regeln mit Level 0 werden verworfen, bevor sie für korrelierende Regeln wie <if_matched_sid> berücksichtigt werden. → Die zweite Regel konnte also nie triggern.

2. Wenn man Level > 0 setzt, entsteht ein neues Problem

Setzt man die Regel z. B. auf Level 1 oder 2, gewinnt möglicherweise eine andere Office-365-Regel (z. B. 91532) die Priorität beim Matching. → Die „Monitored Account“-Regel läuft dann gar nicht an.

Die funktionierende Lösung: Supress-Regel und Level-Anpassung Jakub schlug eine elegante Kaskade vor:

  1. 915311 bekommt Level 4→ So wird sie zuverlässig ausgewertet
  2. 915313 unterdrückt diese Regel→ verhindert unerwünschte Alerts
  3. 915312 korreliert dann sicher auf Basis von 915313→ das eigentliche IP-Wechsel-Event wird ausgelöst

Hier die funktionierende Version: 

<rule id="915311" level="4">
  <if_sid>91531</if_sid>
  <list field="office365.UserId" lookup="match_key">etc/lists/o365/monitored-accounts</list>
  <group>office365,monitored-accounts,</group>
  <options>no_full_log</options>
  <description>Monitored account $(office365.UserId) event: $(office365.Operation) operation</description>
</rule>

<rule id="915313" level="2">
  <if_sid>915311</if_sid>
  <description>Supress 915311</description>
</rule>

<rule id="915312" level="7" timeframe="3600" frequency="2">
  <if_matched_sid>915313</if_matched_sid>
  <same_field>office365.UserId</same_field>
  <different_field>office365.ClientIP</different_field>
  <group>office365,monitored-accounts,</group>
  <options>no_full_log</options>
  <description>Monitored account $(office365.UserId) performs $(office365.Operation) from a new IP $(office365.ClientIP)</description>
</rule>

Ergebnis

Die Regelkette funktioniert zuverlässig Keine unnötigen Alerts im Dashboard IP-Wechsel werden korrekt erkannt Marcin bestätigte: „Works good, thank you very much!“

Weitere Tipps aus der Community

Jakub gab zusätzlich wertvolle Hinweise:

<decoded_as>json</decoded_as> ist in Kindregeln nicht mehr nötig

Wazuh verarbeitet das Format automatisch.

Regel-IDs sollten im Bereich 100000–120000 liegen

Dies entspricht den Best Practices und vermeidet Konflikte mit Standardregeln.

Vorsicht bei der Regelnummerologie

Wenn man viele Custom-Files pflegt, ist es leicht, Nummern zu doppeln. Marcins Ansatz, regelähnliche IDs durch Anhängen von Ziffern zu erzeugen, ist praktisch – muss aber sauber dokumentiert werden.

Fazit

Der Slack-Thread zeigt eindrucksvoll, wie subtil Wazuh-Regellogik sein kann:

  • Level-Einstellungen spielen eine entscheidende Rolle
  • Parent-/Child-Regelbeziehungen müssen exakt stimmen
  • Supress-Regeln ermöglichen flexible, saubere Korrelationslogik
  • Community-Wissen beschleunigt die Fehlersuche enorm

Dank eines einfachen, aber cleveren dreistufigen Setups wird nun zuverlässig gemeldet, wenn ein sensibler Office-365-Account von einer neuen IP-Adresse agiert – ein wichtiger Baustein für moderne Cloud-Sicherheitsüberwachung.

https://wazuh.slack.com/archives/C0A933R8E/p1764089579561909

Mehr zu Wazuh …

Mehr zum Wazuh Ambassador Program …

Quelle

Dieser Artikel stammt aus dem Wazuh-Blog von m.a.x. it (veröffentlicht am 28. November 2025).

Unterstützung von m.a.x. it

Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit SIEM-Services auf Open-Source-Basis.


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen

Abgerufen von „http://techcorner.max-it.de/index.php?title=Wazuh:_Wie_man_IP-Wechsel_bei_überwachten_Office-365-Konten_zuverlässig_erkennt&oldid=3003“