A 12,000-Indicator Feed and 2,400 Matches in One Day
The threat intel team subscribes to a commercial feed delivering about 12,000 indicators per day. 78% of the IP indicators resolve to hosting or CDN ranges, and the feed marks nearly all of them 'high confidence'. After enabling the feed in the platform, a hunting query joining endpoint network telemetry to feed IPs returns 2,400 matches in the first 24 hours. Analysts also imported a 30-day-old OSINT list of C2 IPs; several entries now belong to legitimate cloud provider ranges. Meanwhile, a sector advisory describes a phishing campaign that uses a legitimate file-sharing domain and a distinctive user-agent string, with no usable IPs. The platform retains 90 days of endpoint telemetry. Leadership wants proactive hunting from the same three analysts who handle 90 cases per day.
1. Decide which intelligence to operationalize for automatic detection and which to keep hunt-only, and justify each decision.
Read the worked answer
Separate detection-grade intelligence from context-grade intelligence.
Hosting and CDN IPs are context-grade. Shared infrastructure is used by thousands of benign customers, and 'high confidence' in a feed usually means confidence that the address was observed in malicious activity, not that every connection to it is malicious. Using them for auto-detection produces exactly the 2,400 matches. Keep them for enrichment ('destination is a hosting range') and for retrospective hunts that add other conditions.
Operationalize indicators that survive infrastructural rotation: domains or URL paths rather than bare IPs, first-seen inside the campaign window, and corroboration from a second source or your own telemetry. The advisory's combination of a file-sharing domain, a distinctive user-agent, and a download or process execution is detection-grade because it is behavior-based.
The 30-day-old OSINT list should not be a blocklist. Cloud addresses are reassigned; require last-seen under 7 days and mark the list hunt-only. Record each decision and its reason, because 'why is this feed not alerting' will be asked within a month.
2. How would you work down the 2,400 matches without consuming the team for a week?
Read the worked answer
Do not triage 2,400 rows. Reduce them with logic you can defend, and report the funnel.
First check the query itself. A join on IP alone, with no direction and no time window, produces noise. Add outbound direction, a defined window, and exclusions for known scanners and proxies, then see how many matches survive.
Then prioritize: (1) matches on endpoints with a recent phishing or macro alert; (2) matches where the destination is a domain rather than an IP; (3) matches with anomalous bytes transferred or a rare process making the connection; (4) matches on high-value assets such as finance systems, domain controllers, and OT jump hosts; (5) everything else gets bulk enrichment, not investigation.
Publish the counts at each filter. If 2,400 becomes 60, the feed is usable as a hunt source and leadership can see why. Close the loop per cluster: write a detection if the pattern is repeatable, or a documented exclusion with an expiry if it is benign infrastructure. An untriaged backlog is the real failure mode.
3. Design the hunt for the advisory and define what success looks like.
Read the worked answer
Hypothesis: a user in a targeted department received a link to the file-sharing domain, downloaded or opened a file, and within 20 minutes an executable or script ran on the endpoint. That is specific and falsifiable.
Data: proxy and URL filtering for the domain, Zeek HTTP records for the user-agent, endpoint process events for files written to Downloads and subsequently executed, and email gateway delivery logs for the lure.
Query shape: start from the domain in proxy logs by user and time, join to process creation within a 20-minute window, and filter to unsigned or low-prevalence binaries. Baseline the domain's normal usage first - if 400 employees use it legitimately, the domain is not the signal, the join is.
Success is not a hit. Success is a documented yes or no with evidence, a reusable query, and either a new detection or a documented exclusion. Time-box to four hours. If the required telemetry does not reach back far enough, record that as a finding rather than stretching the conclusion. Also test whether the user-agent is trivially spoofable; if it is, weight process execution more heavily than the header.