Tuesday's Tip of the Week - Retrohunt: Test Your Rules Against the Past

October 27, 2026

Audience: SOC managers, detection engineers, incident responders

Summary: Retrohunt runs a YARA-L rule against UDM data you’ve already ingested. Instead of waiting weeks for live detections, you can see how a new rule behaves, sweep for new indicators, or scope an incident in a single run. This briefing covers:

• how retrohunt works and its limits
• the settings that keep it from causing problems
• four use cases with example rules
• dashboard queries for reviewing results
• criteria for promoting a rule to live

1. Retrohunt compared with the other ways to test a rule

Google notes that Run test results can differ from retrohunt and live results, because the evaluation windows may be aligned differently. Use Run test while you’re writing a rule. Use retrohunt when you need saved detections and real volume numbers to decide whether a rule is ready for production.

2. Before you run: checklist

3. How to run a retrohunt

In the console:

1. Open the Rules Dashboard, click the rule’s options icon, and select Yara-L Retrohunt.
2. Choose the start and end times. The default range is one week.
3. Click RUN. Progress shows in the rule’s detections view. If you cancel a run partway through, you keep the detections it already found.
4. To see earlier runs, click the date range link in the rule’s detections view. Each run’s results appear in the Timeline and Detections graph.

Through the API (for automation and detection-as-code):

The caller needs the chronicle.retrohunts.create IAM permission.

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "https://REGION-chronicle.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/instances/INSTANCE_ID/rules/RULE_ID/retrohunts" \
  -d '{"processInterval": {"startTime": "2026-09-27T00:00:00Z", "endTime": "2026-10-27T00:00:00Z"}}'

4. Use cases

Use case 1: Validate and tune a new rule

Scenario: You want to detect lateral movement where one source opens RDP connections to many hosts.

Version 1:

rule rdp_fan_out {
  meta:
    author = "Detection Engineering"
    description = "One source connects to 5 or more distinct hosts over RDP within 1 hour"
    severity = "Medium"

  events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    $e.target.port = 3389
    $e.principal.ip = $src
    $e.target.ip = $dst

  match:
    $src over 1h

  outcome:
    $distinct_targets = count_distinct($dst)
    $source_hosts = array_distinct($e.principal.hostname)

  condition:
    $e and $distinct_targets >= 5
}

Tuning loop (the numbers are only an example):

1. Run a 7-day retrohunt with alerting off. It returns about 1,400 detections, roughly 200 a day.
2. Find where the detections come from. Use the top sources query in Section 5. Most of the volume comes from three machines: a jump host, a vulnerability scanner, and an IT management server.
3. Add exclusions. Put those hosts in a data table and add one line to the events: section:

   not $e.principal.hostname in %rdp_admin_hosts.hostname

4. Save and run again. Saving creates version 2. Retrohunt the same 7 days. This time it returns 6 detections, and 4 of them line up with a known red team exercise.
5. Widen the range. Run it over 30 days to confirm the rule stays quiet, then enable live detection.

Note: Once a rule uses a data table, it can’t run at real-time frequency. Google doesn’t support real time for rules with data tables.

Use case 2: Sweep for new threat intel indicators

Scenario: Your intel team receives IP addresses and domains linked to an active campaign. You need to know whether any of them have already appeared in your environment.

Check IoC matching first. If the indicators came from a threat intel feed already integrated with SecOps, SecOps may have matched them already. Use retrohunt for indicators you collected yourself, for example from a vendor report, an ISAC alert, or your own analysis.

Set up two data tables. Use campaign_x_ips with an ip column and campaign_x_domains with a domain column. Keeping them separate means neither table has blank cells.

rule ti_campaign_x_sweep {
  meta:
    author = "Threat Intel"
    description = "Connections or DNS lookups to campaign X indicators"
    severity = "High"

  events:
    (
      $e.target.ip in %campaign_x_ips.ip or
      $e.network.dns.questions.name in %campaign_x_domains.domain
    )
    $e.principal.ip = $src

  match:
    $src over 1h

  outcome:
    $hostnames = array_distinct($e.principal.hostname)
    $matched_ips = array_distinct($e.target.ip)
    $matched_domains = array_distinct($e.network.dns.questions.name)
    $first_seen = min($e.metadata.event_timestamp.seconds)

  condition:
    $e
}

How to run it: Retrohunt as far back as your retention and the campaign timeline justify. Then leave the rule live with alerting on so future hits come through as cases. Because the rule uses data tables, it can’t run in real time, so expect some delay on live hits.

When indicators change: Update the data tables, save a new rule version, and retrohunt again.

Use case 3: Scope an incident

Scenario: Forensics gives you SHA-256 hashes from a compromised host. You need to know how far back the activity goes and which other machines ran the same files.

rule ir_case_1234_hash_sweep {
  meta:
    author = "Incident Response"
    description = "Process launches matching hashes from IR case 1234"
    severity = "High"

  events:
    $e.metadata.event_type = "PROCESS_LAUNCH"
    $e.target.process.file.sha256 in %ir_case_1234_hashes.sha256
    $e.principal.hostname = $host

  match:
    $host over 24h

  outcome:
    $first_seen = min($e.metadata.event_timestamp.seconds)
    $last_seen = max($e.metadata.event_timestamp.seconds)
    $users = array_distinct($e.principal.user.userid)

  condition:
    $e
}

Use case 4: Check that tuning didn’t drop real detections

Before you deploy a tuned version, retrohunt it over the same time range you used for the previous version, then compare the two result sets. Every true positive from the old version should still appear in the new one. If one disappeared, your exclusion is too broad.

5. Reading the results: dashboard queries

Retrohunt detections are labeled in the detection.detection_timing_details field, so you can chart them separately from live detections. Both queries use the Detections data source. If the results look cut short, widen the dashboard time range to cover the full retrohunt window.

Retrohunt detections per rule, by the date the activity happened:

detection.detection_timing_details = "DETECTION_TIMING_DETAILS_RETROHUNT"
$rule_name = detection.detection.rule_name
$event_date = timestamp.get_date(detection.collection_elements.references.event.metadata.event_timestamp.seconds)

match:
  $rule_name, $event_date

outcome:
  $detection_count = count_distinct(detection.id)

order:
  $event_date asc

Use this chart for capacity planning. The daily counts are roughly what the SOC would have received if the rule had been live.

Scoping: affected hosts with first and last activity:

detection.detection_timing_details = "DETECTION_TIMING_DETAILS_RETROHUNT"
detection.detection.rule_name = "ir_case_1234_hash_sweep"
$host = group(detection.collection_elements.references.event.principal.hostname, detection.collection_elements.references.event.target.hostname)
$host != ""

match:
  $host

outcome:
  $detection_count = count_distinct(detection.id)
  $first_seen = timestamp.get_timestamp(min(detection.collection_elements.references.event.metadata.event_timestamp.seconds))
  $last_seen = timestamp.get_timestamp(max(detection.collection_elements.references.event.metadata.event_timestamp.seconds))

order:
  $first_seen asc

Change the rule name for each sweep.

To find top sources for tuning (use case 1):

1. Replace the group() line with $host = detection.collection_elements.references.event.principal.hostname. If your network logs don’t carry hostnames, use principal.ip instead.
2. Order by $detection_count desc.

The top rows are your exclusion candidates.

How to read the results:

Don’t trust a zero without a known positive.

1. Run the technique in a test environment, for example an Atomic Red Team test or a red team exercise.
2. Retrohunt the window that covers it.
3. If the rule doesn’t fire, use the Week 19 field coverage query to check that the log source is arriving and the fields the rule needs are populated.

6. For SOC managers: promotion criteria and capacity

Criteria for promoting a rule to live (a starting point; adjust to your team):

Capacity math: Multiply expected daily detections by average triage minutes per alert. For example, 40 a day at 10 minutes each is about 6.7 analyst hours a day. If you don’t have that capacity, tune the rule further, automate its enrichment, or hold it back.

Validation record: Keep promotion evidence in a data table such as rule_validation_log, with these columns:

• rule
• version
• time range
• detections
• true positives
• false positives
• reviewer
• date

The table is searchable inside SecOps and survives staff changes. It also gives auditors evidence when they ask how you validate detections.

Keep retrohunts out of performance metrics: A retrohunt detection is created when the retrohunt runs, but the events behind it can be weeks old. If retrohunt detections land in your Week 18 MTTD query or Week 17 detection volume charts, one retrohunt shows up as a large spike in both. Add this filter to those queries. In the MTTD query, put it inside the per_alert stage next to the alert_state filter.

not detection.detection_timing_details = "DETECTION_TIMING_DETAILS_RETROHUNT"

7. For response engineers: operating retrohunts

8. Things to know about historical data

9. Action items

• Make “disable alerting before a retrohunt” a written standard step
• Adopt the promotion criteria, and require a retrohunt record before any rule goes live
• Build the two retrohunt dashboard charts: volume by event date, and scoping by host
• Create a rule_validation_log data table for promotion evidence
• Set up data table templates for IOC sweeps (separate IP and domain tables) and incident hash sweeps
• Add a retrohunt step to the detection-as-code pipeline through the API
• Exclude retrohunt detections from MTTD and detection volume charts