Wazuh 4.14.7 CDB lookup occasionally fails for existing vendor entries in custom software policy rule

[ARUN S]

Hi Team,

We recently upgraded our Wazuh Manager and agents to 4.14.7 and are using a custom software policy rule based on a CDB list of approved software vendors.

Rule:

<group name="allowapplication,">

<rule id="100500" level="16">

<if_sid>61603</if_sid>

<list field="win.eventdata.company" lookup="not_match_key">

etc/lists/software-vendors

</list>

<description>

Sysmon - Event 1: Process $(win.eventdata.description) started but not allowed by the software policy

</description>

<group>software_policy</group>

</rule>

</group>

The rule is intended to generate an alert when the Sysmon Event ID 1 Company field is not present in the CDB whitelist.

Problem

Most whitelist entries work correctly.

However, we occasionally receive Rule 100500 alerts for vendors that already exist in the CDB list.

Examples:

Microsoft Corporation

Sysmon Event:

"company":"Microsoft Corporation"

List entry:

Microsoft Corporation:

Alert still generated:

Sysmon - Event 1: Process Console Window Host started but not allowed by the software policy

Example process:

C:\Windows\System32\conhost.exe

Company: Microsoft Corporation

---

Amazon.com Inc.

Sysmon Event:

"company":"Amazon.com Inc."

List entry:

Amazon.com Inc.:

Alert still generated:

Sysmon - Event 1: Process OpenJDK Platform binary started but not allowed by the software policy

Example process:

C:\Program Files (x86)\AWS Replication Agent\jre\bin\java.exe

Company: Amazon.com Inc.

Validation performed

• Confirmed win.eventdata.company exists in incoming Sysmon events.
• Verified exact strings in alerts:
  • Microsoft Corporation
  • Amazon.com Inc.
• Verified matching entries exist in the software-vendors list.
• Rebuilt/reloaded lists and restarted manager.
• Most vendors match correctly.
• Issue appears sporadic and only affects some executions.

Questions

1. Is there any known issue in Wazuh 4.14.x involving CDB lookups with lookup="not_match_key"?
2. Is there a recommended method to verify the value being evaluated by the <list> condition during rule matching?
3. Could analysisd use a stale cached CDB after upgrades/restorations?
4. Are there known issues where Sysmon Event 1 fields appear correctly in alerts but fail CDB matching during rule evaluation?

Any guidance would be appreciated.

Thanks.

Arun S

[Md. Nazmur Sakib]

Hi Arun,

There's no confirmed 4.14.x bug I know of where not_match_key fails on one occasion and works on another.

I would like you to review whether this fails only for some specific company names.

If this works for the same company name sometimes and also fails for the company with the same name. Review the two different events. Check if the company name has a similar value.

For the CDB list to match, the field value needs to be the same as the decoded field. If there is any additional whitespace or a different case of the alphabet, the CDB list will not work.

The issue also might be related to a high EPS (events per second) rate in your Wazuh environment. This could cause wazuh-analysisd to miss or fail to properly evaluate the CDB list, resulting in false positive alerts. There are similar discussions on GitHub regarding this behavior. You may refer to the linked GitHub thread for more context.

• https://github.com/wazuh/wazuh/issues/17026

• https://github.com/wazuh/wazuh/issues/4067

Workaround:

If your CDB list is relatively short, you can use the <field> tag with negate="yes" instead of a CDB list to achieve similar logic. For example:  

<group name="allowapplication,">

<rule id="100500" level="16">

<if_sid>61603</if_sid>

<field name="win.eventdata.company" negate="yes" type="pcre2">value1|value2|value3</field>

<description>Sysmon - Event 1: Process $(win.eventdata.description) started but not allowed by the software policy</description>

<group>software_policy</group>

</rule>

</group>

In this rule:

• If the table field matches any of the listed values (value1, value2, value3), the rule will not trigger due to the negate="yes" option.

• If the value does not match any of the listed values, the rule will trigger as expected.

You can replace value1, value2, etc., with your actual company names.

Refer to these documents for more details.

Wazuh rule syntax documentation
Regular Expression Syntax
Perl-compatible Regular Expressions