Hypothesis Generation

What Makes a Good Hypothesis?

A hypothesis is a specific, testable statement about adversary behavior in your environment. It is not a concern, not a vague worry, and not a repeat of a problem statement. It names the technique, the expected evidence, and the scope of investigation.

Compare these two statements:

• "There might be malware somewhere on our network."
• "An attacker used PowerShell remoting (T1021.006) to move laterally from workstations to servers, generating WinRM connection logs (Event 4624 Type 3 from PowerShell.exe) and script block logs (Event 4104) on destination hosts in the last 30 days."

The first is a concern. The second is a hypothesis. You can write a query to test the second one. You cannot write a query to test the first.

Four qualities make a hypothesis ready to hunt:

• Specific: Names a technique and describes its expected behavioral signature. Testable with available data.
• Actionable: A query or set of queries can be written immediately to investigate it.
• Bounded: Defines a scope (systems, time window, data sources). Prevents runaway scope creep during execution.
• ATT&CK-anchored: Tied to a specific technique or sub-technique. This connects the hypothesis to known actor behavior, known data sources, and known detection guidance.

Where Hypotheses Come From

Hunters often stall at hypothesis generation because they treat it as creative work. It is not. Hypotheses come from structured inputs: threat intelligence, the ATT&CK framework, anomalies in your own data, and situational context from your organization. Each source type produces a different kind of hypothesis with different reliability and urgency characteristics.

Prioritize in this order: Intel-Driven first (real, attributed threat to your industry), Situational second (business context makes specific attack types more likely), TTP-Driven third (systematic coverage improvement), Anomaly-Driven fourth (data signals that may or may not be threats).

CrowdStrike OverWatch tracks over 140 named adversary groups. Their hunt team knows which groups target which industry verticals and uses that context to prioritize which hypotheses are relevant each week. You may not have that intelligence depth, but the principle scales: use what you know about who targets organizations like yours to bias your hypothesis backlog toward the most relevant threats.

The ABLE Framework

ABLE is the hypothesis structuring model from the PEAK framework (developed by Splunk SURGe). It forces you to answer four questions before writing a single query: Actor, Behavior, Location, Evidence. If you cannot answer all four, the hypothesis is not ready.

Actor:    [Named group | General category | Unknown advanced]
Behavior: [ATT&CK T####.### + sub-technique name + specific action description]
Location: [Platform | Network segment | Identity layer | Host group]
Evidence: [Log source | Event IDs | Artifact types | Specific fields and expected values]

ATT&CK as a Hypothesis Source

Every ATT&CK technique page is a structured hypothesis seed. It tells you who uses the technique, how it works, what artifacts it leaves, what logs you need, and what controls reduce its effectiveness. A hunter who knows how to extract that information can generate dozens of well-formed hypotheses from a single ATT&CK session.

How to read a technique page for hunting:

• Procedure Examples: Real-world actor usage. This is the Actor field in ABLE. It also shows you specific implementation details that inform your query, such as the exact flags or file paths an actor uses.
• Detection Section: ATT&CK's recommended detection guidance. Translate this directly into query logic. It is the starting point for your Evidence field.
• Data Sources: The log sources required to detect this technique. If you do not have them, you cannot hunt it. Document the gap.
• Mitigations: Controls that reduce the technique's effectiveness. Useful context: if you have the mitigation deployed, factor that into your hypothesis scope.

Red Canary analyzed telemetry from 1,700 organizations covering 305 petabytes of data and 329 billion records per day. Across five years of analysis, the same techniques appear consistently in the top detections, comprising approximately 46% of all confirmed threats. These are your highest-priority hypothesis sources because they are what attackers actually use, not just what threat reports discuss theoretically.

Attackers chain techniques in predictable patterns. A single hunt rarely covers a full attack chain, but understanding the chains tells you which techniques to prioritize and what to pivot to when you find one. Three common chains worth building hypothesis pairs around:

Prioritizing Your Hunt Backlog

A healthy hunt program generates hypotheses faster than it can execute them. That is a good problem to have, but it requires a disciplined prioritization system. Without one, hunters default to the most interesting hypothesis rather than the most important one. Interesting and important are not the same.

A simple four-factor scoring matrix prevents that bias. Score each hypothesis from 0-3 on each factor. Max total: 12. Hunt the highest scores first.

Treat your hunt backlog like a Kanban board: Backlog (scored, not yet scheduled), Planned (assigned to a sprint or analyst), In Progress (hunt running), Complete (documented), and New Detections Created (rules or alerts derived from findings). The last stage is critical. A hunt that does not produce a detection rule or a documented data gap has not fully closed.

Converting Threat Intel to Hypotheses

Threat reports are dense and often written for intelligence consumers, not hunters. The skill is extracting the operational content: which techniques were used, in which sequence, with which tools, leaving which artifacts. Then translating each technique into an ABLE-structured hypothesis.

From that single report, extract five distinct hypotheses:

Hypothesis 4 (comsvcs.dll LSASS dump) directly translates into a Sigma rule that any SIEM can consume:

title: Potential LSASS Memory Dump via comsvcs.dll
id: e1a3b5c2-f4d6-4e89-a0b2-c3d5e7f90123
status: experimental
description: Detects LSASS memory dump using comsvcs.dll MiniDump function,
  common in credential theft operations. Observed in multiple ransomware
  pre-deployment and APT intrusion chains.
author: H3AD-LEARN
date: 2026/06/02
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith: '\rundll32.exe'
  selection_cmd:
    CommandLine|contains|all:
      - 'comsvcs'
      - 'MiniDump'
      - 'lsass'
  condition: selection_img and selection_cmd
falsepositives:
  - Legitimate memory diagnostics tools (verify process tree and initiating user)
level: critical
tags:
  - attack.credential_access
  - attack.t1003.001

Common Mistakes in Hypothesis Generation

Most hypothesis failures fall into five patterns. Recognizing them before you start saves hours of wasted hunt time.

The confirmation bias mistake is the hardest to self-diagnose. The fix is structural: before executing any hunt, write down the conditions that would prove the hypothesis false. If your only planned queries are designed to confirm your suspicion, add at least one query that would surface contrary evidence. This is the same rigor applied in scientific investigation and it applies directly to adversary hunting.