Threat Hunting: What It Is, How It Works, and When You Need It

Threat hunting is the deliberate search for threat actors who are already inside your environment and have not triggered a single alert. Detection tooling only catches what someone has already written a rule for, which leaves a gap threat actors work in on purpose. This article covers what threat hunting is, the three methodologies that matter, how a threat hunt runs, and how to tell whether a provider’s hunting is a programme.

Key takeaways

• Threat hunting is the assumption that something has already got through, followed by a deliberate search for it. It starts from a hypothesis rather than an alert.

• It is not a replacement for detection tooling. It exists because detection tooling only catches what someone has already written a rule for.

• Three methodologies cover almost all real hunting: hypothesis-driven, intelligence-driven, and anomaly-driven. Most of the longer lists you will find elsewhere are these three described at different levels of detail.

• Hunting only produces value if findings become detections. A hunt that ends in a report has found something once. A hunt that ends in a new detection rule finds it forever.

What is threat hunting?

Threat hunting is the proactive search for attackers who are already inside an environment and have not triggered an alert.

That definition contains the whole discipline. Detection tooling answers the question “did anything match a known pattern?” Threat hunting answers a different one: “if something got in without matching a pattern, where would it be and what would it look like?”

The distinction matters because of how the two are triggered. Detection is triggered by the environment. Hunting is triggered by a person forming a hypothesis and going to look.

Why alerts are not enough

Every detection rule is a description of an attack somebody has already seen. That makes detection tooling excellent against known techniques and structurally blind to the gap between a new technique appearing and a rule being written for it.

Attackers work in that gap deliberately. Three patterns from our own incident response casework show how:

Legitimate tools instead of malware. In the cases we investigate, malware appears less and less often. Attackers use valid credentials and administration software the organisation already runs, such as TeamViewer or AnyDesk. Endpoint protection has no reason to flag software you licensed yourself.

Identity rather than infrastructure. The majority of incidents we handle are identity related. A stolen session token produces activity that looks like a legitimate user, because to the system it is a legitimate user.

Patience. In one ransomware case we handled, the initial access broker sat in the network for three months without acting. The antivirus did generate detections during that period. They were reviewed and marked as false positives.

That last case is the argument for hunting in a single line. The tooling worked. Nobody went looking.

How is threat hunting different from MDR, detection, and penetration testing?

These four terms get used interchangeably in vendor material, and they are not the same activity.

	Trigger	Question it answers	Timing
Detection	An alert from a rule or signature	Did something match a known pattern?	Continuous, automated
Threat hunting	A human hypothesis	Is something here that no rule would catch?	Periodic, deliberate
Incident response	A confirmed incident	What happened, how far did it get, how do we remove it?	Reactive
Penetration testing	A scheduled engagement	Could someone get in through this system?	Point in time
Red teaming	A scheduled engagement	Would a real attacker reach our crown jewels, and would we notice?	Point in time

Two clarifications worth making explicitly, because both are commonly muddled:

Threat hunting is not part of red teaming. Red teams simulate the attacker. Hunters look for evidence of one. They are opposite sides of the same question, and some published lists of “hunting methodologies” wrongly include adversary emulation. If someone offers you red teaming as a hunting service, they are describing a different engagement with a different output.

Threat hunting is a component of mature MDR, not an alternative to it. MDR gives you the telemetry, the tooling, and the analysts. Hunting is what those analysts do with that telemetry when they are not responding to alerts. Buying hunting without the underlying visibility gives you people with nothing to search.

Why does threat hunting matter?

Dwell time is where cost accumulates

The damage an intrusion causes is largely a function of how long it goes unnoticed. An attacker present for a day has taken what was immediately reachable. An attacker present for three months has mapped the environment, found the backups, and chosen the moment.

In our incident data, dwell time in unmonitored environments is measured in weeks. With managed detection in place it drops to minutes. Hunting closes the remaining gap: the portion of intrusions that produce no alert at all, and would otherwise be discovered by the ransom note.

Every hunt makes the next attack harder to hide

A hunt has two outputs. The finding itself, and the detection logic built from it.

The second is the one that matters over time. A hunt that surfaces an unusual authentication pattern has protected you once. A hunt that converts that pattern into a detection rule has protected you permanently, and protects every other environment the same SOC monitors. This is the strongest argument for hunting inside a shared SOC rather than in isolation.

A threat hunt tells you what your tooling cannot see

Threat hunting produces an uncomfortable but valuable byproduct: a map of your blind spots. Every hunt that cannot be completed because the data is not being collected is a visibility gap you now know about. That finding is often worth more than the hunt’s original objective.

What are the phases of a threat hunt?

A hunt has four phases, and the fourth is the one most often skipped.

Phase	What happens	Output
1. Hypothesis	State a specific, testable proposition about attacker activity in this environment	A question the available data can answer
2. Investigation	Query telemetry across endpoints, identity, network and cloud to test the hypothesis	Confirmed activity, benign explanation, or a visibility gap
3. Response	If activity is confirmed, contain and hand over to incident response	A contained incident
4. Detection engineering	Convert what was learned into a permanent detection rule	Automated coverage for the technique

Phase 1: Forming a hypothesis

A usable hypothesis is specific enough to be wrong. “Are there attackers in our environment?” is not a hypothesis. “An attacker with valid credentials is using a legitimate remote access tool for persistence on servers where our IT team does not normally use one” is.

Three sources produce good hypotheses:

• Adversary behaviour. What techniques do the groups active against your sector actually use? MITRE ATT&CK is the standard reference for structuring this.

• Your own environment. What would an attacker want here, and what path leads to it? Your architecture suggests hunts nobody else would run.

• Recent incidents. Both yours and those published by others. A technique used against a peer organisation is a hypothesis ready to test.

Prioritise by two factors: how likely the technique is against you, and how much damage it would cause if present.

Phase 2: Investigation

The hunt is only as good as the telemetry underneath it. In practice that means:

• Endpoint data for process execution, persistence mechanisms and tool usage

• Identity data for authentication patterns, token issuance and privilege changes, which is where the majority of incidents we handle actually live

• Network data for lateral movement and command-and-control traffic

• Cloud and SaaS audit logs for mailbox rules, application consents and configuration changes

The technique is comparative. Establish what normal looks like for this environment, then look for deviation from it. This is why hunting in an unfamiliar environment is hard and hunting in one you monitor daily is effective. You cannot spot an anomaly without a baseline.

A hunt has three legitimate outcomes, and only one of them is a finding:

1. Confirmed malicious activity. Hand to incident response.

2. A benign explanation. Document it, so the same anomaly does not cost analyst time again.

3. The data does not exist. A visibility gap. Fix the collection, then rerun the hunt.

Phase 3: Response

If a hunt confirms activity, it stops being a hunt and becomes an incident. That transition should be pre-agreed rather than improvised: who is notified, who authorises containment, and at what point the wider crisis process starts.

The temptation at this moment is to remove what you found immediately. Resist it long enough to scope properly. Containing one compromised host while the attacker holds three others gives away that you are watching without removing them.

Phase 4: Detection engineering

This is where hunting either compounds or evaporates.

Every completed hunt should produce one of three artefacts: a new detection rule, a tuning change to an existing rule, or a documented visibility gap with an owner. A hunt programme measured only in findings will run the same hunt repeatedly. A hunt programme measured in detections written gets progressively harder to hide from.

What are the main threat hunting methodologies?

You will find lists of eight or ten methodologies elsewhere. Most are the same three approaches described at different levels of abstraction, or tooling categories misfiled as methods. There are three that genuinely differ, distinguished by where the hunt starts.

Hypothesis-driven hunting

Starts from: a proposition about attacker behaviour, usually structured against MITRE ATT&CK.

How it works: the hunter selects a technique relevant to the organisation’s sector and architecture, then tests whether evidence of it exists in the environment.

Best for: systematic coverage. Because ATT&CK is a finite matrix, this approach lets you track which techniques you have hunted for and which you have not, turning hunting into a measurable programme rather than a series of one-off investigations.

Limitation: it can only find techniques somebody has documented.

Intelligence-driven hunting

Starts from: an external indicator or a specific piece of threat intelligence.

How it works: a new campaign is reported, credentials appear in a leak, or infrastructure associated with a known group is published. The hunter searches historical telemetry for contact with those indicators, including before the intelligence existed.

Best for: speed and retrospective coverage. When a campaign against your sector becomes public, this answers “were we already hit?” within hours.

Limitation: indicators expire quickly. Infrastructure rotates, hashes change. This approach is most valuable in the days after intelligence emerges and decreasingly so afterwards.

Anomaly-driven hunting

Starts from: a deviation from the environment’s own baseline, with no prior theory about what caused it.

How it works: behavioural analytics, statistical comparison and machine learning surface activity that is unusual for this specific organisation. The hunter then investigates whether the anomaly has a benign explanation.

Best for: genuinely novel activity, insider threats, and compromised accounts behaving in ways no rule anticipated. This is the only approach that can find something nobody has ever documented.

Limitation: the highest false-positive rate of the three, and the most dependent on a mature baseline and experienced analysts. Unusual is not the same as malicious, and most unusual things in a business are just business.

Which methodology to use

Mature programmes run all three on different rhythms. Hypothesis-driven hunts on a schedule for systematic coverage. Intelligence-driven hunts reactively when relevant intelligence appears. Anomaly-driven hunting continuously in the background, feeding candidates to analysts.

A note on AI and machine learning: these are not a fourth methodology, they are what makes anomaly-driven hunting viable at scale. Treated as a method in their own right, they produce volume without direction.

What tools do you need for threat hunting?

Tooling matters less than most vendor content suggests. What hunting actually requires is searchable telemetry across four domains, retained long enough to hunt in.

You need visibility into	Typically provided by	What hunting uses it for
Endpoints	EDR	Process execution, persistence, tool usage, historical timeline
Identity	Identity provider logs, ITDR	Authentication anomalies, token issuance, privilege change, consent grants
Network	NDR, firewall and DNS logs	Lateral movement, command-and-control, exfiltration
Cloud and SaaS	Provider audit logs	Mailbox rules, app registrations, configuration change
All of the above, correlated	SIEM or XDR	Cross-domain queries, which is where most hunts actually happen

Two supporting inputs:

Threat intelligence supplies hypotheses and context. Without it, hunting is guided only by what you can imagine. With it, hunts align to what is actually happening in your sector.

Documented playbooks make hunts repeatable and comparable over time. A hunt run differently each time cannot tell you whether your posture is improving.

The three things that matter more than tool selection

Retention. If your telemetry is retained for 30 days, you cannot hunt for the three-month dwell time described earlier. Retention length sets a hard limit on what any hunt can find, and it is the most commonly overlooked constraint.

Identity coverage. If you are collecting extensive firewall logs and little identity telemetry, your visibility is inverted relative to where incidents actually occur. This is worth checking against your own logging today.

People with the time to hunt. Hunting is not something an alert queue does in gaps. It requires analysts with allocated time, environment familiarity, and the authority to investigate a hunch. Tooling without that produces dashboards nobody interrogates.

What does a human hunter contribute that automation cannot?

Automation finds what it was told to look for, faster and at greater scale than any person. That is a genuine advantage and it is also the whole of its contribution.

Hunters bring four things that do not automate.

They form the hypothesis. Every automated detection began as a human idea about how an attack might work. Hunting is that idea generation, done continuously, before the rule exists.

They pivot mid-investigation. A hunt that starts with an unusual login and ends up finding a compromised service account went somewhere no playbook specified. Following a weak signal into unfamiliar territory is judgement, not logic.

They know what your business normally does. Finance sending a payment file at 03:00 is an alert. Finance sending a payment file at 03:00 during month-end close, from a location a colleague mentioned travelling to, is a Tuesday. Context of this kind separates a real finding from a false positive, and it is the hardest thing to encode.

They validate the automation. Models are only as good as their training data, and detection rules drift as environments change. Hunters test whether the automated layer is still working, which is a category of check nothing automated can perform on itself.

The productive framing is not human against machine. It is automation handling volume, hunters handling ambiguity.

How to start hunting if you do not have a hunt programme

Five steps, in order of dependency rather than difficulty.

1. Audit your telemetry and retention first. Establish what you collect across endpoint, identity, network and cloud, and for how long. Every subsequent step is capped by this.

2. Close the identity gap before anything else. If identity telemetry is thin, fix that ahead of adding new tooling. It is where most incidents begin.

3. Run one hypothesis-driven hunt end to end. Pick a single ATT&CK technique relevant to your sector. Complete all four phases, including writing the detection rule. One finished hunt teaches more than a documented strategy.

4. Measure detections written, not hunts run. The metric shapes the behaviour. Counting hunts produces activity, counting detections produces coverage.

5. Decide whether this is yours to build or to buy. A hunt programme needs analysts with allocated time, tooling with adequate retention, and threat intelligence. For most mid-market organisations that is a team you do not have and would struggle to retain. Hunting inside a shared SOC also means every detection built from another environment’s hunt applies to yours.

Questions to ask a provider who offers threat hunting

• Is hunting scheduled and documented, or does it happen when the alert queue is quiet?

• How long is telemetry retained, and can you hunt across the full period?

• What identity telemetry is collected, and what proportion of hunts touch it?

• What happens to a hunt finding afterwards? Ask to see a detection rule that came from one.

• Do detections built from other customers’ hunts apply to our environment?

The fourth question is the most revealing. A provider who cannot show you a detection rule that originated in a hunt is describing an activity, not a programme.

What this means for your organisation

Threat hunting exists because of a structural limit in detection tooling. Rules describe attacks somebody has already seen, and attackers work in the space before the rule is written. No amount of additional tooling closes that gap, because the gap is not caused by insufficient tooling.

What closes it is someone assuming compromise and going to look, on a schedule, with adequate visibility, and converting whatever they find into permanent detection.

The organisations that get value from hunting are not the ones with the most sophisticated platforms. They are the ones who know what their telemetry covers, retain it long enough to be useful, put identity at the centre rather than the edge, and treat every finding as a detection rule waiting to be written.

The alternative is the case described earlier in this article. The tooling generated detections for three months. Nobody went looking. The organisation found out when the ransom note appeared.

See how threat hunting works inside Eye Security’s 24/7 European SOC.

Not sure what your current visibility covers? Our 5-minute cyber maturity assessment maps your coverage across detection, response and recovery. No sales call required.

Experiencing a cyber incident? Call the Eye Security Incident Response hotline on +31 88 644 4898, 24 hours a day. For non-urgent cases, email cert@eye.security.

Frequently asked questions

What is threat hunting?

Threat hunting is the proactive search for attackers who are already inside an environment and have not triggered an alert. It begins with a human hypothesis about how an attack might be present, rather than with an alert from a detection rule.

How is threat hunting different from threat detection?

Detection is automated and triggered by activity matching a known pattern. Threat hunting is human-led and triggered by a hypothesis, which allows it to find techniques no rule has been written for yet. Detection tells you what matched. Hunting asks what got through without matching.

Is threat hunting the same as MDR?

No. Threat hunting is one capability within a mature managed detection and response service, not an alternative to it. MDR provides the telemetry, tooling and analysts; hunting is the proactive use of those to search for activity no alert surfaced.

Is threat hunting the same as penetration testing or red teaming?

No. Penetration testing and red teaming simulate an attacker to find out whether they could get in. Threat hunting searches for evidence that one already did. They answer opposite halves of the same question and produce different outputs.

What are the main threat hunting methodologies?

Three: hypothesis-driven hunting, which starts from a proposition about attacker technique and is usually structured against MITRE ATT&CK; intelligence-driven hunting, which starts from an external indicator or threat report; and anomaly-driven hunting, which starts from a deviation from the environment’s own baseline. Mature programmes use all three on different rhythms.

What tools do you need for threat hunting?

Searchable telemetry across endpoints, identity, network and cloud, correlated in a SIEM or XDR platform and retained long enough to hunt across. EDR, identity logs, NDR and cloud audit logs are the usual sources. Retention length and identity coverage matter more than the specific products.

How often should you conduct threat hunts?

Continuously for anomaly-driven hunting, on a defined schedule for hypothesis-driven hunts so that MITRE ATT&CK coverage can be tracked, and reactively for intelligence-driven hunts whenever relevant threat intelligence emerges. Hunting that only happens when the alert queue is quiet is not a programme.

Can a small IT team do threat hunting?

Partially. A small team can run useful hypothesis-driven hunts against specific techniques, and should start there. Continuous anomaly-driven hunting needs 24/7 coverage, mature baselines and threat intelligence, which is why most mid-market organisations access it through a managed SOC rather than building it.

What is the output of a threat hunt?

One of three things: confirmed malicious activity handed to incident response, a documented benign explanation, or an identified visibility gap. Every completed hunt should also produce a detection rule, a tuning change, or a logged gap with an owner. A hunt that ends only in a report has found something once.