Threat Hunting Foundations

What Is Threat Hunting?

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.

This is meaningfully different from alert triage. Alert triage is reactive: a tool fires, an analyst investigates, the analyst closes or escalates. The tool drives the process. Alert triage depends on known-bad signatures. If the adversary's behavior does not match a signature, no alert fires, and triage never begins.

Hunting inverts that model. The analyst drives the process. The analyst forms a belief about what an adversary might be doing, then queries data to test that belief. No signature is required. The hypothesis replaces the rule.

The modern definition of threat hunting was formalized around 2015 by Sqrrl, a threat intelligence company that published the Hunting Maturity Model and the hunting loop concept. CrowdStrike OverWatch operationalized it as a managed service, demonstrating at scale what a dedicated hunt team could find. Their threat graph processes over 3 trillion events per week and interrupted more than 41,000 intrusion attempts in the first half of 2020 alone. Those are attempts that would have been missed without a human-led hunt function on top of automated detection.

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. Threat hunting operationalizes it at the detection layer. If you assume breach, you build your security program to find the adversary quickly. If you assume your perimeter holds, you find them 197 days later.

The Detection Gap

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.

The reason is structural. Most detection relies on two mechanisms: known-bad signatures and threshold-based alerts. Signatures work well against commodity threats. They fail against novel malware, living-off-the-land binaries (LOLBins), and advanced actors who deliberately avoid known-bad indicators. Threshold alerts catch volume anomalies but miss slow, low-volume operations.

SOCs also face alert fatigue at scale. Red Canary analyzed 329 billion records per day across 1,700 organizations. That volume produced 419 million investigative leads, which filtered down to 8.5 million potentially malicious events, which confirmed as 110,000 actual threats. The ratio is roughly 3,800:1. For every confirmed threat, analysts review thousands of false positives. True positives get buried.

The Pyramid of Pain illustrates why signature-based detection has structural limits. At the base sit hash values: trivial to change, caught by AV, useless against a motivated actor who recompiles every sample. Moving up: IP addresses (easy to rotate), domain names (cheap to register), network and host artifacts (more effort to change), tools (harder, requires rewriting capabilities), and TTPs at the apex. TTPs, the actual techniques and procedures an adversary uses, are expensive to change. An actor cannot easily stop using PowerShell or lateral movement via SMB. Those behaviors are baked into their tradecraft.

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

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.

Hunting lives at L3 and above. To hunt meaningfully, you need three things: logs with sufficient coverage, a baseline of normal behavior to spot deviations from, and threat intelligence to inform what you hunt for. L3 is when these three converge.

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

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 three disciplines form a feedback loop. Each one feeds the others.

Thinking Like an Adversary

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. Process creation events, registry modifications, network connections, file writes, authentication events. These artifacts are recorded in your logs. 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.

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

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

A SIEM or query engine for searching logs. An EDR for process and memory telemetry, which provides richer data than Windows event logs alone. A threat intelligence source, even a free one like MITRE ATT&CK or open-source CTI feeds, to seed hypotheses. That is the floor. You can hunt with these three.

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, specifically which processes run on which hosts, what the normal network flows are, and 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.