Add Timebox to Windows.Hayabusa.Rules and Windows.Registry.Hunter

[mtreanor-r7]

As discussed internally, it would be great to add a Timebox to Windows.Hayabusa.Rules and Windows.Registry.Hunter to pre cut out noisy output when running all rule level/status across in scope compromised assets.

Understand WHERE Timestamp>'2024-09-20' could be applied to the notebook after the fact by focusing only on in scope cells but by doing it during the hunt parameters would reduce the noise when building timelines in Velociraptor.

Normally during an IR, we have pre indicators and a known date/time of bad compromise and using the above hunts to triage would lift our pivot points.

Thanks,

[scudette]

I added timeboxing to the Hayabusa Rules one now. It does help a lot but there are some rules which are extremely noisy.

Since I did the sync to the latest rules we have this https://github.com/Yamato-Security/hayabusa-rules/blob/main/hayabusa/sysmon/Sysmon_1_Info_ProcExec.yml

That rule essentially fires on every process execution message - so it basically duplicates the sysmon eid 1 log. This is a new rule that was not present previosuly and in my testing it doubles the number of hits to about 50k hits on a pretty boring test machine - it will be extremely noisy in real machines.

The rules is marked "informational" so it will only fire when we select All rules. I am not sure of the value of the rule but it seems not very useful. We have a couple of options:

1. Remove the rule from the artifact. Maybe implement a set of blacklisted rules we automatically exclude.
2. As a user do not use informational level rules by default - the procedure now is to use All in the rule level choice for triage. Maybe we need a lower default but not informational. Or maybe we need to specifically remove these rules

What do we think about managing extremely noisy rules? Are all information level rules this useless?

[scudette]

This is another example of a rule that is potentially very noisy https://github.com/Yamato-Security/hayabusa-rules/blob/main/hayabusa/sysmon/Sysmon_11_Med_FileCreated_RuleAlert.yml

The rule is marked medium, and in the default sysmon config we only record executable file creation. Depending on sysmon config this rule can explode if all file creations are recorded by sysmon.

Maybe we need to override some of the rule levels they have.

[mgreen27]

I would lean towards having multiple filter options. So we can have a blacklist of artifacts, and allow folks to add their own to the blacklist on collection. But also have the error level filter.

The idea is different levels of collection may be useful at different times and allowing options helps for less post collection processing.

[scudette]

I am just worried this makes it hard to use because it is not clear to the user what is the best course of action - should they always enable everything? (This sounds very appealing for a DFIR investigator where more data is always wanted).

To some extents this is the approach taken by defaults - most of the time this is what the user wants. But I can also see people turning all the knobs to 11 .

[mtreanor-r7]

Leaning towards @mgreen27 's suggestions, right now it's the following:

• Critical
• Critical and High
• All

if we could have low, med, high, critical as one option (or tick box)to avoid some of the info alert noise that could also be a solution too.

Think a blacklist option would be beneficial, every environment is going to be different, one rule might by noisy one day, the other it won't be, if an analysts runs the hunt, notices something, they can stop it, re-run with exclusions/blacklist to cut down noise for timeline purposes.

[mtreanor-r7]

Upon further testing, it would be helpful if the rules are set with the option to the following, we can modify it after the fact but when running this hunt in a compromise assessment, depending on the data coming back upstream, it would be ideal to split out the Critical and Highs as two different hunts for the sake of tasking out analysis.

• "Critical"
• "High"
• "Medium"
• "Critical and High"
• "Critical, High, and Medium"
• "All"

[scudette]

What if we just did a multi selector box which had all three ?

[mtreanor-r7]

that would work also, thank you!

We mistakenly ran a hunt for critical, high and medium and returned too much data (understandable), realise that this type of hunt isn't designed for an enterprise org wide compromise assessment but just figured I'd put forward the idea to split out the rule levels.

[scudette]

Im not sure there is much thought given to the rule levels in the upstream repository so I wouldnt rely on it too much. Maybe we need a way to design a working set of rules for different scenarios and encode that into the artifact - kind of like the blacklist but in reverse.

I found the rule level to be very inconsistent in practice