Issue Using Process Paths as Keys in CDB List for Process Creation Whitelisting

[CRIZ]

Hi Wazuh Community,

I am currently testing process creation whitelisting using a CDB list (key-value format) in Wazuh.

My use case is to whitelist known parent process and child process combinations by storing them in a CDB list. However, I am facing an issue where the process path is not being accepted correctly as the key because it contains / (or full file paths in general). As a result, the CDB lookup does not appear to match as expected.

I would like to understand whether using full process paths as CDB keys is supported, whether there are any restrictions on characters such as /, and if there is a recommended approach for whitelisting parent-child process combinations when the values are full executable paths. If this is not the intended use of CDB lists, I would appreciate any guidance on the recommended best practice for implementing this use case.

If anyone has implemented a similar solution, I would be grateful for any suggestions or examples.

Thank you.

[Olamilekan Abdullateef Ajani]

Hello,

Each line in a CDB list is a unique key which is followed by a colon separator. The forward slash / has no special meaning in CDBList context and works fine as part of a key. The character that does break parsing is :, because it is the key/value delimiter. If the key itself contains a colon, you must enclose the whole key in double quotes. This matters immediately for Windows paths, since C:\... contains a colon:

"C:\\Program Files\\Google\\Chrome\\Application\\PSScriptPolicyTest_umhytiates.gw3.exe":

Ref:
https://documentation.wazuh.com/current/user-manual/ruleset/cdb-list.html

Something else to note:
CDB matching is an exact, case-sensitive string comparison, partial matching is not supported, so the key must match the decoded field as is.
The list must be registered under <ruleset> in ossec.conf (relative path, e.g. etc/lists/cdb-test) and the manager must be restarted.

A <list> lookup compares one field against the keys. You can check a field against a key and then check a static string against the stored value via check_value, but you cannot check field1 against the key and field2 against the value, check_value does not support dynamic field references like $(win.eventdata.image); it only takes a static value. This is a known, open feature request. Also remember keys must be unique, so you can't have multiple lines with the same parent path as the key to list several allowed children.
Ref:
https://github.com/wazuh/wazuh/issues/14252

So match one for one first and ensure that works or use

For exact parent-child whitelisting, a Wazuh-native approach is to create one rule per parent process and keep a CDB list of allowed child processes for that parent.  

<rule id="100210" level="0">
  <if_sid>baserule</if_sid>  
  <field name="win.eventdata.parentImage" type="pcre2">(?i)\\services\.exe$</field>
  <list field="win.eventdata.newProcessName" lookup="match_key">etc/lists/cdb-test-for-children</list>
  <description>Whitelisted child of services.exe</description>
</rule>
<rule id="100211" level="7">
  <if_sid>baserule</if_sid>
  <field name="win.eventdata.parentImage" type="pcre2">(?i)\\services\.exe$</field>
  <list field="win.eventdata.image" lookup="not_match_key">etc/lists/cdb-test-for-children</list>
  <description>Unexpected child of services.exe: $(win.eventdata.image)</description>
</rule>

So in short, full paths are supported, but exact parent-child is what you need to design carefully, as you cannot use the CDBlist to compare both fields.

Ref:
https://documentation.wazuh.com/current/user-manual/ruleset/cdb-list.html