Rule for ignoring duplicate alerts/events
16 views
Skip to first unread message
Nicolae Sirbu
Dec 19, 2025, 11:53:27 AM (17 hours ago) Dec 19
to Wazuh | Mailing List
Hello Team,
We are running Wazuh 4.14.1 and have implemented a custom decoder and a custom rule (both attached to this ticket) that are functioning as intended.
However, we are occasionally receiving duplicate log events. These events are essentially identical, with only the timestamp differing.
To suppress these duplicates, I attempted to create an additional rule (also attached) using if_matched_sid applied to the custom field data.deep.Id. Unfortunately, this approach did not work as expected.
Could you please assist us in resolving this filtering issue?
Examples of the duplicate log events:
We are running Wazuh 4.14.1 and have implemented a custom decoder and a custom rule (both attached to this ticket) that are functioning as intended.
However, we are occasionally receiving duplicate log events. These events are essentially identical, with only the timestamp differing.
To suppress these duplicates, I attempted to create an additional rule (also attached) using if_matched_sid applied to the custom field data.deep.Id. Unfortunately, this approach did not work as expected.
Could you please assist us in resolving this filtering issue?
Examples of the duplicate log events:
- 1 2025-12-19T07:37:03.511Z 1.1.1.1 D-Appliance - 9087788 - CEF:0|Deep Instinct|D-Appliance|7.4.1.0|SecurityEvent_Detected|Script Control - Command|9|eventExternalId=9087788 act=Detected dvchost=1.1.1.1 dhost=user-pc dst=10.70.0.8 dmac=1C:91:92:63:79:1F dLoggedInUsers=DC\\USER USER duser=DC\\USER USER dGroup=company<WIN>:Contosco dclientVersion=5.2.0000.2 deviceExternalId=11452 policy=WINDETECT start=2025-12-19T07:37:03.511Z rt=2025-12-19T07:37:03.511Z externalSeverity=1 processChain=<wininit.exe|700> <services.exe|780> <Agent.exe|12316> <cmd.exe|1348> <powershell.exe|7320> occurrences=4 lastOccurrence=2025-12-19 07:37:03.718150 filePath=powershell.exe -executionpolicy unrestricted -file \"C:\\ProgramData\\Agent\\Plugins\\Temporary\\ScriptsTemp\\95ad7687-bab3-4253-7uy4-1e5c986f01or.ps1\" fileType=POWERSHELL cs1=Windows cs1label=OS Name cs2=142w cs2Label=EngineVersion mitreId=TA0002.T1059.003 mitreTactic=Execution mitreTechnique=Command and Scripting Interpreter mitreSubTechnique=Windows Command Shell mitreId=TA0002.T1059.001 mitreTactic=Execution mitreTechnique=Command and Scripting Interpreter mitreSubTechnique=PowerShell cs4=owner:{9557c1yt-b763-4li5-lk4d-ef9jh3f609uy} cs4Label=MSPName cs5=stage:prod cs5Label=TenantName cs6=Windows 10 Pro cs6Label=osVersion
- 1 2025-12-19T07:37:03.511Z 1.1.1.1 D-Appliance - 9087788 - CEF:0|Deep Instinct|D-Appliance|7.4.1.0|SecurityEvent_Detected|Script Control - Command|9|eventExternalId=9087788 act=Detected dvchost=1.1.1.1 dhost=user-pc dst=10.70.0.8 dmac=1C:91:92:63:79:1F dLoggedInUsers=DC\\USER USER duser=DC\\USER USER dGroup=company<WIN>:Contosco dclientVersion=5.2.0000.2 deviceExternalId=11452 policy=WINDETECT start=2025-12-19T07:37:03.511Z rt=2025-12-19T07:37:03.511Z externalSeverity=1 processChain=<wininit.exe|700> <services.exe|780> <Agent.exe|12316> <cmd.exe|1348> <powershell.exe|7320> occurrences=1 lastOccurrence=2025-12-19 07:37:03.511627 filePath=powershell.exe -executionpolicy unrestricted -file \"C:\\ProgramData\\Agent\\Plugins\\Temporary\\ScriptsTemp\\95ad7687-bab3-4253-7uy4-1e5c986f01or.ps1\" fileType=POWERSHELL cs1=Windows cs1label=OS Name cs2=142w cs2Label=EngineVersion mitreId=TA0002.T1059.003 mitreTactic=Execution mitreTechnique=Command and Scripting Interpreter mitreSubTechnique=Windows Command Shell mitreId=TA0002.T1059.001 mitreTactic=Execution mitreTechnique=Command and Scripting Interpreter mitreSubTechnique=PowerShell cs4=owner:{9557c1yt-b763-4li5-lk4d-ef9jh3f609uy} cs4Label=MSPName cs5=stage:prod cs5Label=TenantName cs6=Windows 10 Pro cs6Label=osVersion
Hernan Matias Villan
Dec 19, 2025, 2:44:53 PM (14 hours ago) Dec 19
to Wazuh | Mailing List
Hello, Nicolae
Composite rules (those defined with a frequency and timeframe) are designed for detecting repetition and patterns within a specific timeframe, not for filtering or deduplication. When a composite rule triggers, it only replaces the alert for the specific event that met the frequency threshold (the last one in the sequence). This means the preceding events still generate alerts based on the base rule, while only the final "triggering" event is promoted to the composite alert.
If you were to set a composite rule to a level lower than 3 (the default minimum for alert generation), it would not act as a deduplicator for the entire sequence; instead, it would simply silence the final alert in a burst. Because the engine is only comparing the rule.id and not the actual content or payload of the logs, this approach leads to "half-reporting." You would be suppressing the notification for the triggering event while allowing the previous events to fire, effectively hiding the conclusion of the sequence without ever verifying if the logs were truly duplicates or distinct alerts matching the same rule.
The most effective way to resolve this issue is to address the source of the logs to ensure they are not being duplicated before reaching the manager. You should verify that the same events are not being written to multiple locations or collected simultaneously from different log files, as resolving the redundancy at the ingestion point is far more reliable than attempting to filter it through rule correlation.
Composite rules (those defined with a frequency and timeframe) are designed for detecting repetition and patterns within a specific timeframe, not for filtering or deduplication. When a composite rule triggers, it only replaces the alert for the specific event that met the frequency threshold (the last one in the sequence). This means the preceding events still generate alerts based on the base rule, while only the final "triggering" event is promoted to the composite alert.
If you were to set a composite rule to a level lower than 3 (the default minimum for alert generation), it would not act as a deduplicator for the entire sequence; instead, it would simply silence the final alert in a burst. Because the engine is only comparing the rule.id and not the actual content or payload of the logs, this approach leads to "half-reporting." You would be suppressing the notification for the triggering event while allowing the previous events to fire, effectively hiding the conclusion of the sequence without ever verifying if the logs were truly duplicates or distinct alerts matching the same rule.
The most effective way to resolve this issue is to address the source of the logs to ensure they are not being duplicated before reaching the manager. You should verify that the same events are not being written to multiple locations or collected simultaneously from different log files, as resolving the redundancy at the ingestion point is far more reliable than attempting to filter it through rule correlation.
Reply all
Reply to author
Forward
0 new messages