Hunting a Shared Behavioral Package Across a 40,000-Endpoint Estate
You run a three-person threat hunting team at a manufacturer with 40,000 endpoints, 2,600 servers, and 90 days of EDR telemetry. The SIEM retains 30 days, and command-line logging is enabled on only 40% of servers. A sector peer shares a TLP:AMBER package: 3,800 MD5 hashes of commodity loaders, 900 domains, 300 IPs, and 12 behavioral notes. Two notes stand out: rundll32.exe spawned by wmiprvse.exe, and scheduled tasks named \Microsoft\Windows\UpdateOrchestrator\UO<8 hex characters> executing a signed binary from C:\ProgramData. Your EDR console has no saved-query support for task names, but it exports process trees, and Splunk ingests Windows Security events from domain controllers and 55% of member servers. Leadership wants a plan by end of day and expects "the IOCs loaded into the blocklist first."
1. Rank the hunt hypotheses by expected value and lay out the first 48 hours.
Read the worked answer
Rank by likelihood given sector targeting, multiplied by impact, multiplied by detectability with the telemetry you actually have - not by what is easiest to load into a console.
Hypothesis A (highest): the actor is present and using the UO-prefixed scheduled task to relaunch a signed binary from ProgramData. Rationale: the naming pattern is a structural artifact tied to this actor's tooling, it survives reboots, and it is rare in legitimate estates. Hunt it first. Because the EDR cannot query task names, go to Splunk: 4698/4699 and Sysmon Event ID 1/11 with TaskName regex \\Microsoft\\Windows\\UpdateOrchestrator\\UO[0-9a-fA-F]{8}, plus file creation under ProgramData with a valid signature. Time-box to the 30 days of SIEM retention, then pivot to EDR process trees for the same path over 90 days.
Hypothesis B: WMI-driven execution, evidenced by wmiprvse.exe spawning rundll32.exe. Medium fidelity - SCCM and inventory tooling produce this ancestry legitimately, so baseline the estate first. A raw query will drown you in false positives; anchor it with command-line content and parent-child rarity, and accept that 45% of servers give you process ancestry only, not full command lines.
Hypothesis C (lowest): the atomic indicators. The 3,800 MD5s are commodity loaders, likely already covered by antivirus, and MD5 is trivially mutated. Hunt the 300 IPs in proxy and firewall logs, and the 900 domains in DNS logs - not on endpoints, where they rarely appear.
Sequence: baseline legitimate scheduled tasks and WMI ancestry on day 1 while running the task hunt; day 2 run the ancestry hunt and retro-hunt network logs; keep the MD5s as alert-only EDR indicators on servers, not block, until you know what the signed binary is.
2. How would you triage the 5,000 indicators, and what would you refuse to do with them?
Read the worked answer
Split the package by half-life. Atomic indicators decay - infrastructure rotates, hashes mutate, and a shared blocklist is a snapshot of someone else's intrusion, not yours. Behaviors persist, so the 12 behavioral notes carry most of the durable value.
Concrete handling:
- Convert, don't just ingest. For each behavioral note, write a detection with a stated false-positive hypothesis and a test case. That is the deliverable, not a feed subscription.
- Tier the atoms. MD5s of commodity loaders go to an alert-only list, scoped to server tiers where a loader has no business. Domains and IPs go to DNS and proxy lookups for retro-hunting, which is where shared infrastructure actually earns its keep.
- Check for collisions. Compare the MD5 set against your existing AV coverage; if 90% is already blocked, say so and spend the time elsewhere.
Refuse to:
- Load 5,000 indicators into blocking policy without an expiry and an owner. Blanket blocks cause outages and then get disabled, which is worse than never loading them.
- Treat a TLP:AMBER package as forwardable. It goes to named recipients only, and derived detections keep the marking.
- Report "we loaded the IOCs" as a hunt outcome. Ingestion is not detection.
- Assume the peer's infrastructure set is complete. Note what the package is silent about - persistence mechanisms beyond the scheduled task, credential access, lateral movement - and treat that silence as a gap to task, not as absence.
3. Define success for this hunt and describe the report you would take to leadership.
Read the worked answer
Success is not a hit count. Use four measures:
- Coverage - what fraction of the estate the hypotheses were actually tested against, stated honestly (for example: task hunt covered 55% of member servers and all domain controllers; 45% of servers have no command-line telemetry).
- Detection yield - number of new, tested detections deployed, and their measured false-positive rate on a 7-day backtest.
- Confirmed findings - true positives with an owner and a containment date, including the negative results, which are intelligence too.
- Time - hours from package receipt to first sweep completed, and to detection deployed.
The report to leadership should lead with the decision, not the telemetry: "We tested two actor behaviors across the estate. One could only be tested on 55% of servers because command-line logging is missing; we found X and closed it. We are recommending a logging change that costs Y and closes the blind spot for future hunts." Name the telemetry gap as a business risk with a cost, since that is the only lever that survives budget season. Include the hypothesis list, the negative results, and a re-hunt date. Keep the TLP:AMBER source out of the leadership deck; cite it as "peer sharing group" unless the agreement permits more.