Indicator of compromise (IOC) sweeps and tactics, techniques, and procedures (TTP) hunting fund different detection work.
The renewal packet for our managed detection and response (MDR) contract included a line item for proactive threat hunting. Before signing, I asked the account team one question: show me the hypothesis behind the last hunt you ran in our environment. They sent a description of their threat intel pipeline. Indicators matched against our telemetry, monthly report attached. Indicator matching is a useful service, but what they billed as proactive hunting was a sweep.
I've run enough vendor selections across security information and event management (SIEM)/endpoint detection and response (EDR) tooling and MDR to see the market pattern: indicator sweeps get sold under the hunting label because most buyers don't ask the question. Both capabilities deserve budget. They're different operating models with different failure modes, and budget gets wasted when teams fund one while believing they bought the other.
In Brief:
- An IOC sweep matches published indicators against telemetry, cheap and automatable hygiene. Calling it hunting misprices the work, and it decays as fast as the adversary can recompile a binary.
- TTP hunting tests hypotheses about adversary behavior. It costs analyst hours by design, and it's the layer that catches the malware-free intrusions that now dominate the industry's intrusion data.
- Much of what gets marketed as "threat hunting" sits closer to automated indicator matching than to hypothesis-driven investigation. Buyers who don't ask for the hypothesis are buying a label.
- The budget call is one decision: automate the sweeps so each one costs about what compute and a feed subscription cost, and fund hunting as staffed analyst hours measured by the detections it produces.
What an IOC sweep actually buys you
IOC sweeps deliver some of the best return-per-dollar detection work a security operations center (SOC) does. Their strengths also cap what they can find, so the same structure that makes sweeps efficient defines the limit of their coverage.
Fast, scriptable, and cheap to run across the whole estate
A sweep takes published hashes and network indicators from an advisory or a feed and queries them against your telemetry, current and historical. A threat intel platform ingests the feed and pushes indicators into the SIEM and EDR so matches surface without an analyst touching anything. A confirmed match is about as high-fidelity as detection gets. It lands in alert triage with the verdict half-made and gives your incident response plan an unambiguous trigger.
Sweeps answer exposure questions the same day across the estate. When a new advisory drops and the board asks whether we're exposed, a sweep answers the same day, across every endpoint, and can re-run against months of history. For a documented campaign with fresh indicators, nothing else delivers that breadth at that cost. I fund this without hesitation. I just refuse to call it hunting.
The coverage decays the moment the adversary rotates infrastructure
David Bianco's Pyramid of Pain, published in 2013, ranks indicators by what it costs an adversary to change them: hashes at the trivial bottom, TTPs at the top. A recompile produces an entirely new hash, and Bianco's own follow-up analysis of VirusTotal submission data ended with a plain instruction: "Please stop using third-party hash values for detection." IP addresses rotate in minutes on cloud infrastructure, and command-and-control (C2) servers frequently live only days before they're abandoned. Domains cost the adversary slightly more effort, but not much.
Open-source intelligence feeds carry duplicates and stale or unvalidated entries, and vendor-provided detection content is already the single largest source of false positives: 66% of false positives originate from vendor-provided rules, per the SANS 2026 Detection Engineering Survey.
What TTP hunting is doing that a sweep can't
TTP hunting tests behavior. Its labor cost is part of the model, and the staffing model decides whether the work is real.
It tests behavior instead of matching indicators
A hunt starts from a hypothesis: if an attacker were abusing valid credentials to move laterally through this environment, the evidence would look like X in log source Y. Analysts then go look. The test holds whether the attacker used last month's binary or one compiled this morning, because behavior such as credential dumping or remote monitoring and management (RMM) tool abuse is what's under examination. Volt Typhoon is the canonical case. The Cybersecurity and Infrastructure Security Agency (CISA) documented the group maintaining footholds for years in critical infrastructure using built-in tools like wmic and PowerShell, activity that produces no hash or malicious domain to sweep for, and the advisory's remediation guidance leans on behavior analytics and hunting rather than indicator matching.
This malware-free approach now dominates intrusion data. 82% of detections were malware-free in CrowdStrike's 2026 Global Threat Report covering 2025 activity. Behavior-level testing is a coverage requirement. The payoff for finding these intrusions yourself shows up in dwell time. In Mandiant's M-Trends 2026 data, the global median dwell time rose to 14 days, up from 11, and organizations first spotted the compromise internally in 52% of cases, up from 43%. Internally caught intrusions still tend to be resolved far faster than the ones an outside party flags.
The analyst hours it costs are the reason it holds up
Hunting resists automation on purpose. Human-led hypothesis formulation marks the boundary automation cannot cross. Lee and Bianco make the same point in their SANS hypothesis-generation paper: the analyst's central contribution to a hunt is forming the hypothesis that guides it. A focused indicator sweep takes an analyst a couple of hours; a hypothesis-driven hunt runs days, across weeks of raw log data. That expense makes the output durable. Detecting at the behavior layer makes the adversary change how they operate, not just what they compile, which is the most expensive move you can force on them and the entire logic of the Pyramid's apex.
The hours also compound in a way sweeps never do. A finished hunt should feed detection engineering, usually with a new detection or a closed telemetry gap, sometimes with just a negative result that rules out a hypothesis. Even a hunt that exposes a logging blind spot has moved the program, because the next hunt starts from better telemetry, and so does every automated detection built after it.
The two answer different questions, so staffing one as the other is the miss
A sweep answers: has this specific, already-documented campaign touched us? A hunt answers: is someone operating in here who hasn't tripped anything we alert on? Conflating them is common enough to show up in survey data. Nearly half of SOCs describe hunting as partially automated vendor-tool work, which the SANS 2025 SOC Survey characterizes as retroactive analysis sitting outside technique-driven hunts. The same survey draws the basic-detection boundary in the same spot, counting Windows Defender scans as basic detection rather than threat hunting.
Bianco's model and TaHiTI draw the line in the same place. The first two hunting maturity levels, the IOC-searching levels, sit outside hunting under the Dutch financial sector's TaHiTI methodology. So when a provider's hunt deliverable is a monthly indicator match report, whether a hunt happened answers itself, because nobody formulated a hypothesis and so nobody hunted. I've sat across from three MDR account teams since that renewal and asked each for their last three hunt hypotheses - only one could produce them.
Where each one earns budget in a real SOC
Budget sweeps as machine work and hunts as analyst work. Fund both on separate lines with separate success measures. Paying analyst rates for machine work leaves no protected time for the work only analysts can do.
Automate the indicator sweeps and stop paying people to run them
Feeds should flow into a threat intel platform, then into SIEM and EDR, with matches surfaced automatically. Set confidence thresholds at ingestion and age indicators with time-to-live so stale indicators expire instead of accumulating. Add feeds a few at a time, with a measurement window before adding more. Run this way, a sweep costs about what the compute and the feeds cost, which is the right price for matching published artifacts.
Every hour an analyst spends pasting hashes into a search bar is an hour billed at investigation rates for work a playbook does free. Unpruned feeds carry a second cost: unvalidated indicators flag legitimate infrastructure, feed alert fatigue, and erode the team's trust in the queue. A small set of validated feeds beats a large noisy one every time, and automated pruning should follow false positive metrics.
Reserve hunting hours for the techniques that fit your environment
Build the hypothesis backlog from your own coverage gaps, mapped to the MITRE ATT&CK techniques your telemetry can actually see. In the SANS 2026 data, 43% of detection engineers name cloud-native environments their top detection coverage gap, and much of what gets sold as cloud-native security doesn't close it. Living-off-the-land (LOTL) tradecraft belongs on the same list, since 76% of nation-state attacks used LOTL techniques per the SANS 2025 Threat Hunting Survey. If identity and cloud telemetry are thinnest, put hunting hours there, especially where native tools hide the activity.
A dedicated team can wait until the program is large enough to support one. SANS documents both the dedicated model for larger organizations and a periodic rotation model where SOC analysts get protected hunt blocks, which works at the ten-person SOC size most of us actually run. My rule for either model: every hunt closes with a detection rule when the data supports one. If telemetry is missing, it closes with a log acquisition request; live activity triggers escalation. If I get one incremental hire this year, it's a hunter who writes detections instead of another feed subscription.
The question that tells you which one you're actually funding
Ask your provider, or your own team: show me the hypothesis behind the last hunt, and show me the detection it produced. Anton Chuvakin's definitional test supplies the follow-up. If you can simply write a detection rule, then write the rule, because at that point you are no longer hunting. If the answer describes a matching pipeline, you're funding a sweep, which is fine, provided it's priced and staffed like one. Most programs can't currently run this check on themselves: only 51% formally measure threat hunting effectiveness per the SANS 2025 Threat Hunting Survey, down from 64% the year before.
So I split the money. The sweeps run automated and metered, costing about what the compute and the feeds cost. The hunting budget buys analyst hours, on my team or a provider's, and every hunt has to leave a hypothesis and a detection behind or it doesn't count. I signed that renewal in the end, but I struck the hunting line item and moved the money into protected hunt time on my own team. The vendor still runs the sweeps, and now the invoice says what it is.
Frequently asked questions about TTP hunting
Is IOC matching considered threat hunting?
Major frameworks treat IOC matching as hygiene. Bianco's Hunting Maturity Model places IOC searching at the lowest levels, and TaHiTI excludes those levels from its definition of hunting outright. IOC sweeps are necessary hygiene; hunting begins when someone formulates a hypothesis about behavior and investigates it.
How quickly do IOC-based detections go stale?
Hashes go stale instantly, since a recompile produces a new one with no other changes. Network indicators do not last much longer: C2 infrastructure often rotates within days, and domains are cheap enough to replace that they're only marginally more durable. That decay curve is why the Pyramid of Pain ranks TTPs at the top as the indicator class that is stickiest and most expensive for adversaries to change.
How often should a small SOC run threat hunts?
SANS documents a periodic rotation model where SOC analysts get protected hunt blocks, which is viable for teams too small to staff a dedicated hunter. Give analysts protected time blocks on a regular cadence rather than leaving hunting to whatever time is left after triage. Analysts hunt when they get those blocks, and fall back to leftover sweeps when they don't.
How do you measure whether a threat hunting program is working?
Measure outcomes. Track new or updated detections created and log source gaps identified and closed. A live-activity finding should trigger escalation. Track what share of hunts produce a confirmed finding or a concrete program improvement; a near-perfect rate suggests you're only testing obvious hypotheses, while a very low one points to weak hypothesis design. A hunt that surfaces a telemetry blind spot still counts as output.
What should you ask an MDR vendor about their threat hunting?
Ask for the hypothesis documentation from their last several hunts in your environment and their MITRE ATT&CK technique coverage mapped to your telemetry, then compare indicator-triggered hunts with hunts run with no prior lead. Their answer should also show how many hunts produced new detection rules. A vendor who can only show feed match counts is selling a sweep under a hunting label.