Seperate Folder For "Hunting Rules"

[nasbench]

In sigma, we tend to write rules while avoiding the maximum amount of FP rate but unfortunately sometimes this can be very hard if you don't have enough information about the environment in which this rule would be executed. So an amount of tuning and work needs to be done by the rule used for it to be prod read.

Before this, some of these rules can be classified as hunting rules.

What I'm suggesting is to transfer some of the rules we already have that are more suited for hunting and write more rules like these but in a separate folder called "hunting_rules" or add a new tag that indicates that some rules are more for hunting than direct detection.

People can use/leverage this folder/tag during conversion of the rule and have adapted expectations and start hunting for malicious stuff with an acceptable rate of FP

I know the "status" field aims to achieve a similar effect to separate between prod-ready rules and testing ones. But some rules will always be best for hunting rather than a generic flag/alert approach in a detection pipeline.

[frack113]

Hi,
for me [informational and low level] (https://github.com/SigmaHQ/sigma/wiki/Specification#level) rules are for hunting or forensic .

• As many take the full repo without verification, putting them in a hunting directory makes sense.
• I don't think that a new tag is necessary, with the status and the level we already make a good sorting
• Low rule can have some generic tuning . Informatinal don't need

[nasbench]

@Neo23x0 any thoughts?

[Neo23x0]

Can we get a better understanding of what a "hunting rule" would look like. My understanding is, that hunting is the opposite of a rule (a plan to find malicious events).

For me, "hunting" means that an analyst browses or looks through lists of data and tries to find malicious activity based on his knowledge and sense of legitimate activity. He does NOT know what to look for when he starts hunting.

If you can define a hunt in a rule and you know that some false positives may appear in the result set, then it's a medium level rule.
If you can define a hunt in a rule and you know that many false positives may appear in the result set, then it's a low level rule.

The informational level is not a level for hunting. Matches with such a rule or a set of rules can be used in correlations that lead to a match of a higher level. (used in Sigma correlation rules or in SIEM specific correlation rules)

So, if there is a type of rule that doesn't match the character of the rules mentioned above, I'd like to look at it and reconsider.

[nasbench]

It's more of a grouping than anything else to facilitate the usage of rules. For example, 90% of people who use SIGMA will not modify any of the rules because they take them as IS and will remove or slightly modify a rule if a ton of FPs are found.

Let's take this rule for example

title: Service Execution
id: 2a072a96-a086-49fa-bcb5-15cc5a619093
status: test
description: Detects manual service execution (start) via system utilities.
author: Timur Zinniatullin, Daniil Yugoslavskiy, oscd.community
references:
    - https://github.com/redcanaryco/atomic-red-team/blob/f339e7da7d05f6057fdfcdd3742bfcf365fee2a9/atomics/T1569.002/T1569.002.md
date: 2019/10/21
modified: 2021/11/27
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith:
            - '\net.exe'
            - '\net1.exe'
        CommandLine|contains: ' start '     # space character after the 'start' keyword indicates that a service name follows, in contrast to `net start` discovery expression
    condition: selection
falsepositives:
    - Legitimate administrator or user executes a service for legitimate reasons.
level: low
tags:
    - attack.execution
    - attack.t1569.002

It looks for starting services with "net.exe". Technically you can't increase the leve of this rule more than low because there are lot of legitimate software that do this. But on the other hand it's good for threat hunters to use these kind of queries to look for what services are being started and perhaps find something malicious.

Of course, you could argue that doing this is part of tuning the rule and making it robust for an environment and that's how the process should be. And you would be correct.

But we know that people won't do that and having such a rule will make people say that sigma has a lot of FP.

By putting these kind of rules in a specific folder we can increase the likelihood that people will use SIGMA with confidence and people who would like to do more hunting and tuning will use the "hunting" folder

[qasimqlf]

Hi,

I think, level attribute is doing enough for rule's intensity as @Neo23x0 and @frack113 said.
But still if we want separate folder for "hunting rules" than we may have duplicates in "rules" and "hunting rules" folders as rules can be part of both folders in many cases.

So best thing will be:

• either have another attribute of hunting like level > for example: hunting: yes or hunting: no

• or add new value in level attribute > for example: level: low, hunt or level: medium, hunt or something like that.

[tsale]

I had a similar idea and want to add my two cents on this topic.

Sigma is very flexible and can be used for threat hunting. Although, creating a threat hunting rule will necessitate a different approach. In many cases, the query generated by the rule will serve as the beginning of a threat hunting scenario. The main purpose will be to collect data that is suspicious in nature without having additional context. Populating a threat hunting rule should also have different criteria. Some of these criteria could be:

Hypothesis: The rule should have a hypothesis that acts as the starting point and also indicates the purpose of the hunt.
Description: The query should be explained in detail in the description, along with some examples of different ways the attack can manifest. The main focus of the query should be to look at the bigger picture. This will inevitably result in some false positives, but this is acceptable for a threat hunting query.

I don't believe that low or informational-level detection rules could be classified as threat hunting. This, of course, varies for each rule. Some rules could be good candidates for threat hunting. However, as I explained above, these rules might need more information to include the purpose and explain the expected results based on what we are looking to find.

I have created a threat hunting rule that depicts how I envision these rules. The main focus was to make it easy to understand despite the somewhat complex nature of the query. Please take a look at this query and let me know what you think. The results that could come out of this will be suspicious enough to start an investigation but too noisy to create a detection rule.

title: Manual execution of scripts that exist inside a compressed file
hypothesis: User double-clicks on a malicious script inside a zip/rar file.
description: "This is a threat-hunting query to collect information related to the interactive execution of a script 
from inside a compressed file(zip/rar). Windows will automatically run the script using scripting interpreters such
as wscript and cscript binaries.

From the query below, the child process is the script interpreter that will execute the script. The script extension 
is also a set of standard extensions that Windows OS recognizes. Selections 1-3 contain three different 
execution scenarios. 
  1. Compressed file opened using 7zip.
  2. Compressed file opened using WinRar.
  3. Compressed file opened using native windows File Explorer capabilities. 

When the malicious script is double-clicked, it will be extracted to the respected directories as signified by the CommandLine
on each of the three Selections. It will then be executed using the relevant script interpreter."
status: experimental
date: 2023/02/15
author: '@kostastsale'
references:
  - https://app.any.run/tasks/25970bb5-f864-4e9e-9e1b-cc8ff9e6386a (Winrar > Wscript executing .wsf)
  - https://app.any.run/tasks/fa99cedc-9d2f-4115-a08e-291429ce3692 (Winrar > Wscript executing .wsf)
logsource:
    category: process_creation
    product: windows
detection:
    ChildProcess:
      Image|endswith:
        - '\wscript.exe'
        - '\mshta.exe'
        - '\cscript.exe'
        - '\powershell.exe'
    ScriptExtention:
      CommandLine|endswith:
        - '.wsf'
        - '.hta'
        - '.vbs'
        - '.js'
        - '.jse'
        - '.wsh'
        - '.vbscript'
        - '.ps1'
    Selection1:
      ParentImage:
        - '*\7z*.exe'
      CommandLine:
      - '*\appdata\local\temp\7z*\*'
    Selection2:
      ParentImage|endswith:
        - '\winrar.exe'
      CommandLine:
      - '*\appdata\local\temp\rar*\*'
    Selection3:
      ParentImage|endswith:
        - '\explorer.exe'
      CommandLine:
        - '*\appdata\local\temp\*.rar\*'
        - '*\appdata\local\temp\*.zip\*'
    condition: ChildProcess and ScriptExtention and (Selection1 OR Selection2 OR Selection3)
falsepositives:
    - "During my testing, batch files produced a lot of noise, as many applications appear to bundle them as part of their installation
process. You should baseline your environment and generate a new query excluding the noisy and expected activity. Some false positives may come up depending on your environment. All results should be investigated thoroughly before
    filtering out results."
level: medium
tags:
    - attack.execution
    - attack.T1059
    ```