What is threat hunting in cybersecurity?

Threat hunting is the proactive, hypothesis-driven search for attackers already inside an environment who have not triggered an automated alert. Analysts form a hypothesis about attacker behaviour, test it against endpoint, identity, network and cloud telemetry, and either confirm an incident or convert the hypothesis into a new detection. It assumes a breach has occurred rather than waiting for evidence.

What is the difference between threat hunting and threat detection?

Threat detection is automated: a platform matches telemetry against rules, signatures or models written in advance and raises alerts. Threat hunting is human-led and starts from a hypothesis rather than a rule, looking for activity the rules missed. Hunting feeds detection by turning confirmed hypotheses into new rules, so the two disciplines improve each other.

What is managed threat hunting?

Managed threat hunting is threat hunting delivered by an external provider, usually as part of a managed detection and response (MDR) service that already operates your EDR and SIEM. The provider's analysts run scheduled and intelligence-led hunts on your telemetry, report each hunt with its hypothesis and result, and escalate confirmed findings for response. Standalone threat hunting services exist, but most organisations buy the capability this way, inside MDR, because hunting needs the same telemetry the MDR provider already operates.

What data do you need for threat hunting?

At minimum, endpoint telemetry with process and command-line detail, identity and authentication logs, DNS and proxy logs, and cloud control-plane audit logs, retained long enough to cover the dwell time you are concerned about. An asset and identity inventory is equally important, because a hunter cannot judge an anomaly without knowing what a host or account is for.

What is MITRE ATT&CK used for in threat hunting?

MITRE ATT&CK supplies the catalogue of adversary techniques that hunters turn into hypotheses, the data sources needed to observe each technique, and a common label so a hunt result becomes a detection with the same name. Programmes also use it to measure coverage: which techniques have a completed hunt or live detection, and which remain blind spots.

How does red teaming improve threat hunting?

A red team engagement records which attack paths worked in your environment and which detections stayed silent, giving the hunting team hypotheses that are already proven feasible. Purple-team sessions make that exchange continuous, with red and blue tuning detections technique by technique. HackersHub uses its offensive findings as a direct input to the hunting and detection engineering inside its managed services.

2 November 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)

What is threat hunting? How proactive hunts find the attackers your detection stack missed

Threat hunting is the proactive, hypothesis-driven search for adversaries who are already inside your environment and have not triggered an alert. This guide covers how a hunt runs, where hypotheses come from, which data you need, how it differs from detection and incident response, how to measure a programme, and what managed threat hunting inside MDR should deliver.

Talk to us about managed detection and response

What threat hunting is

Threat hunting is the proactive, human-led search for adversary activity that automated detection has not flagged. It starts from a hypothesis about how an attacker could be operating in your environment, tests that hypothesis against your own telemetry, and ends either with a confirmed incident handed to incident response or with a new, durable detection so the same behaviour is caught automatically next time. The defining assumption is that the attacker is already inside: hunting does not wait for an alert, it goes looking for the quiet activity that alerts are built to miss.

The practice exists because preventive and detective controls have a structural blind spot. Endpoint detection and response (EDR), a SIEM and network monitoring all fire on patterns somebody has already written. An adversary who uses legitimate credentials, built-in administration tools and ordinary protocols produces activity that looks like a normal day. Industry breach reports have for years put median attacker dwell time at days to weeks. Hunting shortens that window by asking what the data would look like if the attacker were there.

Three outputs make a hunt worth the analyst time. The first is confirmed malicious activity, which becomes an incident. The second is a new detection rule, analytic or playbook, so the hypothesis never has to be hunted manually again. The third is a documented visibility gap: a log source that was not collected, a system that was not enrolled, a retention window that was too short. A hunting programme that produces only the first is a slow incident response team; a programme that produces all three improves the detection stack every month.

Threat hunting vs threat detection vs incident response

The three disciplines share tools and often share people, which is why buyers confuse them. They answer different questions and are measured differently.

Dimension	Threat detection	Threat hunting	Incident response
Starting point	A rule, signature or model written in advance	A hypothesis about attacker behaviour, formed by an analyst	A confirmed or suspected incident
Core assumption	Known bad patterns will recur and can be matched	The attacker is already inside and has evaded the rules	Something has happened and damage must be limited
Who drives it	The platform; analysts triage its output	Analysts; the platform supplies the data	An incident commander and a response team
Primary inputs	Real-time telemetry, threat feeds, detection content	Historical and current telemetry, MITRE ATT&CK, intelligence, offensive findings	Forensic artefacts, logs, hunt and detection output
Output	Alerts, prioritised for triage	Confirmed incidents, new detections, documented visibility gaps	Containment, eradication, recovery, lessons learned
Measured by	Coverage, precision, false-positive rate, time to alert	Hunts completed, techniques covered, detections created, dwell time found	Time to contain, time to recover, impact avoided

The threat hunting loop

Mature programmes run every hunt through the same loop so that results are comparable and nothing ends in an analyst's notebook.

1. Hypothesis

Write one testable sentence: 'an attacker who has phished a user is using a built-in remote-management tool to move between workstations'. A good hypothesis names a technique, a data source and what evidence would confirm or refute it.

2. Data

Identify which telemetry can answer the question and confirm it is actually collected, parsed and retained for the period the hypothesis covers. A visibility gap found here is a legitimate result for the detection engineering backlog.

3. Analyse

Query, stack, baseline and compare. Hunters look for rare values, first-seen events, outliers against peer groups and sequences of events that match the technique. The skill is knowing what normal looks like in this specific environment.

4. Enrich and validate

Every candidate finding is enriched with asset criticality, user role, change records and threat intelligence before anyone calls it malicious. Validation separates a sysadmin's scheduled task from an attacker's persistence.

5. Respond

Confirmed activity hands over to incident response with the evidence, timeline and scope the hunt already assembled. If the response team has to redo the analysis, the hunt was not documented well enough.

6. Automate

Turn the hypothesis into a detection rule, a scheduled analytic or an enrichment so the platform catches it next time, then record the hunt, its coverage against MITRE ATT&CK and its outcome. The loop closes when the manual hunt is no longer needed.

Where hunting hypotheses come from

A hunt without a source for its hypotheses degenerates into random searching. Programmes draw from four wells.

MITRE ATT&CK

The ATT&CK Enterprise matrix catalogues adversary tactics, techniques and sub-techniques observed in real intrusions, with the data sources that reveal each one. Hunters use it to pick techniques that matter for their environment (credential access, lateral movement, persistence, defence evasion), to check which of them existing detections already cover, and to track coverage over time. ATT&CK also gives hunters and detection engineers a shared vocabulary, so a hunt finding becomes a detection with the same label.

Threat intelligence

Strategic and operational intelligence tells a hunter which groups target their sector and geography and which techniques those groups favour this quarter. Tactical indicators (hashes, domains, IP addresses) are the least durable input because adversaries replace them with little effort; behaviour-level intelligence (how a group stages data before exfiltration, which legitimate tools it abuses) survives far longer, a point captured in the widely cited Pyramid of Pain.

Offensive findings from penetration tests and red teams

The most environment-specific source. A red team report shows exactly which path through your identity, network and cloud controls worked, which detections fired and which stayed silent. Every silent step is a hunting hypothesis with proof that it is feasible here. Penetration test findings that were remediated still tell hunters what an attacker would have tried, and whether anyone would have noticed.

Your own environment

Crown-jewel systems, privileged accounts, external exposure and recent change are hypothesis generators in their own right. A new SaaS integration, a merger, a migration to a new identity provider or a vendor with standing remote access each creates a question: if this were abused, what would the data show?

The data a hunt needs

Hunting quality is bounded by telemetry quality. These are the sources a programme should be able to query, and the questions to ask about each before the first hunt.

Endpoint telemetry from an EDR or equivalent: process creation with command lines, parent-child relationships, network connections, file and registry changes and script execution, across servers and workstations, not only the ones considered sensitive
Identity and authentication logs: domain controller and cloud identity provider sign-ins, Kerberos and NTLM events, privilege changes, MFA outcomes, service account usage and conditional-access decisions
Network metadata: DNS queries, proxy and firewall logs, flow records, VPN and remote-access sessions, with internal east-west visibility rather than perimeter only
Cloud control-plane logs: AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs, plus SaaS audit logs for email, collaboration and code platforms
Email telemetry: delivery, attachment and URL verdicts, mailbox rule changes, forwarding and OAuth consent grants
Application and database logs for crown-jewel systems, including administrative actions and bulk data access
An asset inventory and identity inventory that can tell a hunter what a host or account is for; without it, every anomaly is ambiguous
Retention long enough to cover the dwell time you are worried about: a hunt for a technique used six months ago needs six months of searchable data, not thirty days

Structured, unstructured and situational hunting

Practitioners distinguish three hunting styles. Most programmes use all three, in different proportions as they mature.

Aspect	Structured hunting	Unstructured hunting	Situational (entity-driven) hunting
Starting point	A hypothesis built on a known technique or attacker playbook, usually expressed in ATT&CK terms	An indicator, anomaly or analyst intuition, followed wherever the data leads	A specific high-value entity or situation: a crown-jewel system, a privileged group, an executive, a vendor connection
Typical trigger	Scheduled coverage plan, new intelligence on a group's techniques, a red-team finding	A suspicious indicator from a feed, an odd log pattern, an unexplained spike	A risk assessment, a merger, a new exposure, a sector-specific campaign
Scope	Narrow and repeatable; one technique across the whole estate	Open-ended; one thread pulled across many data sources	Deep on a few entities; many techniques against one target
Strength	Measurable coverage; converts cleanly into detections	Finds the unknown unknowns that no playbook predicted	Concentrates effort where impact is highest
Weakness	Only finds what the catalogue describes	Hard to measure; depends heavily on analyst experience	Leaves the rest of the estate unexamined
Typical output	Detection rules mapped to ATT&CK, a coverage heat map	New hypotheses for structured hunts, enriched intelligence	A hardening and monitoring plan for the entity, tailored detections

How to measure a threat hunting programme

Hunting is easy to fund for a quarter and hard to defend when funding is reviewed, because a successful hunt that finds nothing looks identical to a wasted one. The answer is to measure the programme, not the individual hunt. Useful measures are hunts completed per month against the plan, the share of relevant MITRE ATT&CK techniques covered by at least one completed hunt or live detection, detections and analytics created from hunts, visibility gaps identified and closed, and the number of true-positive incidents the hunting team found before any alert fired. Define each for your own environment rather than copying a vendor benchmark.

Dwell time is the outcome metric. When a hunt does find an intrusion, record how long the attacker had been present before the hunt and how long before an automated control would have caught them, if ever. The Hunting Maturity Model, which describes five levels from no routine hunting to a programme that automates most of its successful hunts, is a practical way to describe where you stand. None of these figures should be promised in advance by a provider; a provider that quotes a guaranteed dwell-time reduction before seeing your telemetry is selling, not hunting.

Hunting also produces evidence for frameworks that ask for monitoring and analysis rather than just logging. NIST CSF 2.0 places it under the Detect function (continuous monitoring, DE.CM, and adverse event analysis, DE.AE), and NIST SP 800-61 Rev. 3 ties detection and analysis to the same profile. Contractors under CMMC 2.0 Level 2 must monitor systems to detect attacks and identify unauthorised use (NIST SP 800-171 3.14.6 and 3.14.7). HIPAA requires information system activity review (45 CFR 164.308(a)(1)(ii)(D)), PCI DSS v4.0.1 requires audit logs to be reviewed (Requirement 10.4), and in the EU, NIS2 Article 21(2)(b) and DORA Article 10 expect mechanisms that detect anomalous activity promptly. Documented hunts with dates, hypotheses, data sources and outcomes are exactly the evidence those controls ask for.

Managed threat hunting as part of MDR

Few mid-market organisations can staff hunting internally. It needs analysts who understand attacker tradecraft, time that is not consumed by alert triage, and telemetry breadth across endpoint, identity, network and cloud. Threat hunting services are therefore usually bought as managed threat hunting inside a managed detection and response (MDR) service: the provider operates your EDR and SIEM, triages alerts around the clock, and runs a hunting programme on the same telemetry. Our MDR service page describes HackersHub's managed detection and response in full; the companion article on MDR vs EDR vs XDR explains why the hunting layer is what separates a service from a tool.

What to ask a provider: how many hunts are run per month on your data specifically, not across the customer base; whether hypotheses are tailored to your sector and your own offensive findings; whether completed hunts are reported with hypothesis, data sources, result and the detection created; how a confirmed finding is escalated and who is authorised to contain; and which telemetry the provider needs from you before hunting is meaningful. A provider that cannot show you a completed hunt report is offering alert triage under a different name.

At HackersHub, detection engineering and hunting inside our managed services are informed by our offensive work. The techniques our red teams use against enterprise environments, and the gaps our penetration testers find, become the hypotheses our analysts hunt for in client telemetry. Monitoring runs 24/7, we manage the SIEM and EDR platforms, we support incident response when a hunt confirms activity, and reporting maps to the compliance frameworks named above. Delivery is remote from Amsterdam, Netherlands, with on-site work in the EU and the US where needed.

How red team knowledge improves hunting

The best hunters think like the people they are hunting, and the fastest way to acquire that is to work alongside them. A red team engagement is a hunting programme's richest single input: it produces a dated, step-by-step record of an intrusion in your own environment, with every technique mapped to ATT&CK and every detection outcome recorded. Where the red team moved unnoticed, the hunting team has a hypothesis that is already proven feasible. Our explainer on what red teaming is describes how an engagement runs through to the replay session, where hunters and red teamers compare notes.

Purple teaming makes the exchange continuous. Rather than one report a year, red and blue sit together, execute techniques one at a time and tune detections on the spot, and the hunting backlog is updated with every technique that still slips through. Pairing an annual red team with quarterly purple-team sessions and a monthly hunting cadence produces a detection stack that reflects how attackers actually behave against your environment. That is the model HackersHub applies across its offensive and managed services.

Frequently asked questions

Related services and guides

Want hunters who think like the attackers they are looking for?

HackersHub's managed detection and response combines 24/7 monitoring with hunting and detection engineering informed by 10+ years of offensive security work. Talk to an expert about what your telemetry would support.

Explore managed detection and response Talk to an expert