A threat-hunting play is a repeatable document that turns a suspected adversary activity into a structured hunt. It records what may be happening, where to look, how to test the idea, and which data and tools are needed. This makes hunts more consistent, measurable, and easier to prepare before investigation begins. section 2.1 section 2.2.3
Start with a hypothesis: a statement of the threat that may be present and how evidence could reveal it. A useful hypothesis is relevant to the environment and testable with available telemetry and tooling. Situational awareness—understanding business systems, technologies, processes, and relevant threats—helps keep the hunt focused on risks that matter. section 2.1 section 2.2.3
A practical play documents the investigative logic before execution:
- Identify the play by title and reference number, then state the background that triggered the hunt. section 2.2.2
- State the hypothesis and define the scope: affected servers, endpoints, applications, or cloud infrastructure. section 2.2.2 section 5.3.1
- List relevant adversary techniques, expected procedures or indicators, and the events needed to find them. section 2.2.2 section 2.2.3
- Record internal and external references, including threat intelligence, assessments, threat models, or MITRE ATT&CK mappings. section 2.2.2 section 1.6
- Confirm access to data stores and tools, and consider data volume, search time, and search performance before proceeding. section 1.6 section 3.2.1
Active Directory hunt for shell activity
A play can target APT41 activity in an Active Directory environment. Its hypothesis proposes that evidence of techniques consistent with the group’s patterns exists in the network. The scope includes AD servers and systems using AD services. Initial checks cover PowerShell and Windows Command Shell activity, using command, module, process, and script events such as Security Auditing event 4688 and Sysmon event 1. section 2.2.1 section 2.2.2
Office-delivered payload hunt
A red-team exercise can trigger a play for malicious processes spawned through Microsoft Office. The hypothesis proposes that spearphishing led a user to open a Word document whose payload compromised an endpoint. The play covers Microsoft endpoints, maps spearphishing links to MITRE ATT&CK T1566.002, and uses collected Sysmon endpoint events to investigate the activity. section 3.2.1
The play belongs to the preparation phase, but it guides the full expedition. During execution, hunters search for proof and refine an unproven hypothesis with better details before searching again. If evidence confirms it, they expand the scope to assess spread, engage incident response, and share detection or threat-intelligence content. Hunts can later become detection rules or be retired when their systems disappear. section 1.6 section 2.2.3
The same structure adapts to different environments. A web-shell play may be triggered by vulnerability and threat-intelligence reporting and use web-access and cloud-firewall events. A cloud-native play may originate in threat modeling and draw on Kubernetes API audit logs, node logs, web logs, and firewall logs. Deception-based plays instead formalize hypotheses around decoys and breadcrumbs intended to attract adversary interaction. section 4.3.1 section 5.3.1 section 10.0
Figure 1.3 High-level threat-hunting process
Use the process diagram to place the play in a loop of hypothesis formation, evidence gathering, refinement, scope expansion, and communication. section 1.6
