Planning a Threat Hunt

Author: Roger C.B. Johnsen

Introduction

The previous chapter described how to start and grow a threat hunting programme. This chapter moves one level down: how to plan a single hunt.

A threat hunting programme gives you the capability. A hunt plan turns that capability into a specific investigation.

That distinction matters.

A hunt plan is not a project plan. It is not a long document written to satisfy process requirements. It is the bridge between a hypothesis and an investigation. It explains what the team is trying to find, why it matters, where to look, how to test it, how to validate the result and what useful output may come from the work. A hunt based on “let us just look around” may occasionally find something interesting, but it is difficult to repeat, review or improve. A structured hunt plan does not remove creativity. It gives creativity a shape.

A threat hunt should be structured enough that someone else can understand the reasoning, but flexible enough that the hunter can follow the evidence.

– Roger Johnsen

What a Hunt Plan Is

A hunt plan is a practical working document. It should help the hunter move from an idea to an executable investigation. It should also help someone else understand what was tested afterwards.

At minimum, a hunt plan should answer:

A hunt plan should be short enough to use, but clear enough to survive review. If the plan cannot explain what the hunt is testing, the hunt is probably not ready.

Start With the Question

A hunt usually starts with a question. The question may come from:

• a SOC observation
• a recurring alert pattern
• a recent incident
• threat intelligence
• a vulnerability or exposure
• a detection gap
• a red team or purple team finding
• a new technique described in public reporting
• uncertainty about whether a behaviour is visible in the environment

Examples:

• Can we identify Office applications spawning command interpreters on ordinary user workstations?
• Do we have visibility into suspicious PowerShell activity across managed endpoints?
• Can we detect successful authentication after password spraying behaviour?
• Are administrative tools being used from systems where they are not expected?

The question does not need to be complicated. It needs to be useful. A weak question is:

Are there attackers in the environment?

That may be what the organisation ultimately cares about, but it is too broad for a single hunt. A better question is:

Can we identify user workstations where Office applications spawned PowerShell, cmd.exe, wscript.exe or similar interpreters during the last 30 days?

That question can be tested.

Define Scope and Boundaries

Scope is what keeps the hunt from becoming endless. A hunt should define what is included and what is not included. This is not bureaucracy. It is how the team prevents a good question from turning into an uncontrolled investigation. Scope may include:

The hunt should also define boundaries. For example:

This hunt looks for suspicious Office-spawned command interpreters on managed Windows workstations. It does not attempt full malware analysis, user forensics or incident response. Confirmed suspicious activity will be escalated.

That kind of boundary is useful. It protects the hunt from becoming everything at once.

Turn the Hypothesis Into Observable Behaviour

A hypothesis is useful only when it can be tested against data. A common mistake is to write a hypothesis that sounds good but does not translate into observable behaviour.

Weak hypothesis:

Attackers may be using malware in the environment.

Better hypothesis:

If malicious documents are used for initial execution, Office applications may spawn PowerShell, cmd.exe, wscript.exe or similar interpreters on user workstations.

The second hypothesis gives the hunter something to look for. The next step is to identify observable behaviours:

This is where the hunt becomes practical.

A hypothesis is not useful because it sounds intelligent. It is useful when it can be tested against observable behaviour.

– Roger Johnsen

Identify Required Data Sources

A hunt plan should identify the data needed to test the hypothesis. This is where many hunts fail. The idea may be good, but the required telemetry may not exist, may not be retained long enough, may not be parsed correctly, or may not contain the fields needed to answer the question.

For each data source, ask:

Example for an Office-spawned PowerShell hunt:

If a required data source is missing, the hunt can still be useful. It may become a visibility-gap hunt. That should be documented clearly.

The hypothesis could not be fully tested because unmanaged devices do not provide endpoint process telemetry.

That is not a failure. That is an output.

Decide the Method

The hunt plan should describe how the team will test the hypothesis. This does not need to be overly detailed, but it should be clear enough that another analyst can understand the approach.

Common hunting methods include:

A good plan may combine several methods.

For example:

Search for Office applications spawning command interpreters, baseline frequency across workstations, exclude known packaging hosts, review command-line arguments, and pivot to network connections within five minutes of execution.

That tells the team what to do. It also makes the hunt reviewable.

Prepare Queries, Enrichment and Notes

A hunt plan should prepare the practical material needed for execution. This may include:

• initial queries
• field mappings
• known exclusions
• enrichment sources
• lookup tables
• asset context
• user context
• known administrative tools
• notes from previous hunts
• expected false positives
• triage questions

Do not wait until the hunt is finished to think about documentation. Good notes during the hunt should capture:

This is where many hunts become fragile. The analyst may remember why something was done, but the organisation will not.

The reasoning is part of the hunt. If you do not document it, you lose part of the evidence.

– Roger Johnsen

Execute With Discipline

Execution should follow the plan, but not blindly. The plan gives direction. The data may still force the hunter to adjust.

During execution, the hunter should:

• run the planned queries
• inspect the results
• validate obvious false positives
• pivot when evidence justifies it
• record query changes
• document assumptions
• note gaps or unexpected behaviour
• avoid turning every interesting result into a new hunt

That last point matters. Threat hunting requires curiosity, but curiosity without discipline becomes wandering. If a new lead appears, the team should decide whether it belongs inside the current hunt or should become a separate hypothesis.

Example:

The hunt for Office-spawned PowerShell reveals unusual rundll32 behaviour. If this is not directly connected to the hypothesis, document it as a follow-up hunt instead of derailing the current one.

A disciplined hunt does not ignore interesting findings. It controls them.

Validate Before Concluding

A hunt should not jump from observation to conclusion. Finding a suspicious pattern is not the same as proving malicious activity.

Validation may include:

The hunter should be especially careful with language.

Weak conclusion:

This host was compromised.

Better conclusion:

This host showed rare Office-spawned PowerShell execution followed by outbound connections to an uncommon domain. The activity is inconsistent with observed baseline behaviour and should be escalated for incident response validation.

That is stronger because it separates observation, context and recommended action.

The hunt does not end when something looks suspicious. It ends when the team has tested what the observation can and cannot support.

– Roger Johnsen

Decide the Output

A hunt plan should define what useful output may come from the hunt. Not every hunt ends with an incident. That is normal.

Possible outputs include:

This should be considered during planning, not only after execution. The hunt is more useful when the team knows what kind of improvement it is trying to produce.

If we find suspicious activity, we escalate it.
If we find no suspicious activity, we still document baseline and visibility gaps.
If we find missing data, we create a telemetry improvement request.
If we find repeatable logic, we hand it to detection engineering.

That is how a hunt becomes operationally valuable.

Where AI Can Assist

AI can support threat hunting, but it should not own the reasoning.

Used well, AI can help with:

But every AI-assisted output needs review. AI can hallucinate fields, invent platform behaviour, overstate confidence, produce syntactically plausible but logically weak queries, or turn a weak assumption into a confident conclusion.

A useful rule is:

AI may help draft the plan. The hunter must own the plan.

That means the hunter must verify:

• whether the data exists
• whether the query tests the hypothesis
• whether field names are correct
• whether the logic makes sense
• whether the conclusion is supported
• whether alternative explanations were considered

AI is useful when it helps the hunter think. It is dangerous when it replaces the hunter’s thinking.

Example Hunt Plan

Below is a compact example of a hunt plan.

Example execution notes:

Possible conclusion:

Office-spawned command interpreters are rare on managed workstations. Most observed activity was tied to known packaging work, but one user workstation showed Word spawning encoded PowerShell followed by DNS activity to a rare external domain. This should be escalated for incident response validation. The hunt also identified a visibility gap for unmanaged devices.

Possible outputs:

This is what a small but useful hunt can look like. It starts with one question, one hypothesis and a limited scope. It ends with evidence, context and operational outputs.

What Usually Goes Wrong

Several problems repeat when teams plan threat hunts.

Most of these problems are avoidable. A good hunt plan does not need to be large. It needs to make the reasoning visible.

Working Position for This Book

A threat hunt plan is the bridge between a hypothesis and an investigation. It should not be written to impress anyone. It should be written so the hunt can be executed, reviewed, challenged and turned into useful security work.

A practical hunt plan should define:

Question.
Hypothesis.
Scope.
Observable behaviour.
Required data.
Method.
Validation.
Output.

That is enough to begin. The hunt may still change during execution. That is expected. But when the plan is clear, the team can tell the difference between following the evidence and simply wandering through logs.

A good hunt plan does not make the hunt rigid. It makes the reasoning visible.

– Roger Johnsen

Resources

• MITRE ATT&CK
• MITRE ATT&CK Overview
• CIS Threat Hunting: The Basics
• CIS Threat Intelligence
• Red Canary Threat Hunting Methodology
• NIST Computer Security Incident Handling Guide
• SANS Data Collection Best Practices
• Open Threat Hunting Framework

Revision