Threat Hunting in MDR: What Analysts Actually Do
Threat hunting starts with a hypothesis, searches available telemetry for evidence, documents the result, and turns useful findings into better detection or response.
Threat hunting in managed detection and response (MDR) is a planned search for attacker activity that has not already produced a confirmed alert. A hunter starts with a hypothesis, identifies the required telemetry, searches for supporting or contradictory evidence, investigates findings, and documents what should change. The available evidence depends on which endpoint, identity, email, SaaS, and SIEM sources are connected.
That work is different from alert triage. Triage begins with a detection. Hunting begins with a question.
The threat-hunting cycle in MDR
| Stage | Hunter's task | Useful output |
|---|---|---|
| Hypothesis | Define the activity, technique, or exposure to test | A specific, testable hunt question |
| Data check | Confirm required endpoint, identity, email, cloud, or network evidence exists | Coverage and data-quality notes |
| Search | Query current and historical telemetry | Candidate events and affected entities |
| Investigate | Add context and rule out expected activity | Findings with confidence and rationale |
| Respond | Escalate confirmed threats through the incident process | Incident record and containment actions |
| Improve | Update detections, telemetry, or controls | New rule, tuning, coverage fix, or recommendation |
Expel's explanation of threat hunting in MDR distinguishes continuous automated detection from analyst-driven, hypothesis-based work. It also notes that service scope and reporting cadence vary by provider.
Common ways a hunt begins
| Starting point | Example prompt | Typical use |
|---|---|---|
| Hypothesis | "An attacker with a stolen session may have created a persistent mailbox rule." | Testing a specific attacker behaviour against the data |
| Threat intelligence | A new technique is reported against Microsoft 365 tenants | Checking whether the technique appears in the customer's history |
| Anomaly or event | An unusual administrative change raises a question | Following the thread beyond the first alert |
Example hunts for a Microsoft 365-led business
| Hypothesis | Evidence needed | What a finding might look like |
|---|---|---|
| A malicious application holds persistent access | Entra audit logs, consent events, application permissions | An unfamiliar app with broad mail or file permissions |
| A mailbox rule hides attacker activity | Exchange audit logs, rule creation events | A rule that forwards or deletes messages after a risky sign-in |
| A dormant privileged account was reused | Sign-in logs, role assignments, device records | Admin sign-in from a new device after months of silence |
| A stolen session token is being replayed | Sign-in logs, token and device context | Same session seen from two unrelated networks |
| Admin tools are misused on a device | Endpoint process and command-line telemetry | Encoded PowerShell started by an office application |
These are examples of how to frame a hunt. They are not a list of findings from any customer.
A hunt needs enough telemetry
A hunter cannot find evidence that was never collected or retained. A hunt for suspicious account persistence may need Microsoft Entra sign-ins, audit logs, OAuth consent activity, endpoint events, and SaaS access records. An endpoint-only service may not support that question.
Before treating threat hunting as a benefit, ask which data sources are available, how long evidence is retained, whether analysts can query across sources, and what happens when a required integration is missing. The 24/7 monitoring guide provides the related checks for continuous alert review and escalation.
Human judgment matters, but it is not magic
Automation can search large datasets, enrich indicators, and identify anomalies. Analysts decide whether a hypothesis makes sense in the customer's environment, whether evidence reflects ordinary work, and whether a finding justifies response.
Human review also has limits. A hunter can miss activity, work with incomplete data, or follow a weak hypothesis. Mature programs preserve the search, rationale, findings, and gaps so the work can be reviewed and improved.
What a threat-hunt report should show
A useful report identifies:
- the hypothesis and reason for the hunt;
- the environment and period searched;
- the data sources and known gaps;
- queries or techniques used at an appropriate level of detail;
- findings, confidence, and investigation notes;
- any incident escalated;
- detection or control changes; and
- follow-up owned by the provider or customer.
A report that says only "proactive hunting completed" does not show what was tested. A clean result should be described as no relevant evidence found within the searched data, not proof that the environment was threat-free.
Questions for an MDR provider
Ask whether hunting is included or an add-on, how often scheduled and event-driven hunts occur, who selects hypotheses, what telemetry is searchable, how findings are escalated, and how hunt results improve detection content.
Also ask for a redacted example. The example should show method and evidence boundaries without exposing another customer's confidential information.
QuantM MDR combines managed monitoring with human analysis across endpoint, email, Microsoft 365 identity, SaaS activity, and SIEM data included in scope. Learn how that fits the broader MDR operating model or start with a Microsoft 365 posture assessment.
FAQ
Is threat hunting included in every MDR service?
No. Providers define hunting differently. Confirm cadence, triggers, data sources, reporting, and whether the work is included in the quoted service.
How is threat hunting different from detection engineering?
Hunting searches for evidence based on a hypothesis. Detection engineering turns repeatable patterns into rules or analytics that can identify similar activity in the future. Findings from a hunt may lead to new detection content.
Does a clean threat hunt prove there was no compromise?
No. It means the hunt found no relevant evidence within the data, scope, period, and method used.