Wazuh eventchannel events
34 views
Skip to first unread message
никита какдела
Dec 29, 2025, 6:17:34 AM (2 days ago) Dec 29
to Wazuh | Mailing List
Hello Wazuh Support Team,
I am experiencing an issue with Windows Security Event ID 4624 processing in Wazuh and would appreciate your clarification.
In my environment, not all Event ID 4624 events are processed consistently. I have two very similar 4624 events generated on the same host, from the same channel (Security), with the same logon type and authentication package.
The behavior is the following:
Event 1:
• Is present in archives.log and archives.json
• Passes the built-in Wazuh rules
• Is written to alerts.log
• Is indexed into wazuh-alerts-* and visible in Discover
Event 2:
• Is present in archives.log and archives.json
• Does NOT pass the built-in rules
• Is NOT written to alerts.log as an alert
• Is NOT indexed into wazuh-alerts-* and does not appear in Discover
Both events are structurally identical Windows EventChannel 4624 events. The only noticeable difference is that Event 2 contains network fields (ipAddress and ipPort), while Event 1 does not. Apart from that, both events have the same eventID, logonType (3), authenticationPackageName (Kerberos), and come from the same system.
This leads me to the following questions:
1. Are built-in Wazuh rules for Event ID 4624 dependent on the presence of specific fields such as ipAddress or other network-related attributes?
2. Is it expected behavior that some valid Windows EventChannel 4624 events are archived but never evaluated by built-in rules and therefore never indexed into wazuh-alerts-*?
3. Which exact conditions determine whether a Windows EventChannel event is promoted from archives to alerts and indexed into Discover?
4. Are there any known limitations or design decisions where certain 4624 events are intentionally ignored by default rules, even though they are valid and correctly parsed?
I have verified that both events are correctly collected and stored in archives.log and archives.json, but only one of them is evaluated by the built-in ruleset and indexed.
I can safely provide both raw events from archives.log and archives.json if needed for further analysis.
Thank you in advance for your help.
Best regards,
Shelamov Nikita
I am experiencing an issue with Windows Security Event ID 4624 processing in Wazuh and would appreciate your clarification.
In my environment, not all Event ID 4624 events are processed consistently. I have two very similar 4624 events generated on the same host, from the same channel (Security), with the same logon type and authentication package.
The behavior is the following:
Event 1:
• Is present in archives.log and archives.json
• Passes the built-in Wazuh rules
• Is written to alerts.log
• Is indexed into wazuh-alerts-* and visible in Discover
Event 2:
• Is present in archives.log and archives.json
• Does NOT pass the built-in rules
• Is NOT written to alerts.log as an alert
• Is NOT indexed into wazuh-alerts-* and does not appear in Discover
Both events are structurally identical Windows EventChannel 4624 events. The only noticeable difference is that Event 2 contains network fields (ipAddress and ipPort), while Event 1 does not. Apart from that, both events have the same eventID, logonType (3), authenticationPackageName (Kerberos), and come from the same system.
This leads me to the following questions:
1. Are built-in Wazuh rules for Event ID 4624 dependent on the presence of specific fields such as ipAddress or other network-related attributes?
2. Is it expected behavior that some valid Windows EventChannel 4624 events are archived but never evaluated by built-in rules and therefore never indexed into wazuh-alerts-*?
3. Which exact conditions determine whether a Windows EventChannel event is promoted from archives to alerts and indexed into Discover?
4. Are there any known limitations or design decisions where certain 4624 events are intentionally ignored by default rules, even though they are valid and correctly parsed?
I have verified that both events are correctly collected and stored in archives.log and archives.json, but only one of them is evaluated by the built-in ruleset and indexed.
I can safely provide both raw events from archives.log and archives.json if needed for further analysis.
Thank you in advance for your help.
Best regards,
Shelamov Nikita
никита какдела
Dec 29, 2025, 7:33:27 AM (2 days ago) Dec 29
to Wazuh | Mailing List
I'm encountering an issue where I'm only receiving partial logs for EventID 4624.
That is, I'm not receiving logs enriched with IPAddress.
I can't figure out what the problem is; these logs have the same structure. Both logs are added to archives.log, but one log (the one without IPAddress) is passed through the built-in rules, while the other is not. I've attached a text file with the logs as an example. Event 2 is an event not found in Discover and is not passed through the rules.
That is, I'm not receiving logs enriched with IPAddress.
I can't figure out what the problem is; these logs have the same structure. Both logs are added to archives.log, but one log (the one without IPAddress) is passed through the built-in rules, while the other is not. I've attached a text file with the logs as an example. Event 2 is an event not found in Discover and is not passed through the rules.
понедельник, 29 декабря 2025 г. в 14:17:34 UTC+3, никита какдела:
Jorge Eduardo Molas
Dec 29, 2025, 8:36:55 AM (2 days ago) Dec 29
to Wazuh | Mailing List
Hi,
The behavior you're experiencing is related to rule 92651, which is designed to detect remote network logons (Event ID 4624 with network information) but has a level of 0, preventing alert generation and indexing.
Root Cause
Extract a complete event from archives.json and test it. Note that Windows EventChannel events require special handling in logtest (they need to inherit from rule 60000).
Why This Happens
The built-in rule 92651 was designed with level 0, likely to serve as a parent rule for more specific detections or to avoid alert fatigue from routine network logons. However, this means these events won't appear in your alert index by default.
References
The behavior you're experiencing is related to rule 92651, which is designed to detect remote network logons (Event ID 4624 with network information) but has a level of 0, preventing alert generation and indexing.
Root Cause
- Event 2 (with ipAddress and ipPort fields) matches rule 92651:
<rule id="92651" level="0">
<if_sid>60106</if_sid>
<field name="win.eventdata.ipAddress" type="pcre2">(?:[0-9]{1,3}\.){3}[0-9]{1,3}</field>
<field name="win.eventdata.ipAddress" type="pcre2" negate="yes">127\.0\.0\.1</field>
<description>Successful Remote Logon by user:$(win.eventdata.targetDomainName)\$(win.eventdata.targetUserName) from $(win.eventdata.ipAddress).</description>
</rule>
Rules with level 0 in Wazuh are used for grouping or classification purposes and do not generate alerts that get indexed into wazuh-alerts-*. This is why Event 2 appears in archives.log/archives.json but not in alerts or the dashboard.
To receive alerts for remote logon events (4624 with ipAddress), create a custom rule that overrides or extends rule 92651 with a meaningful alert level.
- Event 1 (without network fields) matches a different rule with a higher level, which is why it generates an alert and gets indexed.
To receive alerts for remote logon events (4624 with ipAddress), create a custom rule that overrides or extends rule 92651 with a meaningful alert level.
- Step 1: Create a custom rule in /var/ossec/etc/rules/local_rules.xml
<group name="windows,authentication,">
<rule id="100651" level="3">
<if_sid>60106</if_sid>
<field name="win.eventdata.ipAddress" type="pcre2">(?:[0-9]{1,3}\.){3}[0-9]{1,3}</field>
<field name="win.eventdata.ipAddress" type="pcre2" negate="yes">127\.0\.0\.1</field>
<description>Successful Remote Logon by user:$(win.eventdata.targetDomainName)\$(win.eventdata.targetUserName) from $(win.eventdata.ipAddress)</description>
<mitre>
<id>T1078</id>
</mitre>
<group>authentication_success,pci_dss_10.2.5,</group>
</rule>
</group>
- Step 2: Restart the Wazuh manager
systemctl restart wazuh-manager
- Step 3: Verify the rule loads correctly
grep "100651" /var/ossec/logs/ossec.log
- Step 4: Test with an archived event using wazuh-logtest
Extract a complete event from archives.json and test it. Note that Windows EventChannel events require special handling in logtest (they need to inherit from rule 60000).
Why This Happens
The built-in rule 92651 was designed with level 0, likely to serve as a parent rule for more specific detections or to avoid alert fatigue from routine network logons. However, this means these events won't appear in your alert index by default.
References
Reply all
Reply to author
Forward
0 new messages