Threat Hunting: What It Is and How It Works

Threat hunting is the practice of proactively searching through networks and endpoints for attackers who have already slipped past your existing detections. It starts from a simple, uncomfortable assumption: something bad may already be inside, and no alert fired for it. Instead of waiting for a SIEM rule to trigger, a hunter forms a hypothesis and goes looking for evidence to confirm or kill it.

Why detection alone isn't enough

Signature-based and rule-based detection catches known patterns. Attackers using living-off-the-land binaries (LOLBins), valid credentials, or slow, low-volume techniques can stay under those thresholds for weeks. Threat hunting fills that gap by having a human actively question the data: does this PowerShell invocation from a finance workstation at 2 a.m. make sense? Why is svchost.exe making an outbound connection to an IP with no reverse DNS?

This isn't incident response. IR starts after you know something happened. Hunting starts when you don't know yet, and the goal is to find that out before a bigger event forces the question.

The three common starting points

Most hunts begin from one of three angles:

• Intelligence-driven: a new threat report describes a TTP (say, abuse of a scheduled task for persistence), and you check whether it's present in your environment.
• Situational awareness: you look at what's actually unusual for your organization — a service account authenticating from a country it never has before, or a spike in SMB traffic between workstations that normally only talk to servers.
• Analytics-driven: you build a baseline of normal behavior (process trees, login times, DNS query volume) and hunt for statistical outliers against it.

MITRE ATT&CK is the reference most teams use to structure hypotheses. Instead of "look for malware," you pick a technique like T1053 (Scheduled Task/Job) and ask: what would that look like in our Windows Event Logs or EDR telemetry, and can I query for it right now?

What the actual workflow looks like

A hunt usually follows this loop:

1. Form a specific, testable hypothesis (not "check for intrusions" but "check for new scheduled tasks created outside patch windows in the last 30 days").
2. Identify the data sources needed — Sysmon Event ID 1 for process creation, Windows Security Event ID 4698 for scheduled task creation, EDR process trees, or Zeek conn logs for network context.
3. Query and pivot. In practice this means writing KQL in Microsoft Sentinel, SPL in Splunk, or raw queries against an Elastic index.
4. Triage results — most will be false positives or benign admin activity, and the job is narrowing that noise down to what's genuinely anomalous.
5. Document findings, whether it's a confirmed compromise, a detection gap, or just a