alert for sysmon event id 13

[Maxim Parpaley]

Hi, I create rule alert for event id 13 sysmon in 0595-win-sysmon_rules.xml

Some log work with rule, some log not.

Here, i filter in opensearch.

How can i solve this situation?

Is it error because of rule?

Best Regards,

[Jose Antonio Izquierdo]

Hi Maxim,

I can see you changed the level of rule 61615 to 3 on 0595-win-sysmon_rules.xml.

Few things here:

1.- Do not change a default ruleset file (rules or decoders) as this change will be overwritten in the next update.

2.- Instead, create a new rules file on /var/ossec/etc/rules/my_sysmon_rules.xml or edit /var/ossec/etc/rules/local_rules.xml to include the modified rule.

your rule can be something like this:

  <rule id="100010" level="3">
    <if_sid>61615</if_sid>
    <field name="win.system.eventID">^13$</field>
    <description>Sysmon - Event 13: Custom alert - RegistryEvent $(win.eventdata.eventType) on $(win.eventdata.targetObject) by $(win.eventdata.image)</description>
    <options>no_full_log</options>
    <group>sysmon_event_13,</group>
  </rule>

Check this to get more details on how to customize the ruleset -> https://documentation.wazuh.com/current/user-manual/ruleset/custom.html

Warning: this rule will work only if other sysmon_13 rules are not matched. You have to modify that rule in order to be fired. Instead of modifying this one, try creating a child rule from sysmon_13 rules.

In your case, the problem is that child rules from 61615 are raised. In file 0860-sysmon_id_13.xml you will find the possible child rules that can match a sysmon_event_13 alert fired with 61615.

Right now, I think you have alerts with ids: 92301, and 92302, and when no one is matched, then you will have your 61615.

Consider what are you trying to detect, maybe creating a child of the 92300 rule should work better than your current modification. Remember, try to not change any default ruleset file.

Hope this helps.

Jose.

[Maxim Parpaley]

Hi,

i don't think it alerts with ids: 92301 or 92300 because i filter with event id 13 in opensearch and log with event id 13 will show here.

I found 2 version of 0595-win-sysmon_rules.xml.

1.https://github.com/wazuh/wazuh-ruleset/blob/master/rules/0595-win-sysmon_rules.xml

2.https://github.com/wazuh/wazuh/blob/master/ruleset/rules/0595-win-sysmon_rules.xml

when i install wazuh file default is in link 1 and i replace it by file in link 2.

I'm creating new rule base sysmon log, how can i use my rule with if_sid option exactly?

Now some alert trigger and some is not although this log must be a alert?

Any wrong with it?

Best Regards,

[Jose Antonio Izquierdo]

Hi Maxim, sorry for the late follow-up here. 

The wazuh-ruleset repository is not updated, please do not use it as a Ruleset source, but as a reference of old rules.

About your scenario. 

Before creating an if-sid rule we have to understand where the logs/alerts are being fired. an If-sid rule tries to improve or enrich a current alert. So when we know the sid of the current alert we can create a child rule with the if-sid parameter to improve the output. 

So, we need to understand where the missing alerts are. 

Are you able to find your missing events/alerts in the dashboard anywhere? try to apply filters that will search for event/alert content, not just sysmon event id number. 

If not. we need to try to find where the alert is missed. 

1.- Ensure there is an alert generated for that log. 

    a.- look for the missing alert in /var/ossec/logs/alerts/alerts.json

    b.- if you can see it there, then check filebeat logs (/var/log/filebeat/filebeat) maybe there is some errors there. 

2.- If there is no info in the alerts.json, please find it in /var/ossec/logs/archives/archives.json (how to enable archiving - Set <logall_json>yes</logall_json> in /var/ossec/etc/ossec.conf and restart wazuh-manager) 

This should help us to understand where the missing logs/events/alerts are stopped. 

Hope this helps.

[Maxim Parpaley]

Hi Jose,

Thank, i solved my situation

Best Regards,