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-logtestkann 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,dissectoderscript 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