Tuning detections issue while using wildcards - Sigma rules

[fr0stysh4ke]

Version

2.4.100

Installation Method

Security Onion ISO image

Description

configuration

Installation Type

Standalone

Location

on-prem with Internet access

Hardware Specs

Meets minimum requirements

CPU

4

RAM

16

Storage for /

98

Storage for /nsm

192

Network Traffic Collection

tap

Network Traffic Speeds

Less than 1Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

No, there are no additional clues

Detail

Hello,

I Found a bug (might be a bug) within the tuning section of the detection section of 2.4.100. I haven't tested this with all detections. As of currently, the only issue that I have right at the moment is the tuning part of a sigma rule. the sigma rule is called "Renamed ZOHO Dctask64 Execution". I am currently attempting to white list a specific file path. I tempted to use wild cards in place of a file path extensions because i have other users that use the same browser on their and preventing tuning fatigue. I tried using C:\Users*\AppData\Local\Mozilla\Firefox\Profiles* which resulted in a failure of 400 while importing this method, Which indicates that a specific file path did not exist because of the wildcard in place of the user name. I switched back to C:\Users\some_user\AppData\Local\Mozilla\Firefox\Profiles* which works perfectly. no errors. However the rule is still currently firing even that it has been excluded according to the tuning rules that was provided under the detection source > convert > test in Kibana.

In this screenshot you are missing a slash next to the wildcard which results in an variable error described in kibana output with 400 (bad request)

Now if I add additional slash to the output it works perfectly as shown below:

When clicking on convert within the detection it shows this:

I have attempted to add addition slashes to the output to the rule while tuning the path out and when I attempt to save it fails with error 400 bad request.

This might be a bug with the security onion conversion, or something that was overlooked or it could be something that was intended, but i did check your channels and I couldn't find a video to where I can use wildcards appropriately.

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[fr0stysh4ke]

C:\\ProgramData\\Microsoft\\Windows Defender\\Platform\*\\MsMpEng.exe, was just added to a rule to be excluded. Other artifacts did include addition slashes while the file path was added manually was still missing when testing in kibana even though the tune detections has confirmed that it exists with no errors and saves the file path.

[reyesj2]

Does this work for you?

In detections tuning I added

sofilter:
  event_data.file.path|contains: 
    - AppData\Local\Mozilla\Firefox\Profiles

which converts into

any where (not process.executable:"*\\dctask64.exe") and (not event_data.file.path:"*AppData\\Local\\Mozilla\\Firefox\\Profiles*")

I think you might just be missing the keyword modifiers like |contains or |endswith contains would get you the string wrapped in *<string>* endswith would you get you *<string>

https://sigmahq.io/docs/basics/modifiers.html

[fr0stysh4ke]

I attempted to use |endswith or |startswith variables but didn't work as expected. I was just missing |contains variable which will wrap the string as you have shown. Thank you for your help!

[fr0stysh4ke]

I added contains to the rule but still breaks. It took a minute to have the rule updated.


The rule that was implemented was excepted. no error. SOC Interface said that the rule was saved. We have to modify it this way so we don't accidently white list something and it becomes malicious/suspicious.

[reyesj2]

It looks like contains is not working there because you have a * in the string.

You should use |contains to specify a value that is common for all your hits. So maybe you can do

so-filter:
  event_data.file.path|contains: "\AppData\Local\Mozila\Firefox\Profiles\"
  event_data.file.path|startswith: "C:\Users\"

This way you get hits for any file.path that contains the value *\AppData\Local\Mozila\Firefox\Profiles* AND starts with the value C:\Users*

[fr0stysh4ke]

Sorry for the late reply.

I haven't tried it that way, which I will try it with your method, i did try it with |contains|all I will try it with your method. However still not being excluded. Its really puzzling. We thought it might be a syncing issue.. We did enable quite a few rules learn the new implementation that SO has to offer before we started to import and creating our own. Even rules that are correct and single lined are not being excluded even tho soc manager states it saved and convert it to Kibana works perfectly does not show it at all. Tonight we tried to exclude one but it returned as 400 Bad Request which states that the line does not exist. Not a 100% sure on the SOC manager what exactly 400 error is I assume it is: "The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, size too large, invalid request message framing, or deceptive request routing)." https://en.wikipedia.org/wiki/List_of_HTTP_status_codes.

We are currently thinking this could be part of the suricata 401 error while modifying the rules. #13668.

This has been a head scratcher for us

[reyesj2]

Ensure you check the spacing it should be formatted as yaml which is 2 spaces as indent.

sofilter:
  event_data.process.command_line|contains:
    - C:\Program Files\Intel\SUR\QUEENCREEK\x64\task.vbs

Also after adding tuning to one or more rules you should run a detections sync for sigma, that will make the changes take affect

[fr0stysh4ke]

I swore in the documentation it showed so-filter but that was corrected. I have copied and pasted your line that you have provided and made sure it was formatted correctly. Right now, just waiting on the full sync to occur we received sync failed error, and hopefully this works. Again i do appreciate ya

[fr0stysh4ke]

The issue with the 400 error code, we were unable to track down what caused this error. However we did reimage Security Onion instance and the errors went away and should only receive error code 400 is when the artifacts was not found. While doing the suggestions that you have provided and we really appreciate it and does work after reimaging. Now when we force sync to make the changes to the tuning for the rules will fail due to rule mismatch error on elastalert side. We noticed that elastalert will still be sitting with rules mismatch for a couple days then go to OK status and then repeat itself. To remove the rules mismatch is to reboot Security Onion and then the detections will sync and once finished then elastalert returns with OK status. This discussion has been resolved.