Erroneous Sigma Results using Hunt option

[OMENScan]

When using the hunt option for Chainsaw I get erroneous results indicating "Windows Defender Threat Detected" in Microsoft-Windows-Wcmsvc and Microsoft-Windows-AppReadiness - and "Win Defender Restored Quarantine File" in Microsoft-Windows-Wcmsvc.

The rules appear to be searching in more than the Defender logs causing the results.

[OMENScan]

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

[AndrewRathbun]

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.

[AndrewRathbun]

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.

[OMENScan]

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

[alexkornitzer]

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.

[reece394]

It might be good to modify the default sigma-event-logs-all.yml file with sane filters for common false positives like the Windows Defender Threat Detected rule similar to sigma-event-logs-legacy.yml. Dug into the rules a bit and it seems like anything tagged with service windefend uses just the Microsoft-Windows-Windows Defender/Operational log file.

Using issue #107 and commit ccdc354 as reference I added the following to the top of it and it seemed to get rid of all the false positives for Windows Defender.

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

exclusions:
......
 extensions:

  preconditions:
    - for:
        logsource.service: windefend
      filter:
        Provider: Microsoft-Windows-Windows Defender

[alexkornitzer]

I am going to close this as I think @reece394's work that merged a while back is sufficient for this for now. Please feel free to reopen if this is not the case though.