Threat Hunting Process: A Repeatable Framework SOC Analysts Actually Use

Most threat hunting programs die in week three. Not because the team lacks skill — because they have no process. They run the same queries they ran last month, call it a hunt, and file a report that says "nothing found."

That's not hunting. That's reactive monitoring with extra steps.

A real threat hunting process starts with a hypothesis, follows a defined execution path, and ends with a detection engineering output whether the hunt finds something or not. Here's the full framework I've used across financial institution SOCs running CrowdStrike, Sentinel, and Splunk.

Why Most Hunts Fail Before They Start

The failure mode is almost always the same: a senior analyst picks a topic, pulls some logs, looks around for 30 minutes, and concludes there's nothing to find. No documented hypothesis. No defined scope. No output beyond "checked, looks clean."

Three problems with that approach:

• You can't repeat it — next month someone else runs a different set of queries on the same topic and gets different results
• You can't measure it — leadership has no idea what was actually covered or what gaps remain
• You get no residual value — even a hunt that finds nothing should produce a detection rule or a data gap finding

The fix is structure. Not bureaucracy — structure. A defined input (hypothesis), a defined process (execution phases), and a defined output (detection or documented gap).

Phase 1: Hypothesis Generation

Every hunt starts with a written hypothesis. Not a topic. A hypothesis.

Topic: "Let's hunt for lateral movement."

Hypothesis: "Threat actors who have compromised a workstation are using pass-the-hash to authenticate to internal servers using NTLM rather than Kerberos, which should be visible as 4624 Type 3 logons with NtLmSsp authentication package from workstation-class source IPs to server-class destination IPs."

The difference matters. The topic gives you no scope and no success criteria. The hypothesis tells you exactly what data to pull, what to look for, and what it means if you don't find it.

Where to source hypotheses

Four reliable sources that actually produce useful hunts:

• MITRE ATT&CK coverage gaps — map your current detection rules against the framework, hunt the techniques you have no coverage for
• Threat intelligence — active campaigns targeting your sector, TTPs from recent IR reports (Mandiant, CrowdStrike, DFIR Report)
• Incident history — what did your last three real incidents look like, what would have caught them earlier
• Environment changes — new system deployments, cloud migrations, M&A integrations all create blind spots worth hunting

Phase 2: Scoping and Data Validation

Before you run a single query, validate that the data you need actually exists and is complete. This sounds obvious. It's skipped constantly.

A hunt for NTLM pass-the-hash requires 4624 events with full authentication package fields. If your SIEM is ingesting Security logs but stripping the extended fields for cost reasons, your hunt will come back clean not because there's nothing there, but because you're looking at incomplete data. That's a false negative, and it's worse than not hunting at all because it creates a false sense of coverage.

Data validation queries

// Check that auth package field is populated
SecurityEvent
| where EventID == 4624
| where TimeGenerated > ago(7d)
| summarize
    TotalEvents = count(),
    WithAuthPackage = countif(isnotempty(AuthenticationPackageName)),
    NTLMEvents = countif(AuthenticationPackageName == "NTLM")
| extend FieldCompleteness = round(todouble(WithAuthPackage) / TotalEvents * 100, 1)

Phase 3: Hunt Execution

Execution follows a consistent pattern regardless of the technique being hunted:

1. Pull the broad population — all instances of the behavior, legitimate and suspicious
2. Baseline the legitimate — identify the known-good patterns (scheduled tasks, admin tools, approved processes)
3. Subtract the baseline — what remains after removing known-good is your anomaly population
4. Prioritize the anomaly population — by rarity, by target sensitivity, by time clustering
5. Investigate the top items — manual review, correlated context, timeline reconstruction

CrowdStrike LogScale — Pass-the-Hash hunt query

// Hunt: NTLM auth from workstation to server-class hosts
#event_simpleName=UserLogon
LogonType=3
AuthenticationPackage="NTLM"
| regex("^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)", field=RemoteIP)
| groupBy([UserName RemoteIP ComputerName], function=count())
| rename(field=_count, as=AuthCount)
| sort(AuthCount, order=desc)
| tail(50)

Splunk SPL — Pass-the-Hash hunt query

index=win_* sourcetype="WinEventLog:Security"
EventCode=4624 Logon_Type=3
Authentication_Package=NTLM
earliest=-30d latest=now
| stats count values(Source_Network_Address) as SourceIPs
    values(Workstation_Name) as WorkstationNames
    by Account_Name ComputerName
| where count > 5
| sort - count

Phase 4: Evidence Documentation

Every hunt — whether it finds something or not — needs a documented evidence record. This is the part most teams skip, and it's where most of the value gets lost.

Phase 5: Detection Engineering Output

This is the phase that turns hunting from a cost center into a force multiplier. Every completed hunt should produce one of three outputs:

• A new detection rule — if you found technique evidence, the hunt query becomes the detection with tuned thresholds and false positive suppression
• An improved existing rule — if the hunt revealed gaps in a current rule's coverage or too many false positives
• A documented data gap — if you couldn't complete the hunt because required logs weren't available, that's a finding that goes to the data engineering backlog

Building a Hunt Calendar

Once the process is in place, the next step is a quarterly hunt calendar so coverage is deliberate rather than opportunistic. A working format:

• Two hunts per month minimum — one MITRE coverage gap, one threat-intel driven
• Rotate platforms so CrowdStrike, Sentinel, and Splunk each get hunted regularly
• Reserve one slot per quarter for environment-change-driven hunts (new cloud deployment, M&A activity)
• Track MITRE technique coverage as a percentage — report it to leadership quarterly

Coverage tracking sounds bureaucratic until leadership asks "are we covered against the technique used in the recent sector breach" and you can answer with a specific date and a link to the hunt record instead of "we think so."

Common Mistakes That Kill Hunt Programs

• Hunting without a hypothesis — produces inconsistent, unrepeatable results with no measurable coverage improvement
• Skipping data validation — creates false confidence in coverage when the data was never complete to begin with
• No detection output — the hunt value disappears the moment the analyst closes their terminal; the detection rule is what makes the hunt permanent
• Hunting the same techniques repeatedly — feels productive, produces no new coverage; use a coverage matrix to force breadth
• No time tracking — without knowing how long hunts take, you can't staff for them or justify the program to leadership