I think this is because it's only hitting on the Event ID and not considering anything else. Ideally, the Event ID and Provider would be considered when applying Sigma logic. I can't tell you how many Event ID 1's there are outside of Sysmon:1, but there are a lot. Many Providers log to Event ID 1, 2, 3, 100, etc. Without factoring in the Provider, the rules get applied to the wrong events.

from chainsaw.

I am finding this to be the case for other detections like sysmon and applocker.

from chainsaw.

Also, I say Provider and not Channel because that logic will work in most event logs except events logged in Application.evtx, which is effectively a dumping ground for third-party event log Providers. There are lots of event ID collisions in the Application event log, especially on a system with multiple third-party/extracurricular applications beyond what comes with a clean Windows install.

from chainsaw.

I use Chainsaw to write a CSV and then I post process that, so some simple sanity checks got rid of a lot of erroneous detections in my post processing. It's not an optimal solution, and would be better addressed in the code on a more comprehensive basis. But here is some simple example python code:

Sigma Rules - Sanity check detection start

if "defender" in csvrow[1].lower() and "defender" not in csvrow[3].lower():
continue

if "sysmon" in csvrow[1].lower() and "sysmon" not in csvrow[3].lower():
continue

if "file was not allowed to run" in csvrow[1].lower() and "applocker" not in csvrow[3].lower():
continue

Sigma Rules - Sanity check detection end

from chainsaw.

Hi @OMENScan,

So by design the sigma-event-logs-all.yml offloads all filtering and detection to the sigma rules. This is where the problem stems, unfortunately in my opinion Sigma rules are not very well written. Lets take the Windows Defender Threat Detected for example:

...

logsource:
    product: windows
    service: windefend
detection:
    selection:
        EventID:
            - 1006
            - 1116
            - 1015
            - 1117
    condition: selection

...

If we look at the detection here we can see that this is going to cause a huge number of false positives because the Provider is missing from the detection. Some may argue that this is provided by the service but this is not part of the detection block, nor does it map to the actual provider, so additional logic would be required here (current work around is mapping filters).

The best way to solve these problems is to fix the rules upstream but I am not opposed to adding further hacks in but then someone would need to collate all possible values of service so that they could be auto-mapped to provider.

Does that make sense? I am open to other suggestions, but there is only so much that can be done without having to write very detailed mapping files which I do not have the expertise to do.

from chainsaw.