Those who have been using Sysmon for a while will be aware that for some time now there has been a disparity between how filter rules were intended to work and how they worked in practice. The purpose of this post is to hopefully clarify some of the common sources of confusion and to explain why things are the way they are. With that said, let’s dive straight in.
Multiple rules on the same field
This is the most basic case and the least confusing because it has always been and remains the case today that these will be combined using ‘OR’. So the following example will cause Sysmon to log a process creation event only when the command line contains iexplore.exe OR firefox.exe
<EventFiltering>
<ProcessCreate onmatch="include">
<CommandLine condition="contains">iexplore.exe</CommandLine>
<CommandLine condition="contains">firefox.exe</CommandLine>
</ProcessCreate>
</EventFiltering>
A variation on this configuration is where we might have include and exclude rules on the same event. Here exclude rules will always take precedence. Thus in the following example we will omit our browser events when the browser was launched by explorer.exe.
<EventFiltering>
<ProcessCreate onmatch="include">
<CommandLine condition="contains">iexplore.exe</CommandLine>
<CommandLine condition="contains">firefox.exe</CommandLine>
</ProcessCreate>
<ProcessCreate onmatch="exclude">
c:\windows\explorer.exe
</ProcessCreate>
</EventFiltering>
So far so good. Most users I speak with are happy with this. Where they are less comfortable is how rules for different fields are combined. So let’s talk about that next
Multiple rules on different fields
For reasons that are multiple and largely self-inflicted, this is the main source of confusion. The documentation has always stated that rules on different fields would be combined using ‘AND’ and in some cases this was true but in others it was not. Over the years we have tried to address some of the edge cases but generally this has been a non-deterministic hybrid of both depending on which combinations of fields were being used and which events they were applied to.
All this changed in Sysmon 8.02. In response to repeated requests to make this behaviour match the documentation I resolved the hybrid AND/OR filtering once and for all so that the ‘AND’ logic worked consistently. This now matched the documentation and everybody was happy.
Or not. Although the implementation was now consistent with the documentation, it turned out that prior to this change, many of the most commonly used fields were previously being combined using ‘OR’. Users were aware that this was contrary to the documentation but since this is the way it worked in practice they had no choice but to assume ‘OR’ anyway and had come to rely on it working that way. Thus for these users 8.02 broke their existing configurations and broke them badly.
Rule groups
In Sysmon 9.0 we introduced the concept of Rule Groups as a response to satisfy the competing demands of one set of users who wanted to combine their rules using ‘AND’ along with those who wanted to continue using ‘OR’.
Rule groups are completely optional and can be used to explicitly define the way that rules on different fields are combined. At the most basic level a single rule group with or without an optional name attribute can be applied to the entire configuration
<EventFiltering>
<RuleGroup groupRelation="or">
<ProcessCreate onmatch="exclude"/>
<ImageLoad onmatch="exclude"/>
</RuleGroup>
</EventFiltering>
Alternatively multiple rule groups can be used for different events
<EventFiltering>
<RuleGroup name=”group1” groupRelation="or">
<ProcessCreate onmatch="exclude"/>
</RuleGroup>
<RuleGroup name=”group2” groupRelation="and">
<ImageLoad onmatch="exclude"/>
</RuleGroup>
</EventFiltering>
It is also possible to exclude events from the rule group completely such as the NetworkConnect events in the following example
<EventFiltering>
<RuleGroup name=”group1” groupRelation="or">
<ProcessCreate onmatch="exclude"/>
</RuleGroup>
<RuleGroup name=”group2” groupRelation="and">
<ImageLoad onmatch="exclude"/>
</RuleGroup>
<NetworkConnect onmatch="exclude"/>
</EventFiltering>
Default values
Since rule groups are optional and because events may be omitted from a rule group, we had to pick a default value for these rules. In light of our experience when switching from ‘OR’ to ‘AND’ in Sysmon 8.02, we opted to revert to ‘OR’ for this default.
It is important to note however that this is for backwards compatibility purposes only so that users are able to move to Sysmon 9.0 and later without modifying their configuration files. The desire is to reinstate the intended default value of ‘AND’ as stated in the documentation and for this reason we have linked the default value to the schemaversion. Sysmon 9.0 was released with a schema version of 4.1 so anything with 4.1 and lower will default to ‘OR’ and anything with a schema version greater than 4.1 will default to ‘AND’.
Thus in the following example, we will record process creation events when either the command line contains iexplore.exe OR the parent command line contains explorer.exe
<Sysmon schemaversion="4.1">
<EventFiltering>
<ProcessCreate onmatch="include">
<CommandLine condition="contains">iexplore.exe</CommandLine>
<ParentCommandLine condition="contains">explorer.exe</CommandLine>
</ProcessCreate/>
</EventFiltering>
<Sysmon>
Whereas in this example example we will only record events when both the command line AND the parent command line match.
<Sysmon schemaversion="4.21">
<EventFiltering>
<ProcessCreate onmatch="include">
<CommandLine condition="contains">iexplore.exe</CommandLine>
<ParentCommandLine condition="contains">explorer.exe</CommandLine>
</ProcessCreate/>
</EventFiltering>
<Sysmon>
Recently we added DNS logging to Sysmon. This has been a popular feature but to take advantage of it you need to increment the schema version to 4.21. Several users have reported issues with their configuration files after enabling DNS so hopefully the reasons for this are now clear. If your configuration relied on the legacy ‘OR’ behaviour the solution is to add a top level rule group that defines this explicitly as shown in the following example.
<Sysmon schemaversion="4.21">
<EventFiltering>
<RuleGroup groupRelation="or">
<ProcessCreate onmatch="include">
<CommandLine condition="contains">iexplore.exe</CommandLine>
<ParentCommandLine condition="contains">explorer.exe</CommandLine>
</ProcessCreate/>
</RuleGroup>
</EventFiltering>
<Sysmon>
While we continue to evolve the rule structure and flexibility, we have to be sensitive to any additional performance impact. Nevertheless if you have comments or suggestions on how we might be able to make this work better in your environment then we would love to hear from you at syssite@microsoft.com.
Microsoft
