Threat Hunting: Hypothesis, Data, Evidence
Hypothesis-driven, not alert-driven
Hunting starts from a hypothesis about attacker behavior, usually expressed as a MITRE ATT&CK technique, not from an existing alert. The loop: form a hypothesis, identify the data required, query it, analyze, refine, and feed findings back into detections - a new correlation search or risk rule. A hunt that ends with no detection change usually missed its purpose, and a hunt returning nothing proves only that current data cannot confirm the hypothesis.
Tooling and techniques
Query data models with tstats for speed, sweep indicators with threat intelligence lookups and the threat intel framework, and use ESCU analytics stories for context. Core techniques: statistical baselining of a host or user, stacking (count by field and inspect rare values), clustering, outlier detection, and first-seen/last-seen analysis of processes or parent-child pairs.
Traps
rare and stats count by are not interchangeable - rare reports frequency within the result set, while a sorted aggregation is usually clearer. A missing parent process is not evidence of malice if endpoint logging is incomplete. Hunting is not "run every correlation search". tstats cannot see fields that were never CIM-mapped.
Worked example: hunt living-off-the-land execution with | tstats count from datamodel=Endpoint.Processes where Processes.parent_process_name IN ("winword.exe","excel.exe") by Processes.process_name, Processes.parent_process_name, host, then compare against a 30-day baseline and investigate any pair seen on exactly one host.