CDB List matching not working as expected.

[Jeremy Utley]

I've developed a rule using a custom CDB list, and it doesn't seem to be working as I expect it to.  I'll start with some background of what I'm trying to accomplish.

We've set up a log pipeline to bring AWS Cloudwatch logs into Wazuh.  Because of the volume of logs we are dealing with in our environment, we can't use the AWS wodle, because it ends up blocking way too much.  So instead, we've implemented subscriptions to our log groups with AWS Data Firehose.  Firehose sends the logs into a running Vector.dev setup that parses the data, and then feeds the logs into Wazuh via Syslog protocol as JSON.

In Wazuh, one particular type of data we are alerting on is our RDS Audit logs - if there's any write activity to particular tables that should not normally be written to, we want to trigger an alert.  To implement this, we created a CDB list of the tables we do not want to alert on, and reference that in our rules.  The problem we are facing is that we are still seeing alerts for tables listed in our CDB list.

Our rules:

<rule id="105030" level="0">
      <if_sid>105024</if_sid>
      <field name="query_action">insert|update|delete</field>
      <description>RDS Audit Log - tc-db table modification</description>
      <group>custom_rds_audit_tcdb_table_change,</group>
    </rule>
<rule id="105031" level="5">
      <if_sid>105030</if_sid>
      <list field="table" lookup="not_match_key">etc/lists/tcdb-frequent-changed-tables</list>
      <description>RDS Audit Log - tc-db unexpected table modification</description>
      <group>custom_rds_audit_tcdb_unexpected_table_change,</group>
    </rule>

105030 should detect any type of insert, update, or delete query.  105031 should take anything that matches 105030, and if the table modified does not match a table in the CDB list, issues a level 5 alert.

However, I am getting alerts from 105031 for tables that ARE listed in the CDB list.  One specific JSON event that this happened on is:

{"aws_timestamp":"1754058773531273","connection_id":"406683","database":"ccp","id":"39116817771761961933107835159953888841940354770400116939","instance_name":"tc-db01","log_group":"/aws/rds/cluster/tc-db-lts-cluster/audit","log_stream":"tc-db01.audit.log.0","message_origin":"rds-audit","message_type":"DATA_MESSAGE","object":"INSERT INTO transactions_meta_data (var_name, var_value, transaction_id) VALUES (\\'price_taxRuleId\\', \\'2701\\', 196647777)","operation":"QUERY","owner":"464811824699","query_action":"insert","query_id":"1687407245","return_code":"0","source":"cloudwatchlogs","src_host":"10.50.250.234","table":"transactions_meta_data","timestamp":"2025-08-01T14:32:53.531Z","username":"api-tc-pl-prod"}

The table "transactions_meta_data" table is listed in the CDB list.  And in fact, if I run that exact json event thru the Ruleset test, it shows that the matching rule should be 105030:

**Phase 1: Completed pre-decoding.
full event: '{"aws_timestamp":"1754058773531273","connection_id":"406683","database":"ccp","id":"39116817771761961933107835159953888841940354770400116939","instance_name":"tc-db01","log_group":"/aws/rds/cluster/tc-db-lts-cluster/audit","log_stream":"tc-db01.audit.log.0","message_origin":"rds-audit","message_type":"DATA_MESSAGE","object":"INSERT INTO transactions_meta_data (var_name, var_value, transaction_id) VALUES (\\'price_taxRuleId\\', \\'2701\\', 196647777)","operation":"QUERY","owner":"464811824699","query_action":"insert","query_id":"1687407245","return_code":"0","source":"cloudwatchlogs","src_host":"10.50.250.234","table":"transactions_meta_data","timestamp":"2025-08-01T14:32:53.531Z","username":"api-tc-pl-prod"}'

**Phase 2: Completed decoding.
name: 'json'
aws_timestamp: '1754058773531273'
connection_id: '406683'
database: 'ccp'
id: '39116817771761961933107835159953888841940354770400116939'
instance_name: 'tc-db01'
log_group: '/aws/rds/cluster/tc-db-lts-cluster/audit'
log_stream: 'tc-db01.audit.log.0'
message_origin: 'rds-audit'
message_type: 'DATA_MESSAGE'
object: 'INSERT INTO transactions_meta_data (var_name, var_value, transaction_id) VALUES (\'price_taxRuleId\', \'2701\', 196647777)'
operation: 'QUERY'
owner: '464811824699'
query_action: 'insert'
query_id: '1687407245'
return_code: '0'
source: 'cloudwatchlogs'
src_host: '10.50.250.234'
table: 'transactions_meta_data'
timestamp: '2025-08-01T14:32:53.531Z'
username: 'api-tc-pl-prod'

**Phase 3: Completed filtering (rules).
id: '105030'
level: '0'
description: 'RDS Audit Log - tc-db table modification'
groups: '["custom_rds","custom_rds_audit_tcdb_table_change"]'
firedtimes: '1'
mail: 'false'

So in this case, the Ruleset test says 105030 should match, and no alert would be generated.  However, when this event was actually received by Wazuh, 105031 matched, and a level 5 event was generated, and I'm not sure why.

Anyone got any ideas?

[Bony V John]

Hi,

Apologies for the late response.

Based on the details you shared, I have replicated and tested the configuration in my environment. It is working as expected—when the value in the table field is not present in the CDB list, the rule with ID 105031 is triggered, and an alert is generated.

In your case, the issue 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:  

   <rule id="105031" level="5">

      <if_sid>105030</if_sid>
      <field name="table" negate="yes" type="pcre2">transactions_meta_data|value2|value3</field>

      <description>RDS Audit Log - tc-db unexpected table modification</description>
      <group>custom_rds_audit_tcdb_unexpected_table_change,</group>
    </rule>

In this rule:

• If the table field matches any of the listed values (transactions_meta_data, 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 value2, value3, etc., with your actual table names.

Refer to the Wazuh rule syntax documentation for more details.