Description
What is the bug?
Null filters in Sigma rules are not translated properly to queries leading to False Positives and broken detections.
Example:
Pre-packaged rule Wmiprvse Spawning Process contains a null filter
By sigma syntax this should only hit on documents where the LogonId field exists (As in NOT null)
The query is translated to this by OpenSearch:
((winlog.event_data.ParentImage: *\\WmiPrvSe.exe) AND ((NOT (((winlog.event_data.LogonId: "0x3e7") OR (winlog.event_data.LogonId: "null")) OR ((winlog.user.name: *AUTHORI*) OR (winlog.user.name: *AUTORI*)) OR ((winlog.event_data.Image: *\\WmiPrvSE.exe) OR (winlog.event_data.Image: *\\WerFault.exe)))))) AND ((NOT winlog.event_data.LogonId: null))
This is not working as intended. The NOT winlog.event_data.LogonId: null
section is actually looking for null as a string. This query will return all documents that dont have winlog.event_data.LogonId equal to the string "null"
How can one reproduce the bug?
Steps to reproduce the behavior:
- Create any Sigma rule that uses a null filter (or use the prepackaged rule noted above)
- View its query and note the null filter is translated to NOT : null
- Go to discover
- Query for
NOT <field>:null
or simply:NOT winlog.event_data.LogonId:null
- All documents where the specified field is not the string "null" are returned (Nearly all data)
What is the expected behavior?
The sigma to be properly translated to something along the lines of:
winlog.event_data.LogonId:*
where this returns results where the field being queried exists in the data
What is your host/environment?
- OS: 2.11 fresh install
Thanks,
Jay