Skip to main content

Retrohunt - PSA on Case creation

  • March 11, 2026
  • 2 replies
  • 24 views

EP0
Forum|alt.badge.img+3

This is more of an awareness post from a lesson learned and a request to probably update the documentation for Retrohunt and a feature request on the SecOps UI.

Context:

We have a noisy Alerting rule that looks at allowed network traffic from one source IP towards x number of distinct destination IPs within a minute. Today, I made several changes to more appropriately reflect the intent of the said rule. 

As best practice, I always test rules via “Test Rule” in Rules Editor. So far so good, no results in the last ~2 weeks. And for good measure (or so I thought), I ran a Retrohunt for the rule from a start date of Sept 01, 2025 until today. Result shows 400+ detections, with last detection on Feb 24, 2026. 

I have ran several Retrohunts before, but in retrospect, this was the first time I ran it on a rule that was already set to Alerting. Lo and behold, we got flooded with 60+ cases from that single rule, including Overflow cases. 

My own investigation pointed showed events from weeks and months ago. This is how I connected the dots that might have something to do with the Retrohunt. It led me to this post Spammed by 'Overflow Case' | Community and after checking the documentation Run a rule against historical data  |  Google Security Operations  |  Google Cloud Documentation , it mentions “When you create detections using retrohunt on a rule with alerting status disabled, alerting on these detections is disabled as well. To enable alerting, create a new version of the rule with alerting status enabled and re-run the retrohunt.”

I hindsight I should have known better. I did not realize the implication of running a Retrohunt with Alerting enabled on a rule.

Request: 

The documentation addresses the alerting-disabled case but doesn't explicitly state or clear what happens when alerting is enabled. In my opinion it would be better to explicitly state what happens when retrohunt is ran on alerting-enabled rules. In addition, perhaps a warning or something in the SecOps UI itself to notify users (can be in the pop up window when starting the hunt) on the implication of running a Retrohunt with Alerting enabled on a rule would probably be beneficial and potentially save against unwanted flooding of cases. 

2 replies

cmorris
Staff
Forum|alt.badge.img+11
  • Staff
  • March 11, 2026

​I can file a doc request, but also wanted to call one thing out.


When this takes place, a dynamic list can be set on the connector to block case creation for these alerts based on rule ID. To do this, go to your connector settings and you’ll see an external dynamic list as an option, from there enter this, replacing the rule ID with the rules you want to filter alerts from: “Rule.ruleID != ru_f294c036-481e-4b6a-b7a6-b3c8bb613f96”.

 

However, the filter runs after alert ingestion - so this will stop case creation, but the system will not create cases for other relevant alerts (until caught up) as it will still ingest the “max alerts to fetch” config on the “run every” basis. With this in mind, I recommend boosting the alerts pulled at a time along with decreasing the run every config, if doable. Once the issue is resolved, remember to remove the filter.


cmorris
Staff
Forum|alt.badge.img+11
  • Staff
  • March 12, 2026

Example: