IP-Adressen aus Sysmon Event ID 1 extrahieren: Grenzen des Wazuh-Decoders und praktikable Alternativen

Einleitung

Die Analyse von Sysmon-Logs gehört zu den zentralen Bausteinen moderner Endpoint Detection und SIEM-Strategien. Besonders interessant ist dabei Event ID 1 (Process Creation), da hier häufig CommandLines mit potenziell schädlichen Verbindungen oder Indicators of Compromise (IoCs) enthalten sind. Der Wunsch, IP-Adressen direkt aus diesen Feldern zu extrahieren und in Wazuh weiterzuverarbeiten, ist daher naheliegend – stößt jedoch auf architektonische Grenzen innerhalb der Wazuh-Analysepipeline.

Ausgangslage / Problemstellung

Ein typisches Szenario besteht darin, eine IP-Adresse aus dem Feld commandLine eines Sysmon Event ID 1 zu extrahieren und in ein eigenes Feld (z. B. extractedIp) zu schreiben. Dazu wird ein benutzerdefinierter Decoder und eine Regel erstellt:

<decoder name="windows-ip-extractor">
<parent>json</parent>
<prematch>"commandLine":"</prematch>
<regex type="pcre2">(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})</regex>
<order>extractedIp</order>
</decoder>
<rule id="100900" level="12">
<decoded_as>json</decoded_as>
<field name="extractedIp">\d+\.\d+\.\d+\.\d+</field>
<description>Extracted IP from Sysmon command line: $(extractedIp)</description>
</rule>

Im wazuh-logtest scheint dieser Ansatz zu funktionieren. In der realen Umgebung werden jedoch keine Alerts basierend auf extractedIp erzeugt – stattdessen greift nur die Standard-Sysmon-Regel.

Technische Analyse

Der Kern des Problems liegt in der Art und Weise, wie Wazuh Windows-Logs verarbeitet.

Sysmon-Events werden nicht als klassische JSON-Logs ingestiert, sondern über den Windows EventChannel. Diese Events werden von einem speziellen, internen Decoder verarbeitet, der sich grundlegend vom generischen JSON-Decoder unterscheidet.

Die entscheidenden Punkte:

  • Der json-Decoder ist hier nicht aktiv, obwohl die Events im Index später JSON-ähnlich aussehen.
  • EventChannel-Logs werden durch interne, nicht erweiterbare Decoder verarbeitet.
  • Eine nachgelagerte statische Decoder-Verkettung (Child-Decoder auf Basis von json) ist nicht möglich.
  • wazuh-logtest kann in bestimmten Szenarien eine JSON-Verarbeitung simulieren, die in der echten Pipeline so nicht stattfindet.

Das führt dazu, dass der benutzerdefinierte Decoder zwar im Test funktioniert, aber im produktiven Datenfluss nie greift.

Zusätzlich wichtig: Felder wie win.eventdata.commandLine entstehen erst nach der internen Verarbeitung. Eigene Decoder können darauf nicht angewendet werden.

Lösung / Best Practices

Da eine echte Feldextraktion über Decoder bei EventChannel-Logs nicht möglich ist, gibt es drei praktikable Alternativen.

1. Direkte Regel auf bestehendes Feld anwenden

Wenn es nur darum geht, Alerts zu erzeugen, kann direkt auf das vorhandene Feld geprüft werden:

<group name="sysmon_ip,">
<rule id="100900" level="12">
<if_sid>92027</if_sid>
<field name="win.eventdata.commandLine" type="pcre2">\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}</field>
<description>IP located in Sysmon Event ID 1</description>
<options>no_full_log</options>
</rule>
</group>

Vorteile:

  • Funktioniert innerhalb der bestehenden Wazuh-Architektur
  • Kein Decoder erforderlich
  • Sofortige Alert-Erzeugung

Nachteil:

  • Die IP wird nicht als eigenes Feld extrahiert
  • Regex kann False Positives erzeugen (z. B. Versionsnummern)

2. Log-Ingestion anpassen (Alternative Logquelle)

Wenn echte Extraktion erforderlich ist (z. B. für Threat Intelligence Matching), sollte der Logpfad geändert werden:

  • Sysmon-Logs via NXLog, Winlogbeat oder Fluent Bit sammeln
  • Logs als echtes JSON an Wazuh senden
  • Dann greifen benutzerdefinierte Decoder korrekt

Dieser Ansatz ermöglicht:

  • Vollständige Kontrolle über Parsing
  • Erweiterbare Feldextraktion
  • Nutzung von CDB-Listen oder externen Feeds

3. Verarbeitung im Indexer (Post-Processing)

Eine weitere Möglichkeit ist die Verarbeitung auf Indexer-Ebene (OpenSearch/Elasticsearch Ingest Pipelines):

  • Extraktion per grok, dissect oder script processor
  • Speicherung in neuem Feld (extractedIp)
  • Nutzung für Dashboards und Queries

Einschränkung:

  • Diese Felder stehen nicht für Wazuh-Regeln zur Verfügung, da sie erst nach der Analyse entstehen

Lessons Learned / Best Practices

Die Verarbeitung von Windows EventChannel-Logs in Wazuh unterscheidet sich fundamental von klassischen Logquellen. Daraus ergeben sich wichtige Designentscheidungen:

Decoder-basierte Extraktion:
→ Nur bei klassischen Logs (Dateien, JSON, Syslog)

EventChannel (Sysmon, Windows Logs):
→ Nutzung vorhandener Felder + Regel-Logik

Erweiterte Analyse:
→ Entweder Logquelle ändern oder Post-Processing nutzen

Für produktive Umgebungen empfiehlt sich:

  • Regex in Regeln möglichst spezifisch gestalten (z. B. Ausschluss von Versionen)
  • High-Level Alerts auf verdächtige CommandLines definieren
  • Kritische Use Cases über alternative Logpipelines abbilden
  • Indexer-Pipelines für Enrichment (GeoIP, TI, Parsing) nutzen

Fazit

Die direkte Extraktion von IP-Adressen aus Sysmon Event ID 1 mittels Wazuh-Decodern ist aufgrund der EventChannel-Architektur nicht möglich. Stattdessen sollten Administratoren entweder auf Regex-basierte Regeln setzen oder die Log-Ingestion so anpassen, dass echte JSON-Verarbeitung möglich wird. Wer diese Einschränkung kennt, kann dennoch robuste und skalierbare Detection-Use-Cases aufbauen.

Quellenverweis

Wazuh Dokumentation: Rules and Decoders
https://documentation.wazuh.com/current/user-manual/ruleset/index.html

Wazuh Dokumentation: Windows EventChannel
https://documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/windows-eventchannel.html

Diskussion zu alternativen Parsing-Ansätzen (PowerShell / Event Logs)
https://groups.google.com/g/wazuh/c/aVzDvRVQgdI

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