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

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
  4. 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