Definition of "logsource" values like product or category.

[Maspital]

Hey,

I am currently using chainsaw + SIGMA to evaluate log datasets and stumbled upon the following issue: Certain SIGMA rules produce an abnormally high number of false positives, to the point where I suspect that it just triggers on most events. The rule in question is

title: Sysmon Blocked Executable
id: 23b71bc5-953e-4971-be4c-c896cda73fc2
description: Triggers on any Sysmon file block executable event. Which should indicates a violation of the block policy set
status: experimental
author: Nasreddine Bencherchali
date: 2022/08/16
references:
    - https://medium.com/@olafhartong/sysmon-14-0-fileblockexecutable-13d7ba3dff3e
tags:
    - attack.defense_evasion
logsource:
    product: windows
    category: file_block
detection:
    selection:
        Image: '*'
    condition: selection
falsepositives:
    - Unlikely
level: high

I think the problem is that the category in question (file_block) is not mapped to anything - where and how can I define this? In this example, the category should be file_block iff "provider_name": "Microsoft-Windows-Sysmon" and event_id: 27, which would clearly identify the category.

I have a similar problem for several other rules. Am I perhaps misunderstanding how certain things work?

Any help on this would be much appreciated :)

[FranticTyping]

Hey @Maspital

I'm guessing you're running chainsaw with the sigma-event-logs-all.yml mapping file. This mapping file does not filter based on provider name or category which means that some Sigma rules (like the file block one you mentioned above) cause a huge number of false positives.

You could either extend the sigma rule to also require a specific event ID (which should cut down the number of FPs), or you could use the sigma-event-logs-legacy.yml mapping file instead which supports "Provider" mappings.

I don't think either of these two options will completely solve your issue, but it should reduce the number of FPs that you face.

[alexkornitzer]

There is also potential to add category support to the mapping to apply 'x' filter when category 'y' is set. But this would require code enhancements.

[Maspital]

Yes, I'm using a modified version of sigma_event_logs.all (because winlogbeat likes to name stuff differently). Changing SIGMA rules themselves even slightly is something I would like to avoid because I want to be able to say "this dataset was created with SIGMA vXX" so it can be reproduced easily (though this is probably the easiest solution). In this case the change would be simple, but I wouldn't say I'm competent enough to confidently say that whatever change I intend to do does not change the intended result/logic of a given SIGMA rule :D

Using the legacy mapping file seems like it both has a lot of duplicate entries and prevents any novel alerts from being shown because they are blocked by the manually set filters(?).

Having category support like you mentioned @alexkornitzer would be a really nice and useful feature imo, but I dont know how much effort this would require on your part.

[alexkornitzer]

So adding this code wise is pretty easy the challenge comes from how to extend the mapping schema in a clear way, my current thinking is something like this:

---
name: Chainsaw's groupless Sigma mappings for Event Logs
kind: evtx
rules: sigma
...

extensions:
  preconditions:
    - for:
        category: file_block
      filter:
        int(EventID): 27
        Provider: Microsoft-Windows-Sysmon
...
groups:
...

Where the for block can consist of different identifiable fields of a Sigma rule.

[Maspital]

That looks great! Assuming knowledge of Sigma rules in general, this is nice and understandable in my opinion.

So this would work for whatever field may be defined within the logsource of a rule?

[alexkornitzer]

Ah good spot nah I would wanna support things like name too, so it should be this:

---
name: Chainsaw's groupless Sigma mappings for Event Logs
kind: evtx
rules: sigma
...

extensions:
  preconditions:
    - for:
        logsource.category: file_block
      filter:
        int(EventID): 27
        Provider: Microsoft-Windows-Sysmon
...
groups:
...

But awesome, okay i'll see if I can do this when I get time otherwise i'll lob it at someone else :)

[Maspital]

Any news regarding this? :) @alexkornitzer

[alexkornitzer]

@Maspital can you give the feature/extensions branch a try?

[Maspital]

Seems to work nicely, at least for the things I tested :+1: I will try it out in more detail tomorrow

[alexkornitzer]

Awesome. If it all seems fine tomorrow i'll get that merged in and released.

[Maspital]

I'm sure I didn't test for everything, but so far everything did what it was supposed to do. Two more things:

• can the filter handle negated input? Might be useful for certain cases, it's not really important right now. Something like

  extensions:
  preconditions:
  - for:
      logsource.category: some_category
    filter:
      int(EventID): NOT 1337
  

  though there probably exists better/clearer syntax than that

• One would probably only ever write these filters with one or a few specific rule in mind. Sadly, keywords like "file_block" are basically free text with no hard meaning attached to them - though this is more a flaw of Sigma in general imo. This means there could be other rules using the same keyword that now unintentionally get blocked by this filter

  To help with this, would it be possible to additionally declare a set of rules ["Some rule name", "Another rule name"] a filter should be assigned to? Or something similar.

Both of these things are just afterthoughts, I think the new feature perfectly solves the original issue. Thank you so much for implementing it so quickly!

[alexkornitzer]

Thanks for checking that all out. Right so the first one is probably not doable because I don't think I have put support in to handle nested syntax for a filter so this not(int(EventID)) probably won't work. We would need to upgrade the filter to be a full Tau block with condition support, so maybe that can come in later as its not too difficult to add. I should add array support into the for block as well but that can for now just be handled with copy paste, at the cost of duplication.

I don't have a ton of time at the moment so I will merge the current work, and then your two above improvements can be added at a later date. For now I will keep this issue open as a reminder.