Threat Hunting Foundations

What Is Threat Hunting?

The Core Definition

Threat hunting is a proactive, analyst-led, iterative search for adversaries that are already present in an environment but have not triggered existing detection controls. The operative word is proactive. You do not wait for an alert. You go looking.

The core question threat hunting answers is: "If an adversary is already here, what evidence exists?" Every hunt starts from that assumption. The adversary is assumed to be present. The hunt is an investigation to find or rule out their presence.

Hunting vs. Alert Triage

Hunting inverts the alert-triage model. Here is the same process compared side by side:

Origins and Scale

• 2015, Sqrrl: formalized the modern definition of threat hunting, publishing the Hunting Maturity Model and the hunting loop concept.
• CrowdStrike OverWatch: operationalized hunting as a managed service. Its threat graph processes over 3 trillion events per week and interrupted more than 41,000 intrusion attempts in the first half of 2020 alone, attempts that would have been missed without a human-led hunt function on top of automated detection.

Why "Assume Breach" Matters

The "assume breach" mindset is not paranoia. It is a calibrated response to the reality that no detection system catches everything. Zero Trust architecture bakes this assumption into network and identity design, and threat hunting operationalizes it at the detection layer.

The Detection Gap

The 197-Day Number

IBM's 2023 Cost of a Data Breach report found an average dwell time of 197 days before detection. Some organizations find adversaries faster now, and median dwell times have improved. But the mean remains high because outliers, the adversaries who stay for months or years, pull the average up. For every breach caught in a week, another goes undetected for a year.

That 197-day window is the detection gap. Your tools were running. Your team was working. The adversary operated undetected anyway.

Why Detection Has Structural Limits

The reason is structural. Most detection relies on two mechanisms, and both have known blind spots:

• Signatures work well against commodity threats but fail against novel malware, living-off-the-land binaries (LOLBins), and advanced actors who deliberately avoid known-bad indicators.
• Threshold-based alerts catch volume anomalies but miss slow, low-volume operations.

Alert Fatigue at Scale

SOCs also face alert fatigue at scale. Red Canary analyzed 329 billion records per day across 1,700 organizations, and the volume narrows sharply on the way to a confirmed threat:

For every confirmed threat, analysts review thousands of false positives. True positives get buried.

The Pyramid of Pain

The Pyramid of Pain illustrates why signature-based detection has structural limits: the higher an indicator sits, the more it costs an adversary to change it.

Hunting operates at the TTP level. It asks "what behaviors would this technique produce?" not "does this hash match our blocklist?" That is why it finds what signatures miss.

SOC Maturity and Hunt Readiness

Maturity Levels and Hunt Readiness

You cannot hunt without data. You cannot hunt effectively without a baseline. SOC maturity determines what kind of hunting is possible, not whether hunting is possible. Even L2 teams can perform basic TTP hunts if they have endpoint telemetry and a query tool.

What L3 Requires

Hunting lives at L3 and above. To hunt meaningfully, you need three things to converge:

• Log coverage: sufficient telemetry across your environment.
• Behavioral baseline: a picture of normal, so deviations stand out.
• Threat intelligence: to inform what you actually hunt for.

The Model Is a Map, Not a Gate

The maturity model is not a gate. It is a map. A team at L2 who understands their gap can prioritize telemetry improvements specifically to enable hunting. That prioritization is more effective than general "improve logging" initiatives because it ties each log source to a specific hunt capability.

CrowdStrike OverWatch operates at the far end of this spectrum: a team of dedicated hunters with access to a threat graph ingesting trillions of events per week, tracking 140+ named adversary groups. That is not a benchmark for most organizations. The relevant insight from their work is the methodology and the adversary behaviors they consistently find. The volume scales down. The techniques do not change.

Hunting vs. IR vs. Threat Intelligence

Comparing the Three Disciplines

These three disciplines are often confused, sometimes merged, and occasionally treated as the same job. They are not. Each has a distinct trigger, goal, primary input, and output. Understanding the difference matters because conflating them produces worse results in all three areas.

The Feedback Loop

The three disciplines form a feedback loop. Each one feeds the others.

Thinking Like an Adversary

From Alerts to Artifacts

The most important shift in threat hunting is not technical. It is conceptual. Stop asking "what do my alerts say?" Start asking "what would an attacker do here, and what evidence would they leave behind?"

Every action an attacker takes produces artifacts recorded in your logs, for example:

• Process creation events
• Registry modifications
• Network connections
• File writes
• Authentication events

The adversary's goal is to minimize their footprint, but they cannot operate without leaving traces. Your job is to know what traces each technique produces and go looking for them.

Mapping ATT&CK Phases to Artifacts

Walk through the ATT&CK lifecycle with this question in mind for each phase:

Case Study: Encoded PowerShell

Prerequisites for an Effective Hunt

Four pillars determine whether a hunt produces results: Data, Tools, Process, and People. Weakness in any one limits the entire hunt. Most teams underinvest in Data and Process while overestimating what Tools alone can do.

Data: Minimum Viable Telemetry

These are the log sources you need before a meaningful hunt is possible. Each one maps directly to specific ATT&CK techniques.

Tools: Minimum Viable Stack

Three tools form the floor. You can hunt with these:

• SIEM or query engine for searching logs.
• EDR for process and memory telemetry, richer data than Windows event logs alone.
• Threat intelligence source, even a free one like MITRE ATT&CK or open-source CTI feeds, to seed hypotheses.

Process: Repeatability

Ad hoc hunting is better than no hunting. But it does not scale. A documented process ensures that every hunt produces artifacts that other analysts can build on. Chapter 3 covers the major frameworks: PEAK, TaHiTI, and SANS PAM. Pick one and use it consistently from day one.

People: Analyst Baseline Knowledge

The hunter needs three skills:

• Knowledge of ATT&CK techniques relevant to your environment's threat model.
• Knowledge of what "normal" looks like in your environment: which processes run on which hosts, what the normal network flows are, what legitimate admin activity looks like.
• Proficiency in at least one query language: KQL, SPL, SQL, or XQL depending on your stack.

The following query is a first hunt for any analyst with endpoint telemetry and a KQL-capable tool. It detects encoded PowerShell commands, one of the most consistent attacker behaviors across all threat actor groups. Red Canary has tracked PowerShell (T1059.001) in the top attacker techniques for five consecutive years.

// Chapter 1 starter: Hunt for encoded PowerShell commands (T1059.001 + T1027)
// This is one of the most consistent attacker behaviors across all threat actor groups
DeviceProcessEvents
| where FileName =~ "powershell.exe" or FileName =~ "pwsh.exe"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand", "-en ", "-e ")
| where InitiatingProcessFileName !in~ ("explorer.exe", "services.exe", "svchost.exe")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

This query surfaces PowerShell invocations with encoding flags that did not originate from common legitimate parents. Results require analyst review. You will see some legitimate automation. The goal at this stage is to understand your population, not to auto-close results. Every legitimate result teaches you your baseline. Every suspicious result is the start of a hypothesis.