Correlate callerProcessID (Windows EventChannel) with processId (Sysmon) when decoder can't be changed

Mian Muzammil

unread,

Sep 18, 2025, 9:29:10 AM (6 days ago) Sep 18

to Wazuh | Mailing List

Hello everyone — I need help with correlating two Windows events in Wazuh and I’m stuck. I’ll keep it short and give the details, the rules I’m using, and the exact problem.

Goal

Correlate a DPAPI access event (Windows EventChannel) that contains win.eventdata.callerProcessID with a Sysmon process creation event that contains win.eventdata.processId.

Problem

I can’t compare the two fields because they have different key names (callerProcessID vs processId).
My idea was to update the decoder to add a new key (for example win.eventdata.processId) with the value of callerProcessID, but I cannot change the windows_eventchannel decoder (this is a managed/standard decoder). See related discussion: https://github.com/wazuh/wazuh/issues/3193 and https://groups.google.com/g/wazuh/c/i4oOe19YqME

<group name="windows,dpapi,">
<rule id="100100" level="5">
<if_sid>60009</if_sid>
<field name="win.system.providerName">Microsoft-Windows-Crypto-DPAPI</field>
<field name="win.system.eventID">16385</field>
<field name="win.eventdata.dataDescription">Google Chrome</field>
<description>Google Chrome DPAPI decryption detected (Chrome secrets accessed) with caller id $(win.eventdata.callerProcessID).</description>
<mitre>
<id>T1555</id>
<id>T1539</id>
</mitre>
</rule>

<rule id="100200" level="12" timeframe="300">
<if_group>sysmon_eid1_detections</if_group>
<if_matched_sid>100100</if_matched_sid>

<description>
caller ID: $(win.eventdata.callerProcessID) 
process ID: $(win.eventdata.processId)
Info-stealer correlation: executable $(win.eventdata.image)
(originalFileName: $(win.eventdata.originalFileName);
hashes: $(win.eventdata.hashes);
commandLine: $(win.eventdata.commandLine);
user: $(win.eventdata.user);
parentImage: $(win.eventdata.parentImage))
with PID $(win.eventdata.processId) correlated to DPAPI access: Google Chrome.
</description>
<mitre>
<id>T1555</id>
<id>T1539</id>
<id>T1055</id>
</mitre>
<group>info_stealer,credential_access,correlation</group>
</rule>
</group>

Attachments

sysmon_eid1_detections.json (contains processId)
rule100100.json (contains callerProcessID)

Is there a way in Wazuh rules/rule correlation to compare or match two fields with different names across events (e.g., match win.eventdata.callerProcessID from the matched rule to win.eventdata.processId from the incoming Sysmon event) without editing the core windows_eventchannel decoder?

If not, what practical workarounds do you recommend?

rule100100.json

sysmon_eid1_detections.json

Federico Gustavo Galland

unread,

Sep 18, 2025, 10:17:47 AM (6 days ago) Sep 18

to Wazuh | Mailing List

Hey Mian,

Let me go through this and try a few approaches before I share them here with you.

Regards,

Fede

Federico Gustavo Galland

unread,

Sep 19, 2025, 9:54:35 AM (5 days ago) Sep 19

to Wazuh | Mailing List

Mian,

Since the fields to be compared are not named the same, and considering the events come from the Windows Event Channel, which implies we cannot tap into the decoding phase, we need to create a custom active response setup for this.

First off, download the attached correlation and correlation.sh scripts and place them in your manager's /var/ossec/active-response/bin directory.

Next up, give them the right permissions and ownership:

chmod 750 /var/ossec/active-response/bin/correlation*

chown root:wazuh /var/ossec/active-response/bin/correlation*

Now, add the following block to your /var/ossec/etc/ossec.conf file which triggers the scripts above when rule 100600 is fired.

<ossec_config>

<command>
<name>correlation</name>
<executable>correlation</executable>
</command>

<active-response>
<disabled>no</disabled>
<command>correlation</command>
<location>server</location>
<rules_id>100600</rules_id>
</active-response>
</ossec_config>

Following this, we have to set up rules and decoders as follows:

root@manager:~# cat /var/ossec/etc/decoders/correlate_sysmon.xml
<decoder name="correlate_sysmon">
<prematch>Matching process ID and caller Process ID</prematch>
<regex>Matching process ID and caller Process ID in alerts with rule ID (\d+) and (\d+)</regex>
<order>caller_rule_id,callee_rule_id</order>
</decoder>

root@manager:~# cat /var/ossec/etc/rules/correlate_sysmon.xml
<group name="windows,dpapi,">
<rule id="100600" level="5">

<if_sid>60009</if_sid>
<field name="win.system.providerName">Microsoft-Windows-Crypto-DPAPI</field>
<field name="win.system.eventID">16385</field>
<field name="win.eventdata.dataDescription">Google Chrome</field>
<description>Google Chrome DPAPI decryption detected (Chrome secrets accessed) with caller id $(win.eventdata.callerProcessID).</description>

</rule>

<rule id="100610" level="12">
<decoded_as>correlate_sysmon</decoded_as>
<description>Correlation rule between events from rules 92032 and 100600</description>
<match>Matching process ID and caller Process ID in alerts with rule ID</match>
</rule>
</group>

Once you've performed all these steps, you can restart your manager for changes to take effect:

systemctl restart wazuh-manager

Whenever rules 92032 and 100600 are fired in quick succession (30 seconds with the script's default values) and as long as the callerProcessID from 100600 matches the processID from 92032, a new alert will be issued, with level 12 and rule.id 100610.

This looks as follows in my dashboard:

In my following e-mail I'll break down the process involved in this.

correlation.sh

correlation

Federico Gustavo Galland

unread,

Sep 19, 2025, 10:01:36 AM (5 days ago) Sep 19

to Wazuh | Mailing List

In the steps above, we are basically setting up the following workflow:

When custom rule 100600 is triggered, an active response is issued, launching the correlation.sh bash script
The script performs a search on the Wazuh Indexer, looking for events from the past 30 seconds (this is configurable) where the processID matches the trigger alert's callerProcessID field value. In addition, the event must be part of the sysmon group.
If such an event is found, an event is submitted to the Wazuh Manager's queue socket.
The event submitted in the previous step is decoded and then it matches rule 100610, with level 12
This alert is indexed and shown in the dashboard

You can tweak a number of parameters of the active response script by changing the following constants in the script:

root@manager:~# head -16 /var/ossec/active-response/bin/correlation.sh
#!/bin/bash

# --- Configuration ---
DEBUG="1"
DATE_CMD="date '+%Y-%m-%d %H:%M:%S'"
INDEXER_HOST="127.0.0.1"
INDEXER_PORT="9200"
INDEX_PATTERN="wazuh-alerts-4.x-*"
INDEX_USER="admin"
INDEX_PASS="admin"
TIME_RANGE="30s"
SLEEP_SECONDS=25
LOG_FILE="/var/ossec/logs/active-responses.log"
WAZUH_SOCKET="/var/ossec/queue/sockets/queue"
DEPENDENCIES=(ncat jq)
ALERT_MSG="Matching process ID and caller Process ID in alerts with rule ID 92032 and 100600"

Hope this helps.

Regards,

Fede

Mian Muzammil

unread,

Sep 20, 2025, 5:41:10 AM (4 days ago) Sep 20

to Wazuh | Mailing List

Hi Federico — thanks a lot for the great answer, really appreciated!

A few questions — I made two changes on my side in correlation.sh script:

Added the wazuh_index password.
Increased the correlation timeframe from 30s → 240s.

After that the active response was triggered (logs below). I can also see the alert lines in alerts.json on the manager, but the alerts do not appear in the Wazuh dashboard.

— active response log—
2025-09-20 12:20:54 - [DEBUG] Running /var/ossec/active-response/bin/correlation.sh
2025-09-20 12:21:19 - [DEBUG] Waiting for input
2025-09-20 12:21:19 - [DEBUG] {"version":1,"origin":{"name":"node01","module":"wazuh-execd"},"command":"add","parameters":{"extra_args":[],"alert":{"timestamp":"2025-09-20T09:19:14.201+0000","rule":{"level":5,"description":"Google Chrome DPAPI decryption detected (Chrome secrets accessed) with caller id 10652.","id":"100600","firedtimes":5,"mail":false,"groups":["windows","dpapi"]},"agent":{"id":"001","name":"DESKTOP-LLOLL7R","ip":"192.168.1.30"},"manager":{"name":"WazuhSIEM"},"id":"1758359954.25429293","full_log":"{\"win\":{\"system\":{\"providerName\":\"Microsoft-Windows-Crypto-DPAPI\",\"providerGuid\":\"{89fe8f40-cdce-464e-8217-15ef97d4c7c3}\",\"eventID\":\"16385\",\"version\":\"0\",\"level\":\"4\",\"task\":\"64\",\"opcode\":\"0\",\"keywords\":\"0x2000000000000040\",\"systemTime\":\"2025-09-20T09:19:14.0344384Z\",\"eventRecordID\":\"3924\",\"processID\":\"668\",\"threadID\":\"752\",\"channel\":\"Microsoft-Windows-Crypto-DPAPI/Debug\",\"computer\":\"DESKTOP-LLOLL7R\",\"severityValue\":\"INFORMATION\",\"message\":\"\\\"DPAPIDefInformationEvent\\\"\"},\"eventdata\":{\"operationType\":\"SPCryptUnprotect\",\"dataDescription\":\"Google Chrome\",\"masterKeyGUID\":\"{031843ca-f346-4164-9a8a-2229c3e55527}\",\"flags\":\"1\",\"protectionFlags\":\"16\",\"returnValue\":\"0\",\"callerProcessStartKey\":\"2251799814192519\",\"callerProcessID\":\"10652\",\"callerProcessCreationTime\":\"134028335526122890\",\"plainTextDataSize\":\"32\"}}}","decoder":{"name":"windows_eventchannel"},"data":{"win":{"system":{"providerName":"Microsoft-Windows-Crypto-DPAPI","providerGuid":"{89fe8f40-cdce-464e-8217-15ef97d4c7c3}","eventID":"16385","version":"0","level":"4","task":"64","opcode":"0","keywords":"0x2000000000000040","systemTime":"2025-09-20T09:19:14.0344384Z","eventRecordID":"3924","processID":"668","threadID":"752","channel":"Microsoft-Windows-Crypto-DPAPI/Debug","computer":"DESKTOP-LLOLL7R","severityValue":"INFORMATION","message":"\"DPAPIDefInformationEvent\""},"eventdata":{"operationType":"SPCryptUnprotect","dataDescription":"Google Chrome","masterKeyGUID":"{031843ca-f346-4164-9a8a-2229c3e55527}","flags":"1","protectionFlags":"16","returnValue":"0","callerProcessStartKey":"2251799814192519","callerProcessID":"10652","callerProcessCreationTime":"134028335526122890","plainTextDataSize":"32"}}},"location":"EventChannel"},"program":"active-response/bin/correlation"}}
2025-09-20 12:21:19 - Matching Alerts found in the last 130s (hits: 1)
2025-09-20 12:21:19 - [DEBUG] Pushing alert to /var/ossec/queue/sockets/queue

— log from alerts.json —
{"timestamp":"2025-09-20T09:21:19.641+0000","rule":{"level":12,"description":"Correlation rule between events from rules 92032 and 100600","id":"100610","firedtimes":5,"mail":true,"groups":["windows","dpapi"]},"agent":{"id":"000","name":"WazuhSIEM"},"manager":{"name":"WazuhSIEM"},"id":"1758360079.26125353","full_log":"Matching process ID and caller Process ID in alerts with rule ID 92032 and 100600\n","decoder":{"name":"correlate_sysmon"},"data":{"caller_rule_id":"92032","callee_rule_id":"100600"},"location":"/var/ossec/active-response/bin/correlation.sh"}

Could you help me identify what might be wrong? Also, how can I print binary details from rule 92032 (image name, download path, PID, etc.) in the alert?

Best Regards,

Federico Gustavo Galland

unread,

Sep 22, 2025, 7:20:53 AM (2 days ago) Sep 22

to Mian Muzammil, Wazuh | Mailing List

Mian,

From the looks of it, it seems your rule is not showing on your dashboard because it ends with a newline escape code, which may be throwing the dashboard off (see the "\n" at the end of "full_log" in your alerts.json extract).

I just checked my alerts, and mine do not include such a character. Perhaps it was added in your modifications to the file?

Regards,

Fede

--
You received this message because you are subscribed to a topic in the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/3tDKZUgDScY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wazuh+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wazuh/86c174be-cad3-409d-b6e5-bd69de8a56e3n%40googlegroups.com.

--

Federico Galland Wazuh Indexer Team
+1 (844) 349 2984	wazuh.com
federico...@wazuh.com	f-galland

Reply all

Reply to author

Forward