Possible bug - Use of "is not"-filter in rules without specified groupRelation

Question

I found something strange the other day when I was shortening some of my rules by taking
advantage of the "mixed"-mode that you get if you don't specify any groupRelation for your rules.

I started out with several rules like this with explicit AND groupRelations:

    <ProcessCreate onmatch="include">  
        <Rule name="Technique_id=T1036.005,Sub_Technique_name=Match Legitimate Name or Location,Technique_name=Masquerading,Tactic=Defense Evasion" groupRelation="and">  
            <Image condition="image">csrss.exe</Image>  
            <ParentImage condition="is not">C:\Windows\System32\smss.exe</ParentImage>  
        </Rule>   
        <Rule name="Technique_id=T1036.005,Sub_Technique_name=Match Legitimate Name or Location,Technique_name=Masquerading,Tactic=Defense Evasion" groupRelation="and">  
            <Image condition="image">wininit.exe</Image>  
            <ParentImage condition="is not">C:\Windows\System32\smss.exe</ParentImage>  
        </Rule>   
        <Rule name="Technique_id=T1036.005,Sub_Technique_name=Match Legitimate Name or Location,Technique_name=Masquerading,Tactic=Defense Evasion" groupRelation="and">  
            <Image condition="image">winlogon.exe</Image>  
            <ParentImage condition="is not">C:\Windows\System32\smss.exe</ParentImage>  
        </Rule>   
    </ProcessCreate>  

These were then shortened to one rule by removing the groupRelation like this:

    <ProcessCreate onmatch="include">  
        <Rule name="Technique_id=T1036.005,Sub_Technique_name=Match Legitimate Name or Location,Technique_name=Masquerading,Tactic=Defense Evasion">  
            <ParentImage condition="is not">C:\Windows\System32\smss.exe</ParentImage>  
            <Image condition="image">csrss.exe</Image>             
            <Image condition="image">wininit.exe</Image>  
            <Image condition="image">winlogon.exe</Image>  
        </Rule>   
    </ProcessCreate>  

How ever, this causes logging of unrelated process creations like this one:

Process Create:
RuleName: Technique_id=T1036.005,Sub_Technique_name=Match Legitimate Name or Location,Technique_name=Masquerading,Tactic=Defense Evasion
UtcTime: 2021-07-03 09:57:23.325
ProcessGuid: {952ebdeb-3483-60e0-45ce-5c0000000000}
ProcessId: 1924
Image: C:\Program Files\VideoLAN\VLC\vlc.exe
FileVersion: 3.0.16
Description: VLC media player
Product: VLC media player
Company: VideoLAN
OriginalFileName: vlc.exe
CommandLine: "C:\Program Files\VideoLAN\VLC\vlc.exe"
CurrentDirectory: C:\Program Files\VideoLAN\VLC\
User: <<REDACTED>>
LogonGuid: {952ebdeb-246f-60e0-9e83-020000000000}
LogonId: 0x2839E
TerminalSessionId: 1
IntegrityLevel: Medium
Hashes: SHA256=31F5E43E9283CF2469D8B3E51E7C28C132C6ECB0DAB855DF52CBF21D5394AE0B
ParentProcessGuid: {952ebdeb-2473-60e0-b0a6-090000000000}
ParentProcessId: 6696
ParentImage: C:\Windows\explorer.exe
ParentCommandLine: C:\WINDOWS\Explorer.EXE

Note the unrelated bolded Image field.

First I thought Sysmon might interpret the entire rule as an implicit OR-groupRelation, but
changing the order of filter doesn't help. This rule gives the same strange result:

    <ProcessCreate onmatch="include">  
        <Rule name="Technique_id=T1036.005,Sub_Technique_name=Match Legitimate Name or Location,Technique_name=Masquerading,Tactic=Defense Evasion">  
            <Image condition="image">csrss.exe</Image>             
            <Image condition="image">wininit.exe</Image>  
            <Image condition="image">winlogon.exe</Image>  
            <ParentImage condition="is not">C:\Windows\System32\smss.exe</ParentImage>  
        </Rule>   
    </ProcessCreate>  

So, I either have missed/misunderstood something or I have found another bug...

Pinging the Sysinternal folks via @Alex Mihaiuc so they are aware and can investigate.

I'm attaching complete configuration files (one working and one not) for context.
111542-sysmon-parent-child-working.xml
111551-sysmon-parent-child-not-working.xml

Answer 1

Ugh, thought this was ironed out. Looking into it!

Answer 2

Hey Michael,

I've looked into this and it works as expected. The two config snippets you showcased are not equivalent. The first one says:

on ProcesCreate if all 3 (P1, P2, P3) of:
        image is csrss.exe                             (P1)
        and parent is not C:\Windows\System32\smss.exe

    and image is wininit.exe                           (P2)
        and parent is not C:\Windows\System32\smss.exe

    and image is winlogon.exe                          (P3)
        and parent is not C:\Windows\System32\smss.exe

then: log event

So if C:\Windows\explorer.exe launched csrss.exe then we would have

P1 is true
P2 is false (C:\Windows\explorer.exe indeed "is not" smss.exe, but also csrss.exe isn't wininit.exe)
P3 is false (C:\Windows\explorer.exe indeed "is not" smss.exe, but also csrss.exe isn't winlogon.exe)

P1 and P2 and P3 = false

and as a result no log entry is created.

On the other hand, if C:\Windows\explorer.exe launched notepad.exe then all 3 of P1, P2 and P3 would be false and their and-aggregation also false, also no log would be created.

For the second variant, the predicates inside Rule are aggregated with OR. You can check that by asking Sysmon what it thinks about its rules with sysmon64.exe -c.

on ProcessCreate if all (P4) of:
    any of the 4 (P5, P6, P7, P8 predicates)           (P4)

        parent is not C:\Windows\System32\smss.exe     (P5)
        or image is csrss.exe                          (P6)
        or image is wininit.exe                        (P7)
        or image is winlogon.exe                       (P8)

then log event

So a process such as vlc.exe created by C:\Windows\explorer.exe would have P5 as true (and it's enough, as OR aggregation short-circuits after the first success), P6, P7 and P8 also true. As a result, the OR aggregation between them, P4 will be true, which means that the event gets logged.

Answer 3

@Alex Mihaiuc
Hey Alex,
Thanks for researching this. It is quite possible I have missed/misunderstood something but I'm still a bit confused and
would like to add some clarifications and comments.

First, my first "case" have OR specified as the group relation (sorry for not making this explicit before). Like this:

    <RuleGroup name="ProcessCreate - Include" groupRelation="or">  
        <ProcessCreate onmatch="include">  
            <Rule name="Technique_id=T1036.005,Sub_Technique_name=Match Legitimate Name or Location,Technique_name=Masquerading,Tactic=Defense Evasion" groupRelation="and">  
                <Image condition="image">csrss.exe</Image>  
                <ParentImage condition="is not">C:\Windows\System32\smss.exe</ParentImage>  
            </Rule>   
            <Rule name="Technique_id=T1036.005,Sub_Technique_name=Match Legitimate Name or Location,Technique_name=Masquerading,Tactic=Defense Evasion" groupRelation="and">  
                <Image condition="image">wininit.exe</Image>  
                <ParentImage condition="is not">C:\Windows\System32\smss.exe</ParentImage>  
            </Rule>   
            <Rule name="Technique_id=T1036.005,Sub_Technique_name=Match Legitimate Name or Location,Technique_name=Masquerading,Tactic=Defense Evasion" groupRelation="and">  
                <Image condition="image">winlogon.exe</Image>  
                <ParentImage condition="is not">C:\Windows\System32\smss.exe</ParentImage>  
            </Rule>   
        </ProcessCreate>  
    </RuleGroup>  

So, with your P-syntax the first case should be: P1 OR P2 OR P3.

Output of Sysmon64.exe -c:

 - ProcessCreate                      onmatch: include   combine rules using 'Or'  
        Compound Rule Technique_id=T1036.005,Sub_Techn   combine using And  
            Image                          filter: image        value: 'csrss.exe'  
            ParentImage                    filter: is not       value: 'C:\Windows\System32\smss.exe'  
        Compound Rule Technique_id=T1036.005,Sub_Techn   combine using And  
            Image                          filter: image        value: 'wininit.exe'  
            ParentImage                    filter: is not       value: 'C:\Windows\System32\smss.exe'  
        Compound Rule Technique_id=T1036.005,Sub_Techn   combine using And  
            Image                          filter: image        value: 'winlogon.exe'  
            ParentImage                    filter: is not       value: 'C:\Windows\System32\smss.exe'  

Second, I was under the impression that different filters in the same rule had an implicit AND between them
(if you don't specify any explicit rule relation).

At least that is how I read this excerpt from the Sysmon Info page under the heading Event filtering entries:

Each filter can include zero or more rules. Each tag under the filter tag is a field name from the event.
Rules that specify a condition for the same field name behave as OR conditions, and ones that specify
different field name behave as AND conditions. Field rules can also use conditions to match a value.

So again with your P-syntax, I thought (or at least was aiming for) a second case of: P5 AND (P6 OR P7 OR P8).
This was also previously discussed (indirectly) on this forum on this question (expand to see all comments).

I'm also quite sure I have used this "feature" in other rules that are working like that. I will try to find some specific
cases for you. Have this changed (recently)?

However, you are correct that Sysmon reports it is using Or. Output from Sysmon64.exe -c:

Rule configuration (version 4.50):  
 - ProcessCreate                      onmatch: include   combine rules using 'Or'  
        Compound Rule Technique_id=T1036.005,Sub_Techn   combine using Or  
            ParentImage                    filter: is not       value: 'C:\Windows\System32\smss.exe'  
            Image                          filter: image        value: 'csrss.exe'  
            Image                          filter: image        value: 'wininit.exe'  
            Image                          filter: image        value: 'winlogon.exe'  

Answer 4

Hi Michael,

This OR treatment within Rule elements didn't change in the past year. Inside various ...Event elements the default aggregation remains AND as previously explained by Mark - https://techcommunity.microsoft.com/t5/sysinternals-blog/sysmon-the-rules-about-rules/ba-p/733649