What Threat Hunting Actually Is
Threat hunting is the proactive, human-led search for adversary activity that has evaded your automated detection controls. Where a SIEM fires alerts on known signatures and threshold anomalies, a threat hunter formulates a hypothesis — “I suspect an adversary is performing Kerberoasting in our environment” — and then goes looking for evidence, whether or not an alert has fired.
The distinction matters. Relying solely on reactive alerting means your detection coverage is bounded by what you have already thought to detect. Threat hunting expands that coverage by systematically probing your environment against known adversary techniques before they manifest as incidents.
The Hunting Maturity Model
Not all organizations are ready to run advanced hunts. The Hunting Maturity Model (HMM) describes five levels:
- HMM-0 (Initial): Relies entirely on automated alerting. No proactive hunting capability.
- HMM-1 (Minimal): Hunt procedures documented but conducted only when a specific IOC or threat report triggers them.
- HMM-2 (Procedural): Regular, scheduled hunts following documented playbooks. Hunts are IOC-driven and pattern-matching oriented.
- HMM-3 (Innovative): Hypothesis-driven hunts that go beyond known IOCs. Hunters analyze TTPs and develop custom detection logic from hunt findings.
- HMM-4 (Leading): Machine learning and behavioral analytics augment human hunters. Hunt findings automatically feed detection engineering pipelines.
Most organizations should target HMM-2 to HMM-3 before investing in advanced analytics tooling. Solid log coverage and documented procedures produce more hunting value than ML models running on incomplete telemetry.
Building the Hypothesis
A hunt hypothesis is a falsifiable statement about adversary behavior in your environment. Good hypotheses are specific, grounded in threat intelligence, and mapped to a data source that can confirm or deny them.
The anatomy of a strong hypothesis:
Hypothesis: An adversary is performing credential access via LSASS memory dumping
on Windows endpoints in the engineering network segment.
Technique: MITRE ATT&CK T1003.001 (OS Credential Dumping: LSASS Memory)
Data Source: Windows Security Event Log (Event ID 4656, 4663 — handle to lsass.exe),
Sysmon Event ID 10 (ProcessAccess targeting lsass.exe),
EDR process telemetry
Hunt Query: Find processes accessing lsass.exe where the caller is not a known
legitimate process (antivirus, EDR agent, Windows components).
Expected findings if true: Unusual process (e.g., cmd.exe, powershell.exe, custom
binary) with PROCESS_VM_READ access to lsass.exe.
Hypotheses should be sourced from three pools: current threat intelligence (what are adversaries targeting organizations like yours?), recent incidents and near-misses in your environment, and a systematic walk through the MITRE ATT&CK matrix for techniques relevant to your asset profile.
MITRE ATT&CK as a Hunting Framework
ATT&CK provides a structured taxonomy of adversary techniques organized by tactic (the adversary’s goal) and technique (how they achieve it). For hunting purposes, ATT&CK serves three functions:
- Coverage mapping: For each technique, do you have a data source that would surface it? Do you have a detection or hunt procedure covering it? ATT&CK Navigator lets you visualize coverage gaps.
- Hypothesis generation: Each technique page lists data sources, detection recommendations, and real-world procedure examples from threat actor reports. This is your hunting playbook source material.
- Prioritization: Cross-reference ATT&CK techniques against threat intelligence reports on adversary groups targeting your sector. Hunt the techniques those groups actually use first.
# Example: ATT&CK-based coverage assessment (simplified)
techniques:
- id: T1059.001 # PowerShell
data_sources: [PowerShell logs, Sysmon, EDR]
detection_coverage: high
hunt_procedures: [hunt-ps-obfuscation.md, hunt-ps-encoded-commands.md]
- id: T1003.001 # LSASS Memory
data_sources: [Sysmon Event 10, Windows Security 4656]
detection_coverage: medium
hunt_procedures: [hunt-lsass-access.md]
- id: T1055.012 # Process Hollowing
data_sources: [Sysmon Event 8, EDR]
detection_coverage: low # <-- prioritize building hunt here
hunt_procedures: []
Conducting the Hunt: A Worked Example
Walk through a complete hunt for lateral movement via Pass-the-Hash (T1550.002).
Step 1: Define the hypothesis
An adversary has compromised a workstation and is using stolen NTLM hashes to authenticate to other hosts in the 10.0.1.0/24 segment without knowing the plaintext password.
Step 2: Identify data sources
Windows Security Event ID 4624 (logon success) with LogonType 3 (network logon) and AuthenticationPackageName of NTLM is the primary signal. Correlate with 4625 (logon failure) for reconnaissance activity preceding successful lateral movement.
Step 3: Write the hunt query
# SIEM query (pseudo-SPL / Sigma-style)
index=wineventlog EventCode=4624
LogonType=3
AuthenticationPackageName=NTLM
NOT TargetUserName="*$" # exclude machine accounts
| stats count by SourceIP, TargetHostname, TargetUserName
| where count > 5 # multiple targets from same source
| join SourceIP [
search index=wineventlog EventCode=4625 LogonType=3
| stats fail_count=count() by SourceIP
]
| where fail_count > 10 # preceded by failures (hash spraying)
Step 4: Analyze results
Cluster results by source host. A single source IP authenticating via NTLM to five or more distinct hosts within a short time window is a strong lateral movement indicator. Investigate the source host first — check for credential access events, unusual process activity, and recent file writes.
Step 5: Triage and escalate
If the hunt surfaces genuine adversary activity, escalate to incident response. If it surfaces false positives (legacy applications using NTLM legitimately), document the exceptions and refine the query before converting it to a standing detection rule.
Detection-as-Code: Converting Hunt Findings to Standing Detections
A hunt that surfaces a gap in your detection coverage but does not result in a new detection rule has delivered only half its value. Detection-as-code practices ensure hunt findings are systematically converted to durable detections.
The workflow:
- Hunt surfaces a technique with no existing detection.
- Hunter writes a Sigma rule (vendor-neutral detection format) capturing the logic.
- Rule is committed to the detection engineering Git repository and reviewed by peers.
- CI/CD pipeline compiles the Sigma rule to the target SIEM format (SPL, KQL, Lucene) and deploys it.
- Rule is tagged with the ATT&CK technique, hunt reference, and author for traceability.
# Sigma rule: LSASS memory access by non-standard process
title: Suspicious LSASS Memory Access
id: a7b3c2d1-e4f5-6789-abcd-ef1234567890
status: experimental
description: Detects non-standard processes accessing LSASS memory
(potential credential dumping via T1003.001)
references:
- https://attack.mitre.org/techniques/T1003/001/
logsource:
product: windows
category: process_access
detection:
selection:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|contains:
- '0x1010'
- '0x1410'
- '0x147a'
filter_legitimate:
SourceImage|endswith:
- '\MsMpEng.exe'
- '\svchost.exe'
- '\csrss.exe'
condition: selection and not filter_legitimate
falsepositives:
- Some EDR and AV products
level: high
tags:
- attack.credential_access
- attack.t1003.001
Building the Program: People, Process, and Data
A threat hunting program requires three foundations:
People
Hunters need deep knowledge of operating system internals, attacker TTPs, and your specific environment. Start with one or two senior security analysts dedicated to hunting part-time, then grow to a dedicated function as the program matures. Rotate analysts through the hunt team to spread knowledge and prevent burnout.
Process
Establish a documented hunt cycle: hypothesis backlog, sprint planning (typically two-week hunt sprints), execution, findings documentation, and detection engineering handoff. Track hunt coverage against the ATT&CK matrix. Measure time-to-detect for techniques before and after hunts deploy detections.
Data
Hunts are only as good as your telemetry. The minimum viable data set for endpoint hunting: process creation logs (Sysmon Event ID 1 or EDR equivalent), network connections (Sysmon Event ID 3), DNS query logs, authentication logs, and PowerShell script block logging. Gaps in telemetry should drive your log collection roadmap.
Metrics That Matter
Avoid vanity metrics. The metrics that demonstrate program value:
- ATT&CK coverage percentage: What fraction of relevant techniques have a detection or hunt procedure?
- Detections generated per hunt: How many standing detections did hunt findings produce this quarter?
- Mean time to detect (MTTD): Is MTTD improving as hunt-derived detections accumulate?
- True positive rate of hunt-derived detections: Are the detections your hunters write actually firing on real threats?
Conclusion
A threat hunting program is one of the highest-leverage investments a security team can make. It directly addresses the gap between what your automated controls detect and what adversaries are actually doing. The key is to start structured — with documented hypotheses, ATT&CK mapping, and a detection engineering feedback loop — rather than ad hoc log trawling. Build the program incrementally, measure coverage improvements, and let hunt findings systematically harden your detection posture over time.
