Threat Hunting: How a Hunt Program Works and When to Build or Buy One

Threat hunting is the proactive, analyst-led search for attacker activity that your existing detections missed. A hunt starts from a hypothesis, such as "an attacker is using a valid administrator account and built-in Windows tools to move between servers," instead of from an alert. It ends in one of three outcomes: an incident to respond to, a new detection rule so the security operations center (SOC) catches the behavior next time, or a documented gap in telemetry. A hunt program is worth funding when it runs on a schedule, draws hypotheses from threat intelligence and MITRE ATT&CK, retains enough endpoint and identity data to cover the period it is hunting, and measures its output in detections created and gaps closed.
How is threat hunting different from security monitoring?
Monitoring waits for a rule to fire. Hunting assumes that some attacker activity does not match any rule and goes looking for it. The gap between the two has grown as attackers rely on the tools already installed on the systems they compromise. Joint guidance from CISA, the NSA, the FBI, and partner agencies, published in February 2024, explains that living off the land allows actors to blend in with normal system and network activities. The guidance notes a general lack of conventional indicators of compromise for this activity and says actors can easily modify known indicators, such as filenames and command-line arguments. Its recommendations include enhancing network monitoring, log retention, and threat hunting to identify prolonged adversary presence.
A May 2025 joint publication on implementing SIEM and SOAR platforms, led by the Australian Signals Directorate with CISA and the NSA among its co-authors, describes hunting as one way to test whether the baseline excludes all malicious behavior. That framing is useful for a CISO. A hunt checks the assumption underneath every detection rule: that what the SOC treats as normal activity is benign.
What are the main threat hunting methods?
Hunts follow one of three methods, and a mature program uses all of them. The method determines what the hunt needs before it starts and what it usually produces at the end.
| Method | Starts from | Example | What it needs | Typical output |
|---|---|---|---|---|
| Hypothesis-driven | An ATT&CK technique likely in your environment | Service accounts signing in interactively to servers they do not normally touch | Identity and endpoint logs with enough history to define normal | A new detection or a confirmed incident |
| Intelligence-driven | A threat report on an actor or campaign | Searching for the behaviors a government advisory attributes to an actor targeting your sector | Current threat intelligence and fast access to raw telemetry | A yes or no answer for leadership, plus detections for the behaviors |
| Baseline-driven | Statistics on normal activity | Rare parent and child process pairs across all endpoints over 30 days | Query skills and data from every endpoint | Outliers to investigate and a cleaner baseline |
Hypothesis-driven hunts are the backbone. Our explainer on the MITRE ATT&CK framework covers how teams use the matrix to choose techniques. Intelligence-driven hunts answer the question a board asks after a major advisory: are we affected? Baseline-driven hunts take the most data and the most skill, and they find the activity nobody wrote a hypothesis for.
What does one hunt look like from start to finish?
A disciplined hunt follows the same six steps every time, and the record it leaves matters as much as the result:
- Write the hypothesis in one sentence and map it to the ATT&CK techniques it covers.
- Confirm that the telemetry exists, parses correctly, and covers the time window the hypothesis needs.
- Query for the behavior and build a picture of normal for it, such as which accounts usually perform the action and from which hosts.
- Investigate the outliers and escalate anything malicious to incident response immediately.
- Convert the hunt query into a detection rule, or record why the behavior is too common to alert on.
- File the hypothesis, data sources, queries, findings, and gaps in a hunt library so the next hunter can rerun or extend it.
Many hunts find no intruder. A hunt that finds nothing still pays off when it leaves behind a tested query, a detection, or a request for missing logs. A hunt that finds nothing and leaves nothing behind was an exercise in reassurance.
What data and retention does hunting need?
Hunting runs on raw telemetry: endpoint process events with full command lines, identity sign-ins and directory changes, DNS queries, email events, and cloud control plane audit logs. Alerts alone are not enough, because the point is to find what never generated one. The lookback window matters as much as the data types. Microsoft's documentation states that advanced hunting in Defender XDR lets you explore up to 30 days of raw Defender XDR data, and that keeping supported hunting tables longer requires onboarding a Microsoft Sentinel workspace and configuring retention there. The same page notes that hunting queries can become custom detection rules that run automatically, which is the conversion step in the sequence above.
Thirty days is short for an intruder who arrived months ago. The ASD and CISA practitioner guidance suggests, as a starting point for organizations new to detection, retaining logs that record administrative and security-related events for a minimum of one year and informational logs for 90 days, with the final periods set by your risk profile and regulatory obligations. Hunting is often how a company discovers that its retention is too short, because a hypothesis about last quarter cannot be tested against data that was deleted after a month.
How often should you hunt?
Cadence should follow the three methods. Run an intelligence-driven hunt within days of any advisory or threat report that names an actor active in your sector, because leadership will ask whether the company is affected and the honest answer requires a search. Rotate hypothesis-driven hunts through your priority ATT&CK techniques so each one is hunted at least once a year, with the techniques behind your own past incidents hunted more often. Repeat baseline hunts after major changes, such as an acquisition, a cloud migration, or a new remote access product, because each of those changes what normal looks like. BD Emerson planning range: one to two completed hypothesis hunts per month for a team starting out, rising to weekly once a dedicated hunter and a detection pipeline are in place. Fewer, finished hunts with documented outputs beat many half-run ones.
How do you measure a threat hunting program?
Counting hunts rewards volume, and counting threats found punishes the hunts that prove an environment is clean. Measure what the program leaves behind. The useful numbers are detection rules created from hunts and still in production, telemetry gaps identified and closed, priority ATT&CK techniques covered by at least one completed hunt in the past year, time from a new threat advisory to a completed intelligence-driven hunt, and, for any intrusion a hunt does find, how long the attacker had been present. Report the trend each quarter. A program that produces detections every month is making the SOC better; a program that produces only reports is not.
Should you build a hunt team or buy managed threat hunting?
Build in-house when three conditions hold. You have a detection engineering function that can turn hunt queries into rules, you retain enough searchable data to hunt across the periods that matter, and you have senior analysts with protected time, because hunting squeezed between alert shifts does not happen. A practical start is to give two or three senior analysts a fixed share of each week for hunting, then create dedicated hunter roles once the hunt library and the detection pipeline are in place.
Buy when those conditions are missing or when you need coverage faster than you can hire. Managed threat hunting is commonly sold as part of managed detection and response (MDR), and its depth varies between providers. Ask whether the provider hunts in your SIEM, identity, and cloud data or only in the telemetry from its own endpoint detection and response (EDR) agent. Ask whether you receive the hypotheses and queries, and whether findings come back as detections in your SIEM that you own. Ask how the provider hunts for living-off-the-land activity in identity and cloud logs, where an EDR agent sees little. Our comparison of MDR, SOC as a service, and MSSP models shows who owns the tooling, the data, and the detection content in each, which decides whether hunt findings stay with you. One workable hybrid has the provider run intelligence-driven hunts across its client base while your team runs hypothesis hunts focused on your most valuable systems.
When a hunt finds an intruder, hunting stops and incident response starts. BD Emerson's incident response retainer puts that moment on pre-negotiated terms, with a guaranteed response window, named primary and backup responders, and a defined escalation path. Unused hours convert to readiness work, including logging improvements and detection tuning, which is where many hunt findings end up: a log source that needs onboarding, a retention period that needs extending, or a hunt query that should become a detection.



