Threat hunting with hypotheses: plan, query, analyze, and turn findings into detections

A good hypothesis

A hunt starts with a specific, testable statement: “An attacker with access to a workstation may have created persistence through a Run key pointing to a user-writable folder in the last 30 days.” It names a behavior, a place, and a time window, and it implies the data you need.

Sources of hypotheses include threat reports, ATT&CK techniques with weak coverage, recent incidents, and new log sources.

Stacking

Stacking means counting how often each value appears across the environment and looking at the rare end. Persistence entries, service names, parent-child process pairs, and scheduled task actions are good stacking targets: legitimate software appears on many hosts, while unique entries deserve a look.

DeviceRegistryEvents
| where Timestamp > ago(30d)
| where RegistryKey has @"\CurrentVersion\Run" and ActionType == "RegistryValueSet"
| where RegistryValueData has_any (@"\AppData\", @"\Temp\", @"\Users\Public\")
| summarize Hosts = dcount(DeviceName), Example = any(RegistryValueData) by RegistryValueName
| order by Hosts asc

Lab: run a hunt end to end

Pick the Run key hypothesis or a Linux equivalent such as new systemd units in user directories. Write the hypothesis, data needed, query, and expected benign results. Run it against your lab data, stack the results, and investigate the three rarest entries. Write a short hunt report: what you looked for, what you found, gaps in data, and the detection you will create.

Outputs that matter

A hunt is useful even when it finds nothing, as long as it records what was checked and what data was missing. The best outcome is a new automated detection or improved logging, so the same question never has to be answered by hand again.