The Problem
I’ve got a recurring frustration with how “threat hunting” gets thrown around in incident response circles. I’ll be deep in an active incident where we’ve detected a compromise, we’re investigating affected systems, we’re scoping out how far the attacker got, and someone will inevitably say “we need to do some threat hunting to find other compromised hosts.”
No. That’s not threat hunting. That’s using sweeping to scope the incident. That’s just… incident response.
This isn’t pedantry for the sake of it. Words mean things, especially in our field where clear communication during an incident can be the difference between containment and catastrophe. So let’s sort this out.
What Threat Hunting Actually Is
According to every major security vendor and framework out there, threat hunting is:
The proactive search for NEW, undetected threats that have evaded your existing security controls.
Let’s break that down:
- Proactive: You’re not responding to an alert or incident. You’re going looking.
- Undetected: Whatever you’re hunting for hasn’t triggered your detection systems.
- New: You don’t already know about this compromise.
CrowdStrike defines it as “the practice of proactively searching for cyber threats that are lurking undetected in a network.” Splunk calls it “any manual or machine-assisted process for finding security incidents that your automated detection systems missed.”
The key word across all these definitions? Undetected.
What Incident Scoping Actually Is
When you’re already in an incident, when something HAS been detected, when you KNOW you’re compromised, when you’re working an active case, the process of finding additional affected systems is called incident scoping, sometimes colloquially referred to as sweeping.
SentinelOne puts it beautifully: “The purpose of DF/IR methodologies is to determine what happened after a data breach has already come to light.”
That’s the distinction. Threat hunting happens BEFORE you know there’s a problem. Incident response (including scoping) happens AFTER you’ve detected one.
Why This Matters
Beyond just getting the terminology right, conflating these concepts causes real problems:
1. Resource Allocation
Threat hunting and incident response require different resources, skills, and time commitments. If you’re in an active incident and someone says “let’s threat hunt,” you might spin up your threat hunting team when what you actually need is your incident response team working overtime.
2. Expectations and Urgency
Threat hunting is typically a deliberate, hypothesis-driven process. You’re exploring, investigating leads, potentially spending days or weeks on a hunt. Incident scoping during an active response needs to be fast and focused - you’re not exploring, you’re containing.
3. Metrics and Reporting
If you’re reporting “threat hunting activities” but what you’re actually doing is incident response, your metrics are garbage. Your threat hunting program looks busier than it is, and your incident response workload is being undercounted.
4. Communication Clarity
When you’re briefing stakeholders on an incident, telling them you’re “threat hunting” suggests you’re not sure if there’s a problem yet. That’s very different from “we’ve confirmed a breach and are scoping the impact.”
5. Burden of Proof
Threat hunting teams are generally required to triage their findings before reporting them to the SOC for a security response. Sweeping the environment for indicators of compromise, as a part of scoping, generally doesn’t have this burden. If the indicator exists on a machine, that machine becomes part of the incident response scope, no additional analysis required.
The Practical Difference
Here’s how it plays out in the real world:
Threat Hunting Scenario: Your EDR hasn’t alerted. Your SIEM is quiet. But you’ve read about a new technique where attackers are abusing legitimate admin tools in creative ways. You build a hypothesis: “What if someone is using PSExec in an unusual pattern to move laterally?” You query your logs, looking for anomalies. You find evidence of compromise that bypassed your detections. You’ve just completed a successful hunt. This is threat hunting.
Incident Scoping Scenario: Your EDR alerts: Dropper execution detected on WORKSTATION-042. You investigate and confirm the dropper pulls down undetected malware, and the workstation was compromised. Now you need to find everywhere that malware was dropped, every system it touched, every file it accessed. You’re pivoting on IOCs, searching logs, looking for related activity. This is incident scoping. It’s part of incident response. It is NOT threat hunting.
Industry Consensus
This isn’t just my opinion. Every major security vendor and framework agrees threat hunting is looking for:
- CrowdStrike: Threats “lurking undetected”
- Splunk: Incidents “your automated detection systems missed”
- Microsoft Sentinel: “Anomalies that aren’t detected by your security apps”
- Fortinet: Explicitly contrasts proactive threat hunting with reactive incident response
- SentinelOne: Distinguishes hunting from DF/IR which addresses breaches “after they come to light”
The consensus is clear and consistent. Threat hunting is for finding NEW incidents. Incident response (including scoping/sweeping) is for handling EXISTING incidents.
Conclusion
If it’s already detected and you’re responding to it, you’re not hunting. You’re responding.
Threat hunting is for finding NEW compromises that evaded your defenses. Incident scoping is for determining the extent of KNOWN compromises. They use similar techniques, but they’re fundamentally different activities with different goals, different urgency levels, and different success criteria.
Words mean things. Use the right ones.
Sources: