July 10, 202612 min read

Threat Hunting: A Hypothesis-Driven Methodology for Finding Attackers in Your Environment

Sources:MITRE ATT&CK Framework|Sqrrl Threat Hunting Reference Guide|PEAK Threat Hunting Framework (Splunk)

Eric Bang

Founder & Cybersecurity Evangelist

197 days

average attacker dwell time in environments without proactive threat hunting; mature hunting programs reduce this to under 30 days

200+

adversary techniques in MITRE ATT&CK that serve as documented hypothesis sources, each mapped to specific log sources and behavioral indicators

5 steps

in the hypothesis-driven hunt cycle: form hypothesis, identify data sources, execute query, investigate leads, convert to detection rule

> 80%

target detection rule conversion rate for completed hunts; below this signals hypotheses that cannot be automated from available telemetry

The hypothesis-driven hunt cycle

Every successful hunt follows the same five-step cycle: form a testable hypothesis, identify the data sources that would reveal it, execute the query, investigate leads, and convert findings into a permanent detection rule. The discipline is in making each step explicit before moving to the next, so that hunters build a documented record of what was tested, what was found, and what automated coverage was created as a result. Without this structure, hunting devolves into ad hoc log browsing that leaves no lasting improvement to detection posture. The cycle applies whether you are hunting for LSASS credential dumping, C2 beaconing, or living-off-the-land binary abuse.

Step 1: Form a specific, testable hypothesis

A good hunting hypothesis specifies: the attacker behavior (what technique), the data source it would appear in (what logs), and the observable indicator (what you would see if the behavior occurred). Example bad hypothesis: 'Look for malware.' Example good hypothesis: 'If an attacker is using LSASS credential dumping (T1003.001), there will be handles opened to lsass.exe from non-system processes, visible in EDR process telemetry or Windows Security Event ID 10 (process access events).' The hypothesis is falsifiable: you can test it and determine whether the evidence supports or refutes it.

Step 2: Identify data sources and baseline

For your hypothesis to be testable, the relevant data must exist and be accessible. Identify: which log sources contain the telemetry needed (EDR process telemetry, Windows Event Log, network flow data), whether those logs are available in your SIEM for the time period of interest, and what the baseline looks like for normal behavior in that data. LSASS handle events from SYSTEM, lsass.exe itself, and a handful of security tools are normal — handles from unknown processes are the anomaly. You cannot hunt without knowing the baseline.

Step 3: Execute the hunt query

Write and run the query against your SIEM or EDR that tests the hypothesis. For LSASS access hunting in Splunk: index=windows EventCode=10 TargetImage='*\lsass.exe' | where NOT match(SourceImage, '(?i)(system32|sysmon|defender|crowdstrike)') | stats count by SourceImage, SourceProcessId | sort -count. In CrowdStrike Falcon (Event Search): event_simpleName=ProcessRollup2 ImageFileName=*/lsass.exe TargetProcessId=* | stats count by SourceImageFileName. The query result is either clean (no suspicious events) or produces leads to investigate.

Step 4: Investigate leads and determine disposition

Each result from the hunt query requires disposition: is this a true positive (actual attacker activity), a false positive (legitimate software behaving normally that matches the pattern), or indeterminate (not enough information to determine)? Investigate true positives with full incident response procedures. For false positives: document the specific software, behavior, and why it matches, and refine the hypothesis or query to exclude it. For indeterminate cases: gather additional context (what else has this process done, does this host have other suspicious activity) before closing.

Step 5: Convert findings to detection rules

Regardless of whether the hunt finds attacker activity, the output includes a detection rule. A hunt that finds nothing confirms that the technique was not present in this time window — not that it will never be present. Convert the tuned hunt query into a scheduled detection rule in your SIEM or EDR. Future instances of the same behavior will trigger an automated alert. The cumulative effect: each completed hunt reduces the dwell time for future attacks using that technique, because detection becomes automated rather than requiring manual hunting.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Hypothesis sources: where hunting targets come from

Generating good hypotheses requires structured input sources, not inspiration. Ad hoc hypothesis generation produces random coverage rather than systematic improvement against the techniques most likely to be used against your environment. The four primary sources are MITRE ATT&CK gap analysis, sector-specific threat intelligence, statistical anomaly data from your own environment, and the technique inventory from previous incidents. Each source produces a different category of hypothesis and covers blind spots the others miss. Mature hunt programs maintain a backlog of prioritized hypotheses drawn from all four sources so that hunters always have a documented, ranked queue to work from.

MITRE ATT&CK gap analysis

Map your current detection rules to MITRE ATT&CK techniques. Techniques with no detection coverage (no alert fires when that technique is executed) are hunting candidates. Tools: MITRE ATT&CK Navigator (free, browser-based) allows you to color-code which techniques you cover and which you do not, producing a visual gap map. Prioritize hunting in gaps that correspond to techniques commonly used by threat actors targeting your sector — MITRE's ATT&CK Groups mapping shows which techniques specific threat actors (APT29, Lazarus Group, FIN7) use, helping you prioritize high-relevance gaps.

Threat intelligence about your sector

Recent threat intelligence about attacks on organizations similar to yours produces specific, targeted hypotheses. If a ransomware group is actively targeting healthcare organizations and is known to use a specific initial access technique (RDP brute force followed by Cobalt Strike deployment), that is a specific, high-priority hunting hypothesis for healthcare security teams: 'Are there RDP login patterns consistent with brute force, followed by unexpected PowerShell activity, on any of our external-facing RDP servers?' Threat intelligence subscriptions (ISAC reports, commercial TI feeds) provide this sector-specific context.

Anomaly analysis from your own environment

Your own data contains hunting leads: processes that run rarely but intermittently (run these against baseline frequency counts — outliers warrant investigation), systems with unusual outbound network connections compared to their peer group, user accounts with access patterns that differ significantly from their team peers. Statistical outlier detection in your SIEM or EDR produces a ranked list of anomalies — filter by those that could represent attacker behavior (unusual parent-child process relationships, hosts communicating with external IPs outside business hours) to generate data-driven hunting hypotheses.

Post-incident technique inventory

After every security incident, document all attacker techniques (mapped to MITRE ATT&CK) that were used. Ask: if another attacker used the same techniques against another part of our environment, would our detections catch it? For every technique in the post-incident review where the answer is 'no' or 'maybe,' create a hunting hypothesis. Post-incident hunting is how you ensure that a breach in one business unit produces detection improvements that protect the whole organization.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Free daily briefing

Briefings like this, every morning before 9am.

Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.

Practical hunt queries by data source

Different data sources expose different attacker behaviors, and effective hunters know which log source to query for which hypothesis category. EDR process telemetry excels at detecting living-off-the-land abuse and credential access; SIEM Windows Event Logs reveal lateral movement and privilege escalation patterns; network flow data exposes C2 beaconing; DNS logs surface domain generation algorithm activity. These are production-tested starting points for each major source. Every query here should be treated as a hypothesis baseline that you tune to your environment's specific baseline before promoting to a scheduled detection rule.

EDR process telemetry: detecting living-off-the-land attacks

Living-off-the-land (LOLBas) attacks use legitimate Windows binaries to perform malicious actions. Hunt hypothesis: 'Are any LOLBas binaries (certutil.exe, bitsadmin.exe, mshta.exe, regsvr32.exe) executing with command line arguments associated with download or remote execution?' EDR query pattern (CrowdStrike Event Search): event_simpleName=ProcessRollup2 ImageFileName IN ('*\certutil.exe', '*\bitsadmin.exe', '*\mshta.exe') CommandLine='*http*' | stats count by ComputerName, ImageFileName, CommandLine. Legitimate certutil.exe executes for certificate operations without HTTP URLs — HTTP URLs in certutil.exe arguments indicate download-and-execute behavior.

SIEM Windows Event Log: detecting lateral movement via PsExec patterns

PsExec and similar lateral movement tools create a characteristic Windows Event Log pattern: Event 7045 (service installed) with service name 'PSEXESVC' or similar, followed by Event 4624 (logon) with logon type 3 (network), from the same source IP. Hunt query (Splunk): index=windows (EventCode=7045 ServiceName='PSEXESVC') OR (EventCode=4624 Logon_Type=3) | transaction host maxspan=5m | where eventcount>1. Cross-reference service installation events with logon events on the same host within 5 minutes to identify PsExec execution chains.

Network flow data: detecting C2 beacon patterns

C2 malware communicates at regular intervals (beaconing). Hunt hypothesis: 'Are any internal hosts making regular-interval outbound connections to external IPs that could indicate C2 beaconing?' Zeek/Bro conn.log hunt (command line): zeek-cut id.orig_h id.resp_h orig_bytes duration < conn.log | awk '{print $1, $2}' | sort | uniq -c | sort -rn | head 50 — then filter for internal-to-external communications occurring more than 100 times per day. A host connecting to the same external IP 288 times in 24 hours (every 5 minutes) is beaconing. Cross-reference with IP reputation to prioritize investigation.

DNS logs: detecting domain generation algorithm (DGA) C2

DGA malware generates pseudo-random domain names for C2, making blocklists ineffective. Hunt hypothesis: 'Are any hosts querying domains with high entropy (random-looking character distribution) consistent with DGA?' Query DNS logs for domains with: length > 12 characters, high character entropy (many different characters without common English word patterns), and NX (non-existent) response codes (DGA domains often do not have DNS responses because the matching C2 server is not running). Splunk hunt: index=dns answer=NXDOMAIN | eval length=len(query) | where length>12 | eval entropy=... | where entropy>3.5 | stats count by src, query | sort -count.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Operationalizing threat hunting: program structure

Ad hoc hunting by individual analysts is better than no hunting, but a structured program delivers compounding returns that individual efforts cannot match. A structured program tracks hypothesis coverage so hunts are not repeated without new context, measures conversion rates to ensure hunts produce lasting detection improvements, and aligns the hunt backlog with current threat intelligence so that the highest-priority gaps are addressed first. Two operational elements drive program effectiveness: a defined hunt cadence with assigned hunters, and a measurement framework that quantifies progress. Without these, hunting remains a reactive activity triggered by incidents rather than a proactive function that reduces attacker dwell time systematically.

Hunt cadence and assignment

Define a regular hunt cadence: one or two structured hunts per week for teams with dedicated resources, one per sprint for teams where hunting is a secondary responsibility. Assign hunts in advance so hunters can prepare data sources and baseline before the hunt session. Track completed hunts in a hunt log: hypothesis, data sources, query, result (confirmed, refuted, indeterminate), detection rules created, and incidents opened. The hunt log prevents repeating the same hypothesis without new context and provides a coverage map of investigated techniques.

Measuring hunt program effectiveness

Key metrics for threat hunting programs: Mean Time to Hypothesize (how long from threat intelligence receipt to hunt execution), Detection Rule Conversion Rate (percentage of completed hunts that produce a new or improved detection rule — target above 80%), True Positive Rate (percentage of hunts that find actual attacker activity — provides input on hypothesis quality), and MITRE ATT&CK Coverage Growth (percentage of ATT&CK techniques with automated detection coverage, tracked quarterly). A hunt program with low rule conversion rate is generating hypotheses that cannot be automated — these need investigation to determine whether the technique is undetectable in available telemetry or the query needs refinement.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

The bottom line

Threat hunting converts attacker dwell time from months to days by finding attacker activity before automated detections fire. The hypothesis-driven methodology structures hunting as a systematic process: form a testable hypothesis, identify the data source, execute the query, investigate leads, and convert findings to detection rules. MITRE ATT&CK gap analysis, sector-specific threat intelligence, and statistical anomaly detection provide the hypothesis backlog. The cumulative output of a threat hunting program is a continuously improving detection rule set and a shrinking gap between attacker entry and defender awareness.

Frequently asked questions

How is threat hunting different from SIEM alert monitoring?

SIEM alert monitoring is reactive: alerts fire when known-bad patterns are detected. Threat hunting is proactive: analysts investigate the environment for attacker activity that existing detection rules have NOT identified. A monitoring analyst responds to alerts. A threat hunter asks 'what would an attacker look like if they were in our environment right now and our detections had not caught them?' and searches for that. The two are complementary: monitoring provides real-time response to known threats; hunting identifies unknown threats and generates the detection rules that eventually become monitoring alerts.

What skills and tools are required for threat hunting?

Threat hunting requires: familiarity with adversary techniques (MITRE ATT&CK knowledge), proficiency with query languages (Splunk SPL, KQL for Microsoft Sentinel, Sigma rules, CrowdStrike Event Search), knowledge of what normal looks like in your environment (baseline familiarity), and understanding of Windows/Linux system behavior (to distinguish normal system activity from attacker activity). Tools: SIEM for log analysis, EDR console for endpoint telemetry, network flow analysis tools (Zeek logs, NDR), and threat intelligence platforms. A threat hunter with strong query skills and good adversary knowledge is more effective than the most expensive tooling with insufficient operator expertise.

How long should a threat hunting session take?

A hypothesis-driven hunt session for a single hypothesis takes 2-4 hours for an experienced analyst: 30 minutes to review the hypothesis and identify data sources, 30-60 minutes to develop and iterate on the query, 1-2 hours to investigate leads and disposition results, and 30 minutes to document findings and write detection rules. Broader investigation or complex hypotheses may take a full day. Hunt programs that schedule hunters for full-day or multi-day blocks (rather than fragmenting time between hunting and alert response) produce more thorough results. Context switching between reactive alert response and proactive hunting reduces the quality of both.

Sources & references

Free resources

Free download

Critical CVE Reference Card 2025–2026

25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.

Free download

Ransomware Incident Response Playbook

Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.

Free newsletter

Get threat intel before your inbox does.

50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.

Unsubscribe anytime. We never sell your data.

Author

Eric BangCISSP

Founder & Cybersecurity Evangelist, Decryption Digest

Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.

View profile →LinkedIn

Back to all briefings

Subscribe for Updates

threat hunting methodology hypothesis-driven hunting proactive threat hunting threat hunting SIEM threat hunting EDR MITRE ATT&CK threat hunting security operations threat hunting threat hunting 2026

Black Hat Giveaway

Win a $2,495 Black Hat pass.

Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.

Threat Hunting: A Hypothesis-Driven Methodology for Finding Attackers in Your Environment

The hypothesis-driven hunt cycle

Hypothesis sources: where hunting targets come from

Practical hunt queries by data source

Operationalizing threat hunting: program structure

The bottom line

Frequently asked questions

How is threat hunting different from SIEM alert monitoring?

What skills and tools are required for threat hunting?

How long should a threat hunting session take?

Sources & references

Critical CVE Reference Card 2025–2026

Ransomware Incident Response Playbook

Get threat intel before your inbox does.

Subscribe to enter the giveaway