Hypothesis-driven threat hunting

What this companion is for

This guide assumes you have a hypothesis in hand and need to execute it systematically. Your hunt program exists, you have access to telemetry platforms, and you can write or modify queries in at least one query language. This article walks through single-hunt execution mechanics — the discipline that distinguishes hypothesis-driven hunting from exploratory searching.

Hypothesis-driven hunting operates inside the four-stage framework from THREAT-HUNT-001: hypothesis statement, telemetry requirement, execution, and outcome interpretation. This companion focuses on practitioner mechanics within that structure. You leave with concrete steps for each stage and the four failure modes that compromise hunt outcomes.

Drafting the hypothesis statement

The hypothesis statement contains four required components: behavior (what specifically the adversary does), scope (which assets, identities, or systems the behavior touches), time window (over what period the behavior manifests), and expected evidence (what would prove the hypothesis true or false). Vague hypotheses cannot be disproven, which makes them searches rather than hunts.

Consider this example: "Adversaries use PowerShell remoting to move laterally between domain-joined Windows systems in the finance network segment, establishing persistent sessions that would generate WinRM connection events, PowerShell execution logs, and authentication records across multiple systems within a 24-hour window." The behavior names PowerShell remoting for lateral movement. The scope targets finance network systems. The time window spans 24 hours. The expected evidence specifies WinRM events, PowerShell logs, and authentication records.

When using MITRE ATT&CK techniques as hypothesis sources, specify the sub-technique or procedure variant the hunt tests for — technique-level hypotheses are typically too broad to disprove (Source: attack.mitre.org). "Test for T1021 Remote Services" becomes "Test for T1021.006 Windows Remote Management with PowerShell session establishment targeting cross-subnet movement in finance systems."

The hypothesis must be falsifiable. "Look for suspicious PowerShell activity" cannot be disproven because "suspicious" lacks operational definition. "PowerShell remoting sessions from finance workstations to domain controllers outside normal business hours" can be disproven if the search finds no such sessions and the telemetry coverage is confirmed present.

Specifying the required telemetry

Before executing queries, confirm that required telemetry sources exist, contain the necessary fields, and cover the specified time window. The hunt depends on specific log types (Windows Event Logs, EDR process telemetry, network flow data), required fields (process command lines, source/destination IPs, authentication event types), and sufficient retention periods.

For the PowerShell remoting example, required sources include Windows Event Logs (Event IDs 4624, 4648, 4672), PowerShell operational logs (Event ID 4103, 4104), WinRM logs (Event IDs 6, 169), and EDR process creation events. Required fields include logon type, source network address, process command line, parent process name, and target system name. The retention window must cover the specified 24-hour period plus sufficient lookback time.

The critical verification step: query each required source for recent data and confirm the essential fields are populated. If Windows Event Log 4624 exists but Source Network Address is consistently null, the hunt cannot test for cross-system movement. Document telemetry gaps immediately — they represent exposure findings regardless of the hunt outcome.

Test queries confirm telemetry presence: "Show me PowerShell process creation events from the last hour" validates EDR coverage. "Show me WinRM connection events from finance subnet systems in the last 24 hours" validates network telemetry. Empty results may indicate either no activity or missing telemetry — the hunt cannot proceed until this distinction is confirmed.

Executing the search

Hunt execution requires multiple query pivots, not a single search against the primary signature. The search sequence tests the hypothesis at four pivot points: primary signature (direct evidence of the behavior), precursor signals (setup activity), artifact trails (residue left behind), and correlation pivots (related activity that would accompany the behavior).

The primary signature query searches for the core behavior: PowerShell remoting sessions between finance systems. Logic pattern/pseudocode — validate for your platform:

process_events
| where process_name contains "powershell.exe"
| where command_line contains "-ComputerName" or command_line contains "Enter-PSSession"
| where source_network in finance_subnet_range
| where destination_network != source_network

Precursor signals identify setup activity: PowerShell module imports, WinRM service configuration, or credential enumeration that would precede remote sessions. Artifact trails search for session remnants: PowerShell history files, WinRM logs showing established connections, or authentication events showing interactive logons from PowerShell processes.

Correlation pivots identify related activity: concurrent file access across systems, privilege escalation events from PowerShell processes, or network connections from PowerShell sessions to additional systems. Single-query hunts miss the behavioral context that distinguishes legitimate administration from adversary activity.

Interpreting the outcome

Hunt outcomes fall into four types from THREAT-HUNT-001: positive finding, negative confirmation, evidence gap, or hypothesis revision. Each outcome requires different disposition and follow-up actions.

Positive finding: the search identifies behavior matching the hypothesis. PowerShell remoting sessions from finance workstations to domain controllers outside business hours, with command-line evidence of credential dumping and lateral movement artifacts. Route immediately to incident response. Document the specific indicators, affected systems, and timeline for IR handoff.

Negative confirmation: the search finds no evidence of the behavior, and telemetry coverage was sufficient to detect it if present. All required log sources contained data for the specified time window, essential fields were populated, and the query logic correctly identified the expected signatures. The negative finding confirms the behavior is not present in the environment during the tested period.

Evidence gap: required telemetry was missing, incomplete, or insufficient to test the hypothesis. Windows PowerShell operational logging disabled on finance systems means the hunt cannot confirm or deny PowerShell remoting activity. The gap itself becomes a finding for exposure management — the organization cannot detect the tested attack path with current telemetry.

Hypothesis revision: search results are ambiguous or suggest the original hypothesis needs refinement. PowerShell remoting activity exists but appears limited to legitimate administrative sessions. The revised hypothesis might test for PowerShell remoting combined with credential access techniques or focus on after-hours activity patterns.

The four execution time failure modes

Hypothesis too vague: "Look for lateral movement" cannot be disproven because it lacks operational specificity. The hunt cannot conclude because no set of query results would falsify the hypothesis. Fix: name the specific technique, sub-technique, target scope, and expected evidence signatures.

Telemetry assumed but absent: The practitioner writes queries assuming required data exists, finds empty results, and reports negative confirmation without verifying telemetry presence. PowerShell operational logging may be disabled, making "no PowerShell evidence" meaningless. Fix: confirm telemetry coverage and field population before executing searches.

Search-without-pivots: The practitioner runs one query against the primary signature, accepts empty results as negative confirmation, and skips precursor, artifact, and correlation searches. This pattern misses behavioral context and reduces hunts to signature-based detection. Fix: define and execute all four pivot types before concluding.

Outcome-without-disposition: The hunt concludes but results are not routed appropriately. Positive findings remain in hunt notes without IR handoff. Negative confirmations do not feed detection engineering. Evidence gaps are not escalated to exposure management. Fix: every outcome must have defined disposition and documented handoff.

Handoff and documentation

Document the complete hunt execution: hypothesis statement, required telemetry sources and fields, query logic for each pivot point, result summary, and outcome interpretation. The documentation enables hunt reproducibility and feeds the program knowledge base from THREAT-HUNT-002.

Route outcomes to appropriate teams: positive findings to incident response with specific indicators and timeline; negative confirmations to detection engineering for potential rule development; evidence gaps to exposure management for telemetry improvement; hypothesis revisions back to hunt backlog for refinement.

The hunt's value persists beyond its immediate outcome. Negative confirmations that demonstrate the environment can detect specific attack patterns contribute to detection coverage mapping. Evidence gaps that identify telemetry blind spots inform security architecture decisions. Hypothesis revisions that refine behavioral assumptions improve future hunt targeting.

Sources