Wazuh And MISP Integration

OpenSecure
5 min readApr 15, 2022

Interacting With MISP’s API to detect IoCs within our Wazuh Alerts.

Intro

This blog entry details how we can automate Wazuh to take advantage of the MISP API. This automation serves as a great benefit because our analysts will not have to manually correlate a Wazuh alert with MISP to find possible IoCs. For example, when a DNS query is made by an endpoint, Wazuh will strip out that domain and send it to MISP asking if MISP has this value within its threat feeds. If the value does exist within MISP, MISP will respond with the event id and more metadetails around the IoC. A positive response from MISP will generate a high severity Wazuh alert stating “IoC found”. Our SOC team is now immediately notified with enriched data rather than manually searching for IoCs.

Eligible Rules

We first need to instruct Wazuh when we want it to make the API call to MISP and what data we want to pass it. We will take advantage of our Sysmon rules since that is collecting a wealth of information. It is very important that the Wazuh managers are loaded with our custom Sysmon rules and the agents have the correct Sysmon config. This integration will not work correctly without it. This post is coming soon.

The below Sysmon rule groups are eligible for this integration: sysmon_event1,sysmon_event3,sysmon_event6,sysmon_event7,sysmon_event_15,sysmon_event_22,syscheck

These events all contain fields that have values for potential IoCs (IP, domain, hash, etc.). For example, a Sysmon Event 22 alert is a DNS query, looking at the Wazuh alert we see DNS query made in the data.win.eventdata.queryName field.

In the above image, the Wazuh Manager will take the value opensecure.co and ask MISP if that value is within any threat feeds.

MISP Integration Python Script

For this integration to work, we need to tell Wazuh how to make the API request to MISP. We are going to use a custom Python script to do so. There are a few steps that must be completed for a successful request.

  • Custom-MISP.py Script
  • Set custom options into script
  • Add Integration Block To Wazuh’s ossec.conf
  • Add MISP custom rules

Custom-MISP.py Script

Now we will create the script responsible for making the API call to MISP. Navigate into the /var/ossec/integrations directory on your Wazuh Manager and we can place our custom-misp.py script there.

Set Custom Options

Due to the MISP URL and the MISP API token being different per environment. We will need to reflect those changes accordingly in the custom-misp.py script. Lines 35 and 37contain the misp_base_url and misp_api_auth_key variables. These will need to be changed to match your MISP URL and API key.

Add Integration Block To Wazuh’s ossec.conf

Now lets tell Wazuh when to run the custom-misp.py script by setting a new integration block in the ossec.conf of the Manager.

<integration>
<name>custom-misp.py</name>
<group>sysmon_event1,sysmon_event3,sysmon_event6,sysmon_event7,sysmon_event_15,sysmon_event_22,syscheck</group>
<alert_format>json</alert_format>
</integration>

Notice that the Manager will only run the script when one of the Sysmon groups is triggered.

Restart the Wazuh Manager.

Add MISP custom rules

Lastly, we need to configure custom rules so that Wazuh can generate an alert if MISP responds with a positive hit. Create a custom misp.xml rule file and add the below.

<group name="misp,">
<rule id="100620" level="10">
<field name="integration">misp</field>
<match>misp</match>
<description>MISP Events</description>
<options>no_full_log</options>
</rule>
<rule id="100621" level="5">
<if_sid>100620</if_sid>
<field name="misp.error">\.+</field>
<description>MISP - Error connecting to API</description>
<options>no_full_log</options>
<group>misp_error,</group>
</rule>
<rule id="100622" level="12">
<field name="misp.category">\.+</field>
<description>MISP - IoC found in Threat Intel - Category: $(misp.category), Attribute: $(misp.value)</description>
<options>no_full_log</options>
<group>misp_alert,</group>
</rule>
</group>

If MISP responds with a positive hit, rule id 100622 will trigger.

Example

Now lets walk through a full example. On my test endpoint I am going to ping a domain that I know exists within MISP. My endpoint will make a DNS request for the domain which will trigger Sysmon Event 22. The Manager will then make the API request to MISP and MISP will respond with a positive hit which will generate an alert.

We then see the Sysmon Event 22 alert come in from that agent stating that Ping made a DNS request.

We then see the Wazuh manager receive a positive hit alert from MISP.

Opening up the alert with see our various MISP fields which contain the MISP event id, original alert that invoked the integration to run, and the value (tikonam.com in this example):

Conclusion

This automation is greatly beneficial to our SOC team as they do not have to manually search alerts and MISP for IoCs. This whole process is now automated and greatly minimizes the chance of missing an IoC and greatly speeds up response time. Remaining steps would be to setup the proper alerting either via Elastalert or Shuffle so that tickets are auto generated and enriched when this MISP rule is detected.

--

--

OpenSecure

Focusing on Open Source cybersecurity products that provide a robust and scalable solution that can be customized to integrate with any network.