Threat hunting

Proactively test a focused hypothesis

Threat hunting is a structured search for suspicious activity that existing alerts may not have identified. It begins with a hypothesis relevant to the environment, then uses available evidence to test it. The goal can be to find an intrusion, expose a visibility gap, or improve a detection process.

Hunting is different from browsing dashboards until something looks unfamiliar. A useful hypothesis identifies a behavior, why it matters here, which systems are in scope, and which records could support or weaken the explanation.

Turn context into a search

A fictional academy has recently expanded access to a cloud collaboration service. A hunter asks whether any privileged identity created an unusual application grant followed by access to staff documents. The hypothesis connects a plausible access path to assets the organization actually uses.

The hunter identifies the grant events, relevant identities, document-access records, and the retention available. If document-access events were never collected, the hunt can still investigate grants but cannot confidently answer the full access question. That limitation belongs in the plan before searching begins.

The search may reveal approved integrations, abandoned test applications, or unexplained grants. Each result needs context from the owner and the recorded activity. “Rare” is a useful filter, not a synonym for malicious.

Follow evidence without losing scope

Record queries, time windows, field assumptions, and findings so another analyst can reproduce the work. Refine the hypothesis when new evidence justifies it, but preserve why the scope changed. An open-ended search across every available source becomes difficult to review and conclude.

MITRE ATT&CK can help describe the behavior being tested. It should support the hypothesis rather than replace the environment-specific reason for hunting. A technique list alone does not establish priority.

If the hunt finds credible incident evidence, move into the organization's response process instead of continuing as a private research exercise. Preserve records and coordinate Incident containment through the appropriate authority.

A negative finding still needs interpretation

“No suspicious result was found” applies to the data, methods, and scope used. It does not prove the behavior never occurred. Document missing sources, retention limits, unresolved matches, and alternative procedures the search did not cover.

A useful outcome may be a new detection, improved logging, a corrected access configuration, or a better understanding of normal activity. Detection engineering turns repeatable findings into monitored signals.

For practice, write a one-paragraph hunting plan for unexpected privileged account creation. Identify one suspicious example, one legitimate provisioning example, required records, and a clear stopping condition. Finish with a conclusion that distinguishes observed findings from the confidence the available coverage can support.

Related concepts

• Logs and telemetry