What Is Threat Hunting? A Guide for Security Leaders

You have detection rules firing, EDR deployed across endpoints, and SIEM ingesting logs. But detection coverage has a ceiling. Adversaries design operations to stay below your detection thresholds: living off the land, abusing legitimate credentials, moving laterally in ways that look like normal admin activity.

Threat hunting is the proactive, expert-led search for adversary activity that is already inside an environment and has not tripped a detection rule. It exists because the gaps under that ceiling are structural, not incidental. Hunters work from what threat intelligence says is likely targeting an industry, then go looking for behavior no rule was written to catch.

Two failure modes show up in post-incident reviews. One is an intrusion that someone outside the security team noticed first. The other is an intrusion that had been resident long enough for its earliest evidence to age out of the logs. Neither is a tuning problem.

TL;DR:

• Threat hunting starts from a human hypothesis, not an alert. Hunters search for threats that automated tools may miss. Treating threat hunting as a toggle on a dashboard misrepresents what it requires.
• Some services sold as threat hunting focus primarily on periodic indicator of compromise (IOC) sweeps. IOC hunts based on new threat intelligence are an important part of threat hunting, but they do not replace hypothesis-based investigations that search for novel adversary behavior.
• In-house hunting programs often degrade because talent and context requirements are structurally hard to sustain. When senior threat hunters leave, institutional knowledge leaves with them. Programs that cannot solve for continuity often drift back to periodic IOC sweeps.
• The compounding value of threat hunting is the detection flywheel. Each hunt that surfaces a new behavioral pattern should produce a new detection rule, so your automated layer catches that behavior next time. Activity without this feedback loop is a warning sign.

What Is Threat Hunting?

Threat hunting inverts the assumption detection runs on. A detection rule waits for evidence that something is already wrong, while a hunt begins from the premise that an adversary is present and looks for traces that SIEM rules and EDR signatures did not flag. The premise is a method, not a claim about any particular environment, and it holds because an absence of alerts is not evidence of an absence of adversaries.

The two activities therefore start in different places:

• Detection is reactive: a rule fires, an alert appears, your team investigates
• Hunting is proactive: a human develops a hypothesis about adversary behavior and goes looking for evidence

The threats that survive detection are rarely exotic. In the logs they look like work someone is supposed to be doing, which is why a rule written to catch them tends to catch the legitimate version too.

Threat hunting is a discipline and a function, not just a product feature. It needs senior expertise and time protected from the alert queue.

How Threat Hunting Works in Practice

Threat hunting follows a structured methodology, typically anchored in the MITRE ATT&CK framework. The sequence matters because each stage constrains the next, and skipping one shows up later as a hunt nobody can finish.

1. Build the Threat Model

Hunters establish adversary context before writing a single query, and they map which ATT&CK techniques are relevant to your industry, your business model, and the threat actors known to target your vertical.

For example, a financial services company faces different tactics, techniques, and procedures (TTPs) than a SaaS startup. A healthcare organization with legacy on-prem systems also has a different attack surface than a cloud-first tech company.

The threat model shapes everything downstream: which hypotheses are worth testing, and which data sources have to exist before anyone can test them. Without a threat model, hunters default to generic campaigns that don't account for how your specific environment would be targeted.

2. Develop the Hypothesis

A hypothesis has to be falsifiable, and specific enough to name the technique it is testing. Effective hunting starts by understanding which attacks are likely to target your organization, then turning that understanding into testable assumptions. The hypothesis-driven method gives a hunt a defined start and a defined end.

A concrete (but generalized) example of a well-formed hypothesis looks like: "Based on recent reporting of a threat actor targeting our industry, we hypothesize they will conduct internal host and account enumeration after initial access. We will look for behaviors consistent with automated reconnaissance and unusual enumeration patterns across endpoints and identity logs." A hypothesis in that form is materially different from "search for this hash."

3. Map to Data Sources

Hunters identify exactly which telemetry is needed to validate or refute the hypothesis. Mapping is where many hunts deliver unexpected value, because a hunt that finds no adversary still tells you what you cannot see. The TTP-based hunting methodology, written in 2019 and published the following year, records the same pattern: an organization's early hunts tend to produce a better understanding of its own environment before they produce a confirmed intrusion.

A hypothesis about lateral movement via RDP is useless if your environment isn't logging RDP session data. Similarly, a hunt targeting credential abuse across cloud services falls apart if identity provider logs aren't being ingested or retained long enough to correlate.

Done honestly, this step is an audit of what you can actually see, and the gaps it turns up should be documented and fed to the detection engineering team.

4. Execute and Correlate Across Systems

An attacker's trail often spans endpoint, identity, cloud, and network simultaneously. Cross-system correlation connects those threads, and it is what separates hypothesis-based hunting from tool-by-tool searching.

Consider a hypothesis about lateral movement following initial access via phishing. The hunt might:

• Start in email security logs (identifying the phishing delivery)
• Move to endpoint process telemetry (tracking execution and discovery commands)
• Pivot to identity provider logs (spotting unusual authentication to new systems)
• End in cloud API logs (finding data staging or exfiltration attempts)

Each system alone shows a fragment. Correlated together, they reveal the full attack chain.

If your logs only go back 30 days and the attacker has been present for 60, you're hunting with half the picture.

5. Respond and Create Detections

A hunt ends with remediation of anything confirmed, and with new detection rules written from what it found. The rules are where most of the long-term value lives: once the automated layer catches that behavior, the next hunt is free for genuinely novel TTPs, and the one after that starts from a higher floor.

That feedback loop is the detection flywheel in practice. Documentation is what keeps it turning:

• What was the hypothesis?
• What data was queried?
• What was found?
• What rule was created?
• What coverage gap was closed?

Without that trail, the knowledge dies with the hunt.

Two Types of Threat Hunts (and Why the Distinction Matters)

The term "threat hunting" covers two activities with different inputs and different ceilings, and which one a program actually runs decides whether it ever finds anything new.

IOC-Based Hunts

IOC-based hunting sweeps the environment for known indicators of compromise: file hashes, IP addresses, domains, and registry keys. It is a common baseline capability, and many organizations run periodic sweeps when new threat intelligence emerges or on a scheduled cadence. The sweeps find known threats and documented malware, and most mature security organizations do them.

But it is limited by definition. IOC-based sweeps only find what has already been publicly identified and cataloged. They miss novel malware, living-off-the-land techniques, insider threats, and any adversary who rotates infrastructure before your feed updates.

In practice, IOC sweeping sits one step above automated alerting. It is deliberate and scheduled, and it still only looks for what someone has already named. Some providers label periodic IOC sweeps as threat hunting, even when hypothesis-driven investigations are not available.

Hypothesis-Based Hunts

Hypothesis-based hunting begins with a thesis about what an attacker would do in a specific environment. An expert then investigates that thesis across data sources to prove or disprove it.

Developing the hypothesis still relies primarily on human expertise and deep organizational context. The expert who defines the hypothesis must understand how the business operates, including policies, exceptions, and normal activity patterns, as well as historic context from past investigations. AI can then execute the hypothesis testing across relevant data sources once that context is established.

The expert provides the hypothesis and agentic execution scales the search, which is the pairing that holds up as the environment grows. Advanced programs run on a continuous cadence and widen their coverage as they go, so what hunting can reach keeps expanding.

Threat Hunting vs. Detection and Response

Hunting starts where detection ends. Detection covers what someone already thought to write a rule for, and hunting goes after attacker TTPs in the places that detection technology has not already reached.

Detection work can be spread across a queue of responders, while hunting depends on senior practitioners who can reason about adversary behavior. Programs that force hunters into the alert queue rotation end up with both functions performing below their potential.

Where Hunting and Detection Diverge

The two functions separate on nearly every axis that matters operationally, from the trigger to the success metric.

‍

New TTPs and behavioral patterns from a hunt become new rules, tighter logic, and coverage over surfaces nobody was watching, which is why a program that never closes that loop does the same work twice.

What Makes Hunting Hard to Sustain

The qualities that make hunting effective (senior expertise, deep organizational context, broad telemetry access) are also the hardest to build and the hardest to keep.

Senior threat hunters are scarce, expensive to hire, and hard to retain. That is the visible constraint; the knowledge constraint is worse. Hypothesis-based hunting depends on deep organizational context: how the environment is configured, what's normal, and where the gaps are.

In many programs, that context exists only in the hunter's head. There's no systematic way to capture it, compound it, or transfer it. A departure does not just cost a person; it resets months of accumulated understanding.

Programs without a mechanism to operationalize hunt findings (defining hypotheses, executing the hunt, converting findings into detection rules, documenting evidence chains) are structurally fragile regardless of how talented the individual hunter is.

The result is a common degradation pattern:

1. Senior hunter hired; hypothesis-based hunting launches.
2. The hunter leaves, taking organization-specific context with them.
3. Replacement takes months, often at a lower experience level.
4. Organizational context rebuilt from scratch.
5. The program defaults to periodic IOC sweeps while "searching for a replacement."

The interim arrangement becomes permanent. The sweeps are the program.

Building a Hunting Function or Buying One

Most organizations reach the same fork: staff a hunting function internally, or contract one. The internal route runs into the talent and continuity problems above, and managed hunting exists to solve them. What a contract does not settle on its own is which kind of hunt it covers, since both kinds travel under the same name.

Automation makes the contracted version scale: multi-source correlation, timeline reconstruction, and evidence collection across data sources, at a volume no single hunter can cover. Models reason well across a complex investigation once the context is structured and accessible, and assembling that context is deliberate work that people do.

Daylight Security offers hypothesis-based threat hunting and IOC-based sweeps as a dedicated service, scoped separately from managed detection and response. The security expert develops the hypothesis based on customer priorities and a deep understanding of the customer's environment, and AI automates the multi-stage investigation across data sources. The hunts run continuously based on a defined frequency.

Findings feed directly into detection tuning, so the knowledge compounds in the system rather than walking out the door when someone leaves.

What to Ask Before Calling It Hunting

Whether the function sits in-house or with a provider, what separates hunting from indicator matching comes down to ownership, reach, and what survives the hunt. Who writes the hypotheses, and what do they know about this environment that a feed does not? What telemetry does the hunt actually reach, and how far back does it go? And what happens to a finding once the hunt closes: does it become a detection rule, or a paragraph in a report?

A program with good answers to all three improves over time. One without them is running sweeps on a schedule. That is worth doing, and it is not the same discipline.

Frequently Asked Questions About Threat Hunting

How Often Should Threat Hunts Be Conducted?

There is no standard interval, and a number pulled from someone else's program is worth less than one a team can actually sustain. Hypothesis-based hunts work best when they run regularly and get refreshed as threat intelligence evolves and the environment changes. Whatever the interval, the cadence is only as useful as the data retention behind it, since a quarterly hunt against 30 days of logs cannot see the quarter.

Can AI Fully Automate Threat Hunting?

No. Hypothesis creation draws on human reasoning about adversary behavior in a specific environment, and on knowing what normal looks like there. The workable model is AI-assisted: people define the question, and automation scales the investigation.

Is There Regulatory Pressure to Have a Formal Threat Hunting Program?

Indirectly, yes. Neither NIS2 in the EU nor APRA CPS 234 in Australia names threat hunting as a requirement. Both ask for risk-management measures, a working detection and response capability, and evidence that controls get tested, which amounts to pressure toward demonstrable, repeatable security monitoring rather than ad hoc response. What that pressure rewards is documentation: what was searched, what was found, and how the findings changed detection.