Spammed by 'Overflow Case'

[wonjulee]

Hi all,

New to SecOps, so forgive me if this is already a known issue.

I was fixing up a rule that was bugged, and tested it by running a YARA-L retrohunt using my new rule. It worked - it found something like 9000 cases over a month, but since then, I have been getting spammed by 'Overflow Cases', with empty events that are named after my rule. There are no timestamps on these or any event or log info. I do know that for the first 2-3 mins after I finished the retrohunt one of my playbooks went crazy and started spamming too, but that stopped quickly and now I only get these 'ghost' cases that are generated from empty alerts. I was wondering if there is a way to reset the queue of alerts that are waiting to be pooled into cases.

From what I've seen, retrohunts should not generate alerts, so I'm not even sure if the retrohunt is the cause, but it was fine before I ran it. I know that the rule itself is not the problem, because it still finds (correct) matches as shown in the Alerts and IOC matches section.

Any advice would be greatly appreciated. Thanks!

[ajohnson · Accepted solution]

If you execute a retro hunt with live and alerting enabled for the rule it will send to SOAR. Best practice is to use the "test rule" in the bottom right of the rules editor to do a 2 week test on the rule, or disabled alerting and run the retro hunt first. 

the overflow cases will not contain much information as it is built to protect you from a flood: 

https://cloud.google.com/chronicle/docs/soar/investigate/working-with-alerts/define-alert-overflow-a...

I would assume at this point the SIEM detections are no longer going to make new SOAR cases. So i would recommend tuning your rule, testing a retro hunt with alerting off, then running with it on if you would like to generate SOAR cases (if the detections are at a manageable level).