Thread-Zusammenfassung: “Sysmon Event kommt an – aber kein MISP-Alert im Dashboard”

Aus maxTechCorner

In diesem Thread war der Kernfehler ein Missverständnis über den Datenfluss:

Was Jitendra erwartet hat

  • Sysmon Event 22 (DNS Query) mit queryName: woonlergyplay.com kommt rein
  • Domain ist als IOC in MISP vorhanden
  • Daher sollte automatisch eine MISP-Warnung (Rule 100622) im Dashboard entstehen

Warum 100622 nie feuern kann (so wie es gebaut ist)

Die Regel 100622 matcht nicht Sysmon-Events – sie matcht Events, die bereits MISP-Felder enthalten, z. B.:

  • integration = misp
  • misp.category
  • misp.value
  • etc.

Deine Sysmon-Roh-Events (EventChannel, EventID 22 / 1) enthalten aber kein integration:misp und kein misp.*. Also kann Wazuh diese Sysmon-Events niemals mit einer MISP-Regel matchen, außer du hast eine Integration, die nachträglich MISP anfragt und ein neues Event (mit integration:misp) zurück an den Manager sendet.

Genau das hat Marcos dann klargestellt:

  • Ohne ein MISP-“Enrichment-Event” (das vom MISP-Script/Connector zurückkommt) gibt es nichts, was 100622 matchen könnte.
  • Ein reines Sysmon Event kann keine MISP-Regel triggern, weil es die Felder nicht enthält.

Was im Thread noch auffällt: 100622 ist “isoliert”

In deiner geposteten misp.xml fehlt außerdem beim 100622 das Parent-Matching: 

<rule id="100622" level="12">
   <field name="misp.category">\.+</field>
   ...
</rule>

Wenn du MISP-Events per Script einspeist, ist Best Practice:

  • Base rule (z. B. 100620) matcht integration:misp
  • 100622 sollte darauf aufbauen:
<rule id="100622" level="12">
  <if_sid>100620</if_sid>
  <field name="misp.category" type="pcre2">.+</field>
  ...
</rule>

Sonst kann 100622 theoretisch trotzdem matchen – aber nur, wenn ein Event direkt misp.category im richtigen Decoder-Kontext liefert. Mit if_sid wird es sauberer und stabiler.

Die richtige Architektur (damit es funktioniert)

Du brauchst ein “Zwischenglied”:

  1. Sysmon Event 22 kommt an → triggert Sysmon Rule (z. B. 61650)
  2. Integration Script (custom-misp.py) wird durch diese Rule/Group gestartet und fragt MISP ab
  3. Script schickt ein neues JSON-Event zurück an Wazuh mit Feldern wie:
  • integration: "misp"
  • misp.category, misp.value, misp.event_id …
  1. Erst dieses Event matcht dann 100620/100622 → Dashboard zeigt MISP Alert

Wenn Schritt (2) oder (3) fehlt/fehlschlägt, siehst du nur Sysmon, aber nie MISP.

Schnellcheck-Liste (genau das hätte im Thread die Ursache gezeigt)

Auf dem Manager prüfen:

  • Läuft integratord und sieht er Trigger?

/var/ossec/logs/ossec.log | grep -i wazuh-integratord

Gibt es irgendein Event mit location: misp oder integration: misp?

  • /var/ossec/logs/archives/archives.json bzw. alerts.json nach integration":"misp durchsuchen

Wird das Script überhaupt aufgerufen?

  • In ossec.log stehen bei Fehlern oft KeyErrors / Permission / timeouts

Wenn Events erzeugt werden, aber nicht im Dashboard:

  • Filebeat-Logs prüfen auf Index-Fehler (Mapping-Konflikte, oft full_log)

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

Quelle

Dieser Artikel stammt aus dem Wazuh-Blog von m.a.x. it (veröffentlicht am 11. Februar 2026).

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=Thread-Zusammenfassung:_“Sysmon_Event_kommt_an_–_aber_kein_MISP-Alert_im_Dashboard”&oldid=2923“