Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Definition of "logsource" values like product or category. #107

Open
Maspital opened this issue Oct 12, 2022 · 12 comments
Open

Definition of "logsource" values like product or category. #107

Maspital opened this issue Oct 12, 2022 · 12 comments
Labels
enhancement New feature or request

Comments

@Maspital
Copy link

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 FranticTyping self-assigned this Oct 12, 2022
@FranticTyping FranticTyping added the question Further information is requested label Oct 12, 2022
@FranticTyping
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Author

Maspital commented Oct 13, 2022

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 alexkornitzer added enhancement New feature or request and removed question Further information is requested labels Oct 13, 2022
@alexkornitzer
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

alexkornitzer commented Oct 13, 2022

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
Copy link
Author

Any news regarding this? :) @alexkornitzer

alexkornitzer added a commit that referenced this issue Oct 19, 2022
This allows for overriding of poor rules as discussed in #107.
@alexkornitzer
Copy link
Collaborator

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

alexkornitzer added a commit that referenced this issue Oct 19, 2022
This allows for overriding of poor rules as discussed in #107.
@Maspital
Copy link
Author

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

@alexkornitzer
Copy link
Collaborator

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

@Maspital
Copy link
Author

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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants