SentinelOne-Events als JSON

von

SentinelOne in Wazuh: Warum JSON-Events im Dashboard fehlen, Logtest „nicht erkannt“ meldet und wie du Parsing, Filebeat-Pipeline und Korrelation stabil bekommst

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh)

Die SentinelOne-Integration ist in Wazuh ein klassischer „Datenpipeline“-Use-Case: Events kommen per API oder Syslog an, werden lokal als JSON oder CEF geschrieben, anschließend von Wazuh ingestiert, decodiert, in den Indexer weitergeleitet und schließlich im Dashboard sichtbar. Wenn nur „ein paar“ Events auftauchen, wazuh-logtest keine saubere Decodierung zeigt oder der Eindruck entsteht, dass Decoder/Rules „nicht greifen“, liegt die Ursache selten an einem einzelnen Decoder. In der Praxis sind es fast immer Grenzfälle in der Pipeline: falscher Logpfad/Location-Match, nicht-lineares JSON, Zeichenkodierung/Control-Characters, Truncation durch Größenlimits, oder Mapping-Konflikte im Indexer.

Dieser Beitrag verdichtet typische Fehlerbilder und zeigt, wie du SentinelOne-Events in Wazuh zuverlässig verarbeitest – inklusive robuster Regeln für Korrelation.

Ausgangslage / Problemstellung (Zusammenfassung, Symptome, Umgebung)

Typische Ausgangslage:

  • SentinelOne API-Skript läuft auf dem Wazuh Manager und schreibt Events als JSON in eine Datei (z. B. /var/log/sentinelone.json).
  • Auf dem Server sind die JSON-Zeilen sichtbar und „aktuell“.
  • Im Dashboard erscheinen nur wenige Events.
  • wazuh-logtest zeigt: „log isn’t recognized“ oder die Decodierung ist unvollständig.
  • Es gibt den Verdacht, dass Decoder „nicht funktionieren“ oder dass Filebeat-Konfiguration/Mappings blockieren.
  • Nach Workaround mit „Predecoder vor JSON“ wird im Logtest zwar ein Treffer sichtbar, aber der Event ist „incomplete“ bzw. Wazuh meldet „complete error unknown problem“ (Hinweis auf Parser-/Truncation-/Encoding-Probleme).

Technische Analyse (Ursachen, betroffene Komponenten, Architekturbezug, Stolpersteine)

1) API-Integration ≠ Syslog-Integration: Decoder-Strategie ist komplett anders

SentinelOne kann Logs auf unterschiedlichen Wegen liefern:

  • Syslog/CEF: erfordert i. d. R. Custom Decoder (z. B. Prematch auf CEF:...|SentinelOne|) und passende Regeln.
  • API → JSON-Datei: hier greift meist der eingebaute JSON-Decoder (decoded_as json). In diesem Fall sind Custom Decoder oft unnötig – entscheidend sind Custom Rules, die auf JSON-Feldern matchen.

Ein häufiger Denkfehler: „Decoder fehlt“ – obwohl die JSON-Events bereits korrekt als JSON decodiert werden könnten, aber die Regeln (oder die location) nicht passen.

2) Warum wazuh-logtest „nicht erkannt“ melden kann, obwohl Events im Dashboard auftauchen

Das hat meist einen der folgenden Gründe:

  • Du testest nicht den exakten Roh-Log, der tatsächlich vom Logcollector gelesen wird (z. B. Unterschied zwischen Dateiinhalt und dem, was im Eventstream ankommt).
  • JSON ist nicht als „ein Event pro Zeile“ formatiert (z. B. Zeilenumbrüche in Strings, Stacktraces, eingebettete Newlines). Dann wird aus Sicht von Wazuh aus einem JSON-Objekt plötzlich mehrere Zeilen – und der JSON-Decoder greift nicht zuverlässig.
  • Ungültige Zeichen: Control-Characters, nicht-UTF8, Escape-Probleme (z. B. ungequotete Backslashes), sehr lange Felder.
  • Truncation: Der Event wird irgendwo auf dem Weg abgeschnitten (Manager-Logcollector, Transport, Filebeat, Indexer). Im Logtest siehst du dann ein „angefangenes“ JSON, das nicht mehr parsebar ist.

3) „Incomplete“ und „complete error unknown problem“ deuten stark auf Größen-/Formatprobleme hin

Zwei Verhaltensweisen passen gut zusammen:

  • Mit Predecoder „matcht“ du zwar irgendetwas (also Wazuh erkennt einen Anfang), aber die Nutzlast ist zu lang, nicht vollständig oder kein valides JSON → Ergebnis: unvollständige Decodierung oder Parser-Fehler.
  • Mit dem eingebauten JSON-Decoder bekommst du „unknown problem“, weil der JSON-Parser beim Validieren scheitert (typisch bei abgeschnittenem oder invalidem JSON).

Kurz: Wenn Wazuh „crasht“ oder Parsing unvollständig ist, ist das meist kein Rule-Problem, sondern Input-Sanität und Limits.

4) Filebeat/Indexer: „Events fehlen“ kann auch ein Mapping-/Pipeline-Thema sein

Auch wenn Wazuh Events lokal verarbeitet, heißt das nicht automatisch, dass sie im Dashboard ankommen. Typische Bremsen:

  • Filebeat/Wazuh-Indexer-Connector: Warnungen/Errors in Filebeat-Logs (z. B. Rejections, Mapping-Konflikte, zu große Felder).
  • Indexer-Mapping-Konflikte: Ein Feld hat mal String-, mal Objektstruktur (bei JSON-Events nicht selten). Das führt zu Indexing-Fehlern und damit „verschwinden“ Events, obwohl sie im Manager verarbeitet wurden.

Lösung / Best Practices (konkrete Schritte, Konfigurationen, Reihenfolge, Side-Effects)

Schritt 1: Sicherstellen, dass die API-Logs als „JSONL“ ankommen (ein JSON-Objekt pro Zeile)

Für Wazuh ist die stabilste Form: eine Zeile = ein vollständiges JSON-Objekt.

Praktische Checks auf dem Manager:

  • Validität einzelner Zeilen prüfen (Beispielprinzip): mit jq gegen eine einzelne Zeile testen.
  • Wenn SentinelOne-Felder Newlines enthalten (Tracebacks, multi-line Details), müssen sie im JSON escaped sein (z. B. \n), nicht als echte Zeilenumbrüche in der Datei landen.

Wenn du hier aufräumst, löst sich ein Großteil der „logtest erkennt nicht“ Fälle.

Schritt 2: Wazuh-Ingest sauber definieren – keine Decoder-Bastelei, sondern klare location

Für API-JSON ist die Regelbasis meist:

  1. Datei per <localfile> einlesen (auf dem Manager, wenn das Skript dort läuft).
  2. JSON automatisch decodieren lassen.
  3. Custom Rules auf JSON-Feldern aufbauen.

Beispiel-Pattern (Prinzip, Pfad anpassen):

<localfile>
  <log_format>json</log_format>
  <location>/var/log/sentinelone.json</location>
</localfile>

Wichtig: Die Rule-Basis sollte exakt diese Location matchen – sonst triggert nichts, obwohl JSON decodiert wird.

Schritt 3: Custom Rules für API-JSON korrekt aufbauen (Basisregel + Folgeregeln)

Robuster Ansatz:

  • Eine Basisregel gruppiert alle SentinelOne-Events anhand von decoded_as=json und der location.
  • Spezifische Regeln hängen per if_sid daran und matchen field-Werte.

Beispiel (Schema an deine tatsächlichen Felder anpassen):

<group name="sentinelone_api,">
  <rule id="100600" level="3">
    <decoded_as>json</decoded_as>
    <location>/var/log/sentinelone.json</location>
    <description>SentinelOne API Events</description>
  </rule>

  <rule id="100601" level="10">
    <if_sid>100600</if_sid>
    <field name="agentDetectionInfo.agentMitigationMode">detect</field>
    <description>SentinelOne: Active threat $(threatInfo.threatName) on $(agentRealtimeInfo.agentComputerName)</description>
  </rule>

  <rule id="100602" level="5">
    <if_sid>100600</if_sid>
    <field name="threatInfo.mitigationStatus">mitigated</field>
    <description>SentinelOne: Threat mitigated $(threatInfo.threatName) on $(agentRealtimeInfo.agentComputerName)</description>
  </rule>
</group>

Damit entfernst du „Decoder-Zufall“ komplett aus der Gleichung: JSON wird von Wazuh übernommen, Regeln entscheiden die Sichtbarkeit/Severity.

Schritt 4: Größenlimits und Truncation prüfen und entschärfen

Wenn Events sehr lang sind (S1 kann extrem ausführliche Payloads liefern), musst du entlang der Pipeline prüfen, wo abgeschnitten wird:

  • Logdatei selbst: Ist eine „Zeile“ wirklich komplett?
  • Wazuh Logcollector: Sehr lange Loglines oder eingebettete Newlines sind kritisch.
  • Filebeat: Bei zu großen Lines greifen je nach Input max_bytes-Limits (oder der Event wird verworfen/gekürzt).
  • Indexer: Zu große Felder oder Mapping-Konflikte führen zu Rejections.

Operativ bewährt:

  • SentinelOne API-Skript so konfigurieren, dass es nur relevante Eventtypen abruft (Filter/Scopes), und nicht „alles inklusive riesiger Detailfelder“.
  • Besonders große Textfelder (z. B. vollständige Stacktraces) ggf. in S1 reduzieren oder im Export als separate Events/Short-Form ausgeben.

Schritt 5: Filebeat- und Pipeline-Logs aktiv auswerten

Wenn Dashboard „zu wenig“ zeigt, ist das häufig kein Decoder-, sondern ein Transport/Indexing-Thema. Standard-Vorgehen:

  • Filebeat Unit-Logs prüfen (journalctl -u filebeat) und auf warn|error filtern.
  • Auf Hinweise achten wie: mapping conflicts, rejected documents, oversized events, pipeline failures.

Schritt 6: Wenn du wirklich Korrelation willst: Wazuh-Regellogik gezielt nutzen

Sobald die Basisregel zuverlässig feuert, kannst du echte SIEM-Korrelation bauen:

  • if_matched_sid + frequency/timeframe für Schwellenwertregeln
  • same_srcip, same_user, same_field-Äquivalente (je nach Eventstruktur) für Gruppierung
  • ignore für „Dämpfung“ von Eventstürmen

Beispielprinzip (aus Wazuh-Logik abgeleitet):

  • Einzelereignis: „Threat detected“
  • Korrelationsregel: „Mehrere Threats auf demselben Host innerhalb von 30 Sekunden“
<rule id="100610" level="12" frequency="3" timeframe="30">
  <if_matched_sid>100601</if_matched_sid>
  <description>SentinelOne: Multiple active threats in short timeframe</description>
</rule>

Lessons Learned / Best Practices (präventive Maßnahmen, Betrieb, Skalierung)

  • API-JSON immer als JSONL liefern (ein Objekt pro Zeile). Multiline in JSON ist der häufigste Grund für „logtest erkennt nicht“.
  • Decoder nicht überkomplizieren: Bei API-JSON ist der JSON-Decoder meist ausreichend; investiere in Regeln, nicht in Decoder.
  • Location-Match ist entscheidend: Wenn location nicht exakt passt, wirken Regeln „kaputt“, obwohl Decoding korrekt ist.
  • Große Payloads früh reduzieren: Lieber im Export filtern als später in Wazuh mit Truncation/Indexer-Rejections kämpfen.
  • Filebeat/Indexer-Fehler als First-Class Signal: „Fehlende Events im Dashboard“ sind oft Indexing-Probleme, nicht Parsing-Probleme.
  • Regelstrategie: Basisregel → Feldregeln → Korrelationsregeln. So bleibt das System nachvollziehbar und wartbar.

Fazit (knappe Zusammenfassung mit Mehrwert)

Wenn SentinelOne-Events als JSON auf dem Wazuh Manager ankommen, ist das Decoder-Thema meist schon gelöst: Der eingebaute JSON-Decoder kann die Arbeit übernehmen. Dass trotzdem nur wenige Events im Dashboard erscheinen oder wazuh-logtest scheitert, weist in der Regel auf Probleme in der Datenqualität (kein JSONL, ungültige Zeichen, embedded Newlines), Truncation durch Größenlimits oder Indexing/Mappings im Filebeat- und Indexer-Pfad hin. Mit einer sauberen JSONL-Quelle, einer klaren <localfile>-Definition, einer Basisregel über decoded_as=json und darauf aufbauenden Feld- und Korrelationsregeln bekommst du eine stabile SentinelOne→Wazuh Pipeline – und kannst anschließend echte SIEM-Korrelation statt „Console-Spiegelung“ umsetzen.

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