Wazuh rule not ignoring system users (e.g. MSOL_, LOCAL SERVICE) based on subjectUserName

[Sander Kamp]

Hey all,

I'm trying to filter out Windows security events in Wazuh that are triggered by system or service accounts like:

• SYSTEM

• UMFD*

• DWM*

• LOCAL SERVICE

• NETWORK SERVICE

• ANONYMOUS LOGON

• Accounts ending with $

• MSOL_*, azureconnect, IUSR*, IWAM*, etc.

I tried using this rule:

xml

KopiërenBewerken

<rule id="999998" level="0"> <regex field="win.eventdata.subjectUserName">^SYSTEM$|^UMFD.*|^DWM.*|^LOCAL SERVICE$|^NETWORK SERVICE$|^ANONYMOUS LOGON$|.*\$|^IUSR.*|^IWAM.*|^MSOL_.*|^azureconnect$</regex> <description>Ignore subjectUserName if it's a system account</description> <ignore>true</ignore> </rule>

But it's not working — the alerts still show up (e.g. for MSOL_136fe95c1a8f or LOCAL SERVICE), even though the field is definitely present in the alert payload (win.eventdata.subjectUserName).

I also tried specifying <if_sid> with the rule that originally fired (e.g., 60104), but even that doesn't seem to help.
Using data.win.eventdata.subjectUserName instead of win.eventdata.subjectUserName also makes no difference.

What am I doing wrong?
Do I need to use match instead of regex?
Is this maybe due to rule chaining and I need to attach this directly to the original rule as if_sid?

Any help appreciated!

[Olamilekan Abdullateef Ajani]

Hello,

I believe these are windows event channel events which you are trying to filter, I made a modification to the rule you shared, please see below, this can be added to the custom rule directory.

<group name="custom_rule,">
  <rule id="102010" level="0">
    <if_group>windows</if_group>
    <field name="win.eventdata.targetUserName">^SYSTEM$|^UMFD.*|^DWM.*|^LOCAL SERVICE$|^NETWORK SERVICE$|^ANONYMOUS LOGON$|.*\$|^IUSR.*|^IWAM.*|^MSOL_.*|^azureconnect$<</field>

      <description>Ignore subjectUserName if it's a system account</description>

  </rule>
</group>

You should also confirm the username field if it is win.eventdata.targetUserName or win.eventdata.subjectUserName, you can just make use of the <field> tag instead of regex. <match> field could also work, it all depends on your use case.

I also want to point out that your values needs to match the output from the log. example, ^SYSTEM$ means what you are expecting is just SYSTEM in the field. If you wan to be flexible, incase the field consist of more values, you could use \.+SYSTEM\.+

You can also review wazuh regex on how it work for proper mapping: https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/regex.html#os-regex-syntax

Lastly, please note, you can filter out these events on  the agent side rather than on the manager side to reduce event flooding. To do this, edit the ossec.conf on the agent and add similar configuration as stated below indicating the event ID you want to silent.

<localfile>
    <location>Security</location>
    <log_format>eventchannel</log_format>
    <query>Event/System[EventID != 5145]</query>
  </localfile>  

If you require additional support on this, please kindly share a reference log.

[Sander Kamp]

Hi,

Thanks for the suggestions! A few quick updates on my end:

• My <field name="win.eventdata.targetUserName"> filter is firing correctly—I’m already dropping all the SYSTEM, UMFD*, DWM*, LOCAL SERVICE, etc., events as expected.

• I’ve double-checked the XML and removed the stray < you pointed out, so the <field> blocks are properly formed now.

• I verified with wazuh-logtest that rule ID 102010 matches on targetUserName, but the <field name="win.eventdata.subjectUserName"> block still never fires, even when I use a permissive regex like .*SYSTEM.*.

• These are plain Windows Security EventChannel logs (not Sysmon), so <if_group>windows</if_group> is definitely correct.

Yet I still see alerts where eventdata.subjectUserName is “SYSTEM.” I’m wondering:

1. Rule scope or order: Could the subjectUserName condition be evaluated too late?

2. Decoder nuance: Should I explicitly add <if_decoder>windows</if_decoder> or include a sysmon group?

3. Event JSON: Is there any chance the field is nested differently or has hidden whitespace/quotes?

If it helps, I can share a sanitized snippet of the exact eventdata JSON for you to reference. Appreciate any further pointers!

Thanks,
Sander

Op dinsdag 10 juni 2025 om 16:42:18 UTC+2 schreef Olamilekan Abdullateef Ajani:

[Olamilekan Abdullateef Ajani]

Hello Sander,

I think the best line of action would be to share a sample log as you have also mentioned, although I still believe the problem here looks like the regex. The logs would give a better understanding of your side of this.

You can also look at Wazuh regex syntax for more pointers on defining a pattern: https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/regex.html#os-regex-syntax

Example:  This .*SYSTEM.* should be written as  \.+SYSTEM\.+

Ref:
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/regex.html#os-regex-syntax