Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Hypothesis-driven threat hunting is the proactive search for adversary activity that existing alerts have *not* surfaced, structured around a falsifiable statement rather than an open-ended sweep for indicators of compromise. Where IOC matching asks “is this known-bad thing present,” a hunt hypothesis asks “if an adversary used technique X against this environment, what would we expect to see in telemetry Y, and is it there.” This distinction matters because most real intrusions are not caught by signature matches on known bad artifacts — they are caught by a human noticing behavior that is anomalous relative to a hypothesis about how the attack would manifest.
Hunting matters for two reasons beyond finding an active intrusion: it validates detection coverage in a way passive alert review cannot (a hunt that finds nothing but confirms the query and data source both work is still valuable), and it routinely surfaces new patterns that get converted into permanent, automated detections — turning a one-off analyst effort into standing coverage. Mature programs treat every hunt as a detection-engineering input, not a dead-end exercise.
Attack Prerequisites
A hunt is only as good as what feeds it. Before formulating hypotheses, a hunter needs:
- A behavioral baseline — what normal process execution, network egress, and authentication patterns look like for the assets in scope, so anomalies are recognizable.
- Raw, queryable telemetry — EDR process/network events, DNS logs, proxy logs, and authentication logs with enough retention to cover the hunt window; hunts frequently die for lack of the right log source, not lack of a good idea.
- Hypothesis sources — threat intelligence on relevant actor TTPs, ATT&CK coverage-map gaps, anomaly-detection or UEBA output worth investigating manually, and lessons from prior incidents.
- A documented methodology — e.g. TaHiTI (Targeted Hunting integrating Threat Intelligence, developed in the Dutch financial sector) or Sqrrl’s hunting loop, so hunts are repeatable and comparable rather than improvised each time.
- Query tooling — KQL/SPL/EQL fluency and, ideally, a notebook environment (Jupyter) for statistical pivots like stack-counting and outlier detection.
How It Works
Hypotheses generally fall into three categories. Intel-driven hunts start from a specific TTP reported for an actor relevant to your sector (“Group X has been observed using T1218.011 rundll32 to proxy-execute payloads — do we have evidence of that here?”). Situational-awareness / crown-jewel-driven hunts start from what would hurt most if compromised (“what would unauthorized access to the CI/CD signing keys look like in our telemetry?”) independent of any specific reported campaign. Analytics-driven hunts start from a statistical anomaly already surfaced by a model or stack-count (“this one host issued ten times the normal volume of NXDOMAIN — why?”) and work backward to an explanation.
Whatever the source, a usable hypothesis has a specific structure: *If an adversary did [specific behavior], then [specific data source] would show [specific, observable pattern]*. “Hunt for malware” is not a hypothesis; “if an adversary is proxy-executing payloads via rundll32, then Sysmon Event 1 would show rundll32.exe with a command line containing a URL or an unusual export name, spawned from a non-standard parent” is. The hunting loop (per Sqrrl’s model, still the clearest public articulation even though the product was discontinued after AWS’s acquisition) is: Trigger → Hypothesis → Investigate with tools/techniques → Uncover new patterns and TTPs → Inform and enrich analytics → Automate the detection → repeat.
A negative result — the hypothesis was tested and nothing was found — is still a valid, documentable outcome. It confirms the data source is queryable and the pattern genuinely doesn’t occur, which is meaningfully different from never having looked. Programs that only document hunts which “found something” systematically undercount their actual coverage validation work.
Practical Example / Configuration
Hypothesis: *Adversaries are proxy-executing remote payloads through signed LOLBins (rundll32.exe, regsvr32.exe, mshta.exe — ATT&CK T1218) rather than dropping an unsigned binary, to evade allow-listing. If true, we’d see one of these binaries make an outbound network connection within seconds of process start, with a command line that doesn’t match a known internal software deployment pattern.*
KQL to test it (Microsoft Defender/Sentinel schema — join process creation to the network connection it spawned):
let lolbins = dynamic(["rundll32.exe","regsvr32.exe","mshta.exe"]);
DeviceProcessEvents
| where FileName in~ (lolbins)
| where ProcessCommandLine has_any ("http://", "https://", ".sct", "scrobj")
| project DeviceId, TimeGenerated, FileName, ProcessCommandLine,
InitiatingProcessFileName, ProcessId
| join kind=inner (
DeviceNetworkEvents
| where ActionType == "ConnectionSuccess"
| project DeviceId, NetTimeGenerated=TimeGenerated, RemoteIP, RemoteUrl, ProcessId
) on DeviceId, ProcessId
| where (NetTimeGenerated - TimeGenerated) between (0min .. 1min)
| project TimeGenerated, DeviceId, FileName, ProcessCommandLine, RemoteUrl, RemoteIP
| order by TimeGenerated desc
Walkthrough / Exploitation
Running the hunt loop end to end for the hypothesis above:
1. Scope: map the hypothesis to ATT&CK T1218 (System Binary Proxy Execution)
and note it against the coverage map — is this currently "none" or
"partial"? That determines urgency.
2. Data source check: confirm DeviceProcessEvents and DeviceNetworkEvents
both have >=30 days retention for the asset population in scope.
3. Run the KQL query above over a rolling 30-day window; expect noise from
legitimate software updaters using regsvr32 for COM registration.
4. Triage hits: pivot on InitiatingProcessFileName (unexpected parent, e.g.
winword.exe or an Office child spawning mshta.exe, is high-signal) and on
RemoteUrl reputation/newly-registered-domain status.
5. Document the hunt regardless of outcome: hypothesis, query, time range,
hit count, disposition of each hit, and whether the data source itself
behaved as expected.
6. If a true positive or a durable pattern is confirmed, convert the query
into a Sigma rule with the same ATT&CK tag and hand it to detection
engineering for the standing pipeline, closing the loop.
7. Update the coverage map: T1218 moves from "none"/"partial" to
"covered" once the resulting rule is validated in production.
Note: Hypotheses that are too broad (“hunt for malware”) produce unfocused queries and analyst fatigue; hypotheses that are too narrow (“hunt for this exact command line from last year’s incident”) rarely find anything new because a competent adversary varies syntax trivially. Aim for the behavioral middle: specific enough to query, general enough to survive minor variation.
Opsec: Cadence matters as much as content — a hypothesis backlog that never gets revisited goes stale as environments and adversary tradecraft change. Rotate through intel-driven, crown-jewel, and analytics-driven hypotheses on a schedule rather than only hunting reactively after an incident.
Detection and Defense
The output of hunting is only as valuable as how consistently it feeds back into standing detection:
- Convert confirmed gaps into Sigma rules immediately, tagged with the same ATT&CK ID used in the hunt, so the pipeline described in detection-as-code practice picks it up.
- Stack-count for outliers — frequency analysis of process command lines, parent-child pairs, or DNS query volume per host is one of the highest-yield generic hunting techniques and needs no prior intel.
- Seed hypotheses from CAR and ATT&CK data components for techniques the coverage map marks “none,” turning gap analysis directly into a hunt backlog.
- Peer review hunt queries before large-scale runs — a query with an unintended broad filter either misses everything or floods the analyst with noise, wasting the exercise.
- Track negative hunts as coverage-validation evidence in the same system used for the ATT&CK map, not just in a hunter’s personal notes.
Real-World Impact
Hypothesis-driven hunting methodologies like TaHiTI are used across the financial-sector CSIRT community and are taught directly in SANS FOR508 and FOR572 curricula. Mandiant’s annual M-Trends reports have repeatedly noted that a meaningful share of intrusions are self-discovered through proactive activity rather than automated alerting, underscoring that structured hunting finds dwell-time intrusions that signature- and threshold-based detection alone misses, particularly living-off-the-land techniques that individually look like legitimate administration.
Conclusion
Threat hunting earns its place in a detection program by being disciplined, not by being clever guesswork. A good hypothesis is falsifiable, tied to a specific data source and pattern, and documented whether or not it finds anything, and its real payoff is compounding: every hunt either validates existing coverage or produces a new Sigma rule, so a hunting program that consistently closes the loop back into automated detection turns one-off analyst effort into permanent visibility.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments