Creating Hypotheses

Author: Roger C.B. Johnsen

Introduction

The previous chapters introduced hypotheses as part of threat hunting methodology. This chapter goes deeper. It focuses on how to create hypotheses that are specific, testable, relevant and useful enough to drive an actual hunt.

Threat hunting relies on more than intuition and experience. Those things matter, but they are not enough. A hunt needs a structured question. It needs a reason. It needs observable behaviour. It needs data that can support or weaken the idea being tested.

That is where the hypothesis comes in.

• A good hypothesis gives the hunt direction. It does not prove anything by itself. It does not guarantee that the team will find malicious activity. It simply gives the hunter a clear statement to test against evidence.
• A weak hypothesis sends the hunter browsing through logs.
• A strong hypothesis tells the hunter what evidence would matter.

A hypothesis is not a suspicion with better wording. It is a statement you can test against evidence.

– Roger Johnsen

What a Threat Hunting Hypothesis Is

A threat hunting hypothesis is a testable statement about behaviour that may indicate malicious activity, security weakness, detection failure, visibility gap or operational risk. It usually combines several elements:

A hypothesis does not need to be complicated. It needs to be clear enough to test.

Weak example:

Attackers may be present in the network.

Better example:

If attackers gained initial access through malicious documents, Office applications may spawn PowerShell, cmd.exe, wscript.exe or similar interpreters on user workstations.

The second example gives the hunter something to do. It points towards process telemetry, parent-child relationships, command-line arguments, device context and user context. That is what makes it useful. A hypothesis should help the hunter move from a concern to an investigation.

What a Hypothesis Is Not

It is useful to be clear about what a hypothesis is not:

• A hypothesis is not the same as an alert. An alert says that something matched existing logic. A hypothesis asks whether something may be happening that the existing logic does not fully cover.
• A hypothesis is not the same as an IOC. An IOC can be a useful starting point, but an IOC search is usually narrow. A hypothesis should move towards behaviour and context.
• A hypothesis is not the same as a threat report. A report may inspire the hunt, but the hunter still needs to translate the report into local telemetry and observable behaviour.
• A hypothesis is not the same as a vague concern.

Concern:

We are worried about ransomware.

That may be a valid concern, but it is not yet a hunting hypothesis. A better version could be:

If ransomware operators are preparing for encryption, we may observe unusual archive creation, privilege escalation attempts, lateral movement, backup access or security tool tampering before encryption begins.

That version is still broad, but it has become testable. It points towards behaviours that can be scoped, searched and validated.

A hypothesis should not only sound plausible. It should make the next analytical step clearer.

Where Hypotheses Come From

Threat hunting hypotheses can come from many sources. They do not all start with threat intelligence. Some of the best hypotheses come from local observations, weak detections, strange baseline behaviour or questions raised during incident response.

Useful sources include:

The source matters less than the translation. Threat intelligence, for example, is not automatically a hypothesis. A report may describe an actor using PowerShell, scheduled tasks, cloud consent abuse or remote services. The hunter still has to ask:

What would this behaviour look like in our environment?

and:

Do we have the data needed to test it?

Threat intelligence gives you ideas. Telemetry decides whether those ideas can be tested.

– Roger Johnsen

From Input to Hypothesis

The practical work is turning raw input into a testable hypothesis. A simple flow is:

Input → Local relevance → Observable behaviour → Required data → Hypothesis

Example:

This translation step is important. Without it, the team may simply copy ideas from reports into hunts without checking whether they are relevant, observable or testable.

Another example:

The quality of the hypothesis depends on how well the input is translated into behaviour.

Making the Hypothesis Testable

A hypothesis should be testable. That means the hunter should be able to define what evidence would support it, what evidence would weaken it and what data is needed.

Ask these questions:

A testable hypothesis often contains three things:

If [condition or threat behaviour], then [observable activity] may appear in [specific scope or data].

Example:

If attackers are using valid accounts for lateral movement, then we may observe administrative logons from unusual source systems to servers where those users do not normally authenticate.

This is testable because it points towards:

• authentication logs
• source and destination systems
• user roles
• administrative logon types
• baseline behaviour
• time window
• exceptions
• validation paths

A hypothesis does not have to be perfect. It has to be good enough to test.

Using SMART Without Losing the Point

SMART can help refine hunting hypotheses, but it should not turn the hunt into management theatre.

SMART means:

Weak version:

We will look for suspicious logins.

SMART-er version:

During the last 30 days, we will identify successful logins to privileged accounts from unfamiliar countries, rare autonomous systems or unmanaged devices, and compare them against known travel, VPN usage and administrative patterns.

This is better because it defines:

• time window
• account population
• observable behaviour
• data needed
• validation context

SMART should sharpen the hunt, not bury it in paperwork.

SMART is useful when it makes the hypothesis clearer. It is useless when it turns hunting into form-filling.

– Roger Johnsen

Weak and Strong Hypotheses

A strong hypothesis is not necessarily longer. It is more testable.

The stronger versions do not claim that an attack is happening. They describe what evidence may support the idea. That is the point. A strong hypothesis should help the hunter decide:

• where to look
• what to look for
• what context matters
• what would be normal
• what would be suspicious
• what to do with the result

A weak hypothesis often produces open-ended searching. A strong hypothesis produces directed investigation.

Using MITRE ATT&CK as Structure

MITRE ATT&CK is useful for hypothesis creation because it provides a structured vocabulary for adversary behaviour. It can help the hunter ask:

• Which tactic are we concerned about?
• Which technique may be relevant?
• What behaviour would that technique create?
• Which data sources could show it?
• Which detections do we already have?
• What might our existing detections miss?

ATT&CK should be used as structure, not as a substitute for thinking. A technique page may describe adversary behaviour, but it does not automatically tell you what is relevant in your environment. The hunter still needs to translate the technique into local systems, logs and context.

Example:

The useful movement is:

ATT&CK technique → local behaviour → data source → hypothesis → hunt plan

Not:

ATT&CK technique → generic search → conclusion

Example Hypotheses

Below are examples of threat hunting hypotheses inspired by common ATT&CK areas. They are intentionally written as hypotheses, not conclusions.

Initial Access: Phishing

Execution: PowerShell

Persistence: Scheduled Tasks

Credential Access: Credential Dumping

Lateral Movement: Remote Services

Exfiltration: Unusual Data Movement

These examples are not meant to be copied blindly. They are templates for thinking. Each organisation must adapt the hypothesis to its own systems, telemetry, business context and threat landscape.

What Usually Goes Wrong

Several problems appear repeatedly when teams create hunting hypotheses.

Most weak hypotheses fail because they do not connect the idea to observable behaviour. The fix is usually simple:

Make the behaviour visible.
Make the scope clear.
Make the data explicit.
Make the conclusion testable.

Working Position for This Book

A threat hunting hypothesis is a practical tool. It should not be written to sound impressive. It should be written to guide investigation.

A good hypothesis connects:

Threat idea.
Local relevance.
Observable behaviour.
Data source.
Scope.
Validation.
Output.

That connection is what makes hypothesis-driven hunting useful. The hypothesis does not need to prove that an attacker is present. It needs to help the hunter test whether a behaviour exists, whether it matters and what should happen next.

A good hypothesis gives the hunt direction. A great hypothesis also tells you what evidence would change your mind.

– Roger Johnsen

Resources

• MITRE ATT&CK
• MITRE ATT&CK Overview
• SOC Prime: Threat Hunting Hypothesis Examples
• Cyborg Security: 50 Threat Hunting Hypothesis Examples
• Splunk: PEAK Threat Hunting Framework
• Cyborg Security: Art of the Hunt – Building a Threat Hunting Hypothesis List
• SANS Institute Whitepapers on Threat Hunting
• George T. Doran: There’s a S.M.A.R.T. Way to Write Management’s Goals and Objectives

Revision