Definition

Author: Roger C.B. Johnsen

Introduction

Ask ten people what threat hunting is, and you will probably get ten slightly different answers. One SOC may mean IOC searches. Another may mean detection engineering based on threat intelligence. A vendor may describe it as a platform capability. In newer AI-driven SOC discussions, someone may even claim that threat hunting can be done automatically by an AI agent. Some of those perspectives are useful. Some are incomplete. Some are just old activities with a newer label.

That is why this book needs to start with a definition. Not because one perfect definition exists, but because the rest of the book needs a clear position. When I use the term threat hunting, I do not mean ordinary alert triage with a better title. I do not mean simply searching for known bad indicators. I do not mean detection engineering, although hunting and detection engineering should feed each other.

To me, threat hunting is structured investigation into what existing alerts, dashboards, detections and assumptions may not show. It is proactive, but not random. It is hypothesis-driven, but still grounded in operational reality. A good hunt should test something: a behaviour, an assumption, a blind spot, a visibility gap, or a possible attacker technique. It should also leave something behind: better understanding, better telemetry, better detection logic, better documentation, or better questions.

Definition

Several organisations and researchers have tried to define threat hunting. Cyborg Security, later acquired by Intel 471, provides one useful definition:

Threat hunting is an iterative and proactive process whereby threat hunters seek out anomalous activity, artifacts, and behaviors within an environment with the objective of identifying previously unknown and undetected threats. This definition has two critical components:

Repeatable: A hunt (the commonly accepted term for activity carried out by these teams) has value in its execution, but only for the duration of its execution. Once the hunt is complete, any subsequent malicious activity may remain unidentified. Therefore, hunts need to be carried out in an iterative fashion based on the prevalence of the technique, and the relative risk to the organization.

Threat hunting must be proactive: The objective of threat hunting is, ultimately, to identify previously undetected malicious activity in an environment. This objective is accomplished through a variety of analysis methods, especially those involving behavioral and statistical analysis. This process, however, absolutely does not rely on searching through an environment using atomic indicators of compromise (IOC). That practice belongs strictly to the domain of traditional security operations, not threat hunting.

Source: Cyborg Threat Hunting Framework

That definition captures two important points: threat hunting is proactive, and it must be repeatable enough to have value beyond a single analyst looking at data for a few hours.

My own working definition is:

Threat hunting is a structured and proactive investigation method used to test assumptions, search for suspicious behaviour, identify visibility gaps, and turn observations into better security work.

– Roger Johnsen

That last part matters. If a hunt does not improve understanding, telemetry, detection logic, documentation, response guidance, or future hunting questions, it probably did not leave enough behind.

You might wonder where AI fits into this definition. It does, but as an assisting tool. AI may help suggest hypotheses, draft queries, summarise data, or explain unfamiliar artefacts. It may speed up parts of the work, but it does not remove the need for the underlying craft.

Automation without subject-matter understanding is just a faster way to repeat weak assumptions.

There is also a more direct failure mode: AI can hallucinate certainty. It may generate a plausible explanation, map benign activity to a severe technique, or turn harmless code examples from an RSS article into something that looks like malicious behaviour. If the analyst does not understand the data, the environment, and the question being tested, the result may be a confident but wrong conclusion.

My intention with this book is to show the base knowledge and practical handcraft I believe a threat hunter still needs: how to ask better questions, understand the data, test assumptions, and decide whether the evidence supports the conclusion.

What Threat Hunting Is Not

Threat hunting is often confused with adjacent disciplines. That is understandable, because the same people, tools and datasets may be involved. The difference is in the intent:

These activities can support each other. A hunt may produce detection logic. Threat intelligence may produce a hunt hypothesis. Incident response may trigger follow-up hunts. A SOC alert may become the starting point for a wider investigation.

But they should not be collapsed into the same thing.

A useful rule is this:

If you already know exactly what you are looking for, and you are only checking whether it exists, you are usually not hunting. You are searching.

– Roger Johnsen

That search may still be valuable. It just should not be dressed up as threat hunting.

Why Threat Hunting Matters

Threat hunting matters because security operations are built on assumptions. You assume that important systems are logging correctly. You assume that detections cover the behaviours you care about. You assume that alert names describe what happened. You assume that your telemetry is complete enough to answer the questions you ask of it.

Those assumptions are often wrong. Threat hunting gives you a structured way to test them.

The value is not only that a hunter might find an attacker. That can happen, and it is obviously important when it does. But a more common and still valuable outcome is that the hunt reveals something about the environment:

• A detection does not cover what people think it covers.
• A log source is missing from important systems.
• A field needed for investigation is not populated.
• A rule catches a symptom, but not the behaviour.
• An alert name leads analysts towards the wrong conclusion.
• A common attacker technique would not be visible with current telemetry.
• A SOC runbook tells analysts what to click, but not what to reason about.

This is why threat hunting is useful even when no compromise is found.

Threat Hunting and SOC Work

SOC analysts and threat hunters often work with the same data, but they usually work from different starting points.

That difference matters. SOC work is often alert-driven, time-sensitive and queue-based. The analyst must make decisions with the information available. Threat hunting should have more room for exploration, comparison, baselining and hypothesis testing. That does not make threat hunting better than SOC analysis. It is simply a different mode of work.

In mature environments, the two should feed each other:

• SOC alerts reveal behaviours worth hunting further.
• Hunts reveal detection gaps.
• Detection engineering turns repeatable hunt logic into monitored content.
• Runbooks and playbooks are updated with what the hunt learned.
• Analysts get better context for future investigations.

The mistake is treating threat hunting as a heroic function sitting above the SOC. It should be part of a feedback loop.

Threat Detection vs Threat Hunting

Threat detection and threat hunting overlap, but they are not the same discipline:

A hunt query is not automatically a detection rule. This is a common mistake. A query that works well during a hunt may be too noisy, too expensive, too context-dependent or too vague to become a production alert. Before hunt logic becomes detection logic, it needs to be refined, tested, tuned and documented.

A good hunt should therefore ask two follow-up questions:

1. Did we learn something useful?
2. Can any part of this be made repeatable?

Sometimes the answer becomes a detection rule. Sometimes it becomes a parser fix, a logging requirement, a dashboard improvement, a runbook update, or a note that says: “we cannot currently see this well enough.”

That is still valuable.

Outputs from Threat Hunts

A threat hunt should produce more than a yes-or-no answer. The exact output depends on the hunt, but useful outcomes often include the following:

Findings

The obvious output is a finding: suspicious or malicious activity that should be investigated, contained or escalated. This is the outcome people tend to think about first, but it is not the only valid outcome.

A finding should be clear about:

• what was observed
• why it matters
• what evidence supports it
• what remains uncertain
• what should happen next

The finding should not rely on an alert name alone. Alert names are not evidence.

Visibility Gaps

A hunt may show that the organisation cannot answer the question it wanted to ask. That is not a failed hunt. It is useful knowledge.

Examples:

• Endpoint telemetry is missing from critical systems.
• DNS logging is incomplete.
• Authentication logs do not contain the fields needed for analysis.
• Proxy logs are retained for too short a period.
• Cloud audit logging is enabled, but not collected centrally.
• The SIEM has the data, but the schema makes the behaviour hard to investigate.

A visibility gap should be documented as clearly as a detection finding. Otherwise the same weak assumption will return later.

Detection Ideas

Many hunts produce detection ideas. These should be written as behaviour, not as vague observations.

The second version is closer to something detection engineering can work with. Detection ideas should include enough detail for someone else to understand the behaviour, test it, and decide whether it can be monitored reliably.

Improved Documentation

A hunt may reveal that analysts do not have enough guidance. That may lead to:

• updated runbooks
• improved playbooks
• better triage notes
• clearer escalation criteria
• better examples of benign and suspicious behaviour
• known false positive patterns
• investigation questions for future analysts

This is not glamorous work, but it matters. Documentation is one of the ways a hunt leaves value behind.

Incident Response Support

Threat hunters can support incident response when the incident requires wider analysis, historical investigation or behaviour-based searching. This does not mean that threat hunters replace incident responders. It means that hunting methods can help answer questions such as:

• Where else has this behaviour occurred?
• Did this activity happen before the known incident window?
• Are there related systems, users or processes?
• Does the attacker behaviour appear elsewhere?
• Can we identify lateral movement, staging, persistence or exfiltration attempts?
• Do our detections cover this behaviour going forward?

During incidents, hunting should be disciplined. It should not become uncontrolled exploration. The questions must be tied to the incident objectives.

Better Questions

Sometimes the most useful output from a hunt is a better question.

The first question is too broad. The second is testable, scoped and closer to operational reality. Threat hunting is partly the discipline of turning vague suspicion into better questions.

Types of Threat Hunting

Threat hunting is often divided into structured and unstructured hunting. That distinction is useful, but it should not be treated as a rigid taxonomy. In practice, hunts often move between these modes.

The method is less important than the discipline.

A hunt should be scoped, documented and explainable. If another analyst cannot understand what was tested and why, the hunt is too dependent on the person who ran it.

Hunting Approaches

The following approaches are common in threat hunting. They are not mutually exclusive.

These approaches are tools for thinking. They do not replace judgement. MITRE ATT&CK, threat intelligence, baselines and statistics can all help shape a hunt, but none of them will tell you what the data means by themselves.

What Usually Goes Wrong

Threat hunting often fails for ordinary reasons. The organisation may call IOC searches “hunting” because it sounds more mature. The SOC may not have time to do anything beyond alert triage. Telemetry may be incomplete. Detection engineers may receive vague hunt findings that cannot be turned into reliable rules. Management may expect every hunt to find an attacker, which creates pressure to overstate weak findings.

Another common problem is that hunts are not written down properly. The analyst remembers what was tested, but nobody else can reproduce the reasoning. Three months later, the same question returns and the organisation has learned very little.

Threat hunting needs curiosity, but curiosity is not enough. It also needs structure. At minimum, a hunt should document:

• the question or hypothesis
• the scope
• the data used
• the logic or queries used
• the observations
• the interpretation
• the limitations
• the output
• what should happen next

That is how hunting becomes organisational knowledge instead of personal exploration.

Working Definition for This Book

For the rest of this book, I use the following practical definition:

Threat hunting is the structured investigation of behaviours, assumptions and visibility gaps that may not be covered by existing alerts.

The purpose is not only to find attackers. The purpose is to understand the environment better and improve the security work that follows.

A useful hunt should produce at least one of these:

• a confirmed or suspected finding
• a disproven or refined hypothesis
• a visibility gap
• a detection idea
• a telemetry requirement
• improved documentation
• a better investigation method
• a better question

If the hunt leaves nothing behind, it was probably just browsing logs.

References

Resources and references:

• Threat Hunting vs. Threat Detecting: What’s The Difference?
• Cyborg Security - Threat Hunting Framework
• 50 Threat Hunting Hypothesis Examples
• Protecting the ‘Crown Jewels’ with Threat Hunting
• How to Identify Cyber Critical Systems with a Crown Jewel Analysis
• Cyber Threat Hunting: Types, Methodologies, Best Practices
• SOC Analyst vs Threat Hunter
• What is Cyber Threat Hunting?
• IOA vs IOC
• What is Proactive Cyber Threat Hunting and Why Should You Do It?
• Corelight Threat Hunting Guide
• Security Analytics Use Cases for Threat Hunting
• Threat Hunting Use Case: Web Proxy
• Threat Hunting with MITRE’s ATT&CK Framework: Part 1
• Threat Hunting with MITRE’s ATT&CK Framework Part 2 – Advanced Use Cases
• Cyber Wardog Lab by Roberto Rodriguez
• 10 Benefits of Threat Hunting
• Flavio Queiro on what Threat Hunting isn’t

Revision