Guides & Tutorials

Playbooks in threat hunting and incident response, in practice

HuntRule Team · · 8 min read

A flat brass plate with a hollow geometric cutout lying on a dark steel bench, and the matching solid machined metal piece standing upright on edge next to it.
On this page

The word means three different things

A CACAO playbook is a JSON object with an id, a created timestamp and a workflow dictionary keyed by step identifiers. A Microsoft Sentinel playbook is an Azure Logic Apps workflow triggered by an automation rule. A hunting playbook is often a Confluence page with a hypothesis, a query and a list of hosts to check. All three are called playbooks. They are not the same artifact, and confusing them wastes a lot of meeting time.

The OASIS CACAO Security Playbooks Version 1.1 specification, Committee Specification Draft 02 dated 01 March 2022, gives the cleanest definition. A playbook is a workflow for security orchestration containing a set of steps performed according to a logical process, triggered by an automated or manual event or observation. The same spec draws a line that matters operationally. An executable playbook runs in your infrastructure without modification. A playbook template describes actions for a particular incident, malware or vulnerability and will not run as-is, but informs the executable playbook you write for your own environment.

Most of what circulates publicly is templates. The CISA Federal Government Cybersecurity Incident and Vulnerability Response Playbooks, published under Section 6 of Executive Order 14028 for FCEB agencies, are templates in exactly this sense. Two documents, one for incident response and one for vulnerability response. They standardize procedure, not tooling.

Playbook types you should be able to name

CACAO 1.1 defines seven playbook types in its vocabulary. The distinction is not academic, because it determines who owns the playbook and what triggers it.

  • notification: disseminate information and other playbooks about an event

  • detection: orchestrate the steps to detect known activity, or to threat hunt

  • investigation: determine what an event or incident caused

  • prevention: stop a known or expected event from occurring

  • mitigation: limit impact when remediation is not yet possible

  • remediation: return the system or network to a nominal operating state

  • attack: run a penetration test or attack simulation to verify controls

Note that threat hunting sits under detection in this taxonomy, not investigation. That is consistent with how hunt teams actually work. A hunt produces detection content. An investigation consumes an alert that already fired.

Where the response playbook fits in the lifecycle

NIST finalized SP 800-61 Revision 3 in April 2025, superseding Revision 2, the Computer Security Incident Handling Guide. Revision 3 is a CSF 2.0 Community Profile. Its lifecycle model puts Govern, Identify and Protect at the bottom as preparation activities that are broader than incident response, with Detect, Respond and Recover as the incident response layer, and Improvement inside Identify feeding lessons learned back into every function.

The practical consequence for playbook authors: a response playbook is a Respond artifact, but the preconditions it depends on are Govern and Protect artifacts. If your containment step says "isolate the host", the playbook is only executable when someone in Govern has already decided who may authorize isolation at 03:00 and Protect has already deployed the agent that can do it. Playbooks that skip that check are templates pretending to be executable.

Hunting playbooks and the PEAK framework

Splunk SURGe published the PEAK Threat Hunting Framework on 18 April 2023, authored by David Bianco, who also helped create the Sqrrl Threat Hunting Reference Model in 2015. PEAK stands for Prepare, Execute, and Act with Knowledge. It defines three hunt types: hypothesis-driven, baseline (exploratory data analysis) and Model-Assisted Threat Hunting. The reference content repository now lives under Cisco-Talos/PEAK on GitHub, Apache-2.0.

The Act phase is the part that turns a hunt into something a SOC keeps. Documentation, automation and communication. In playbook terms, the output of a detection playbook is usually a new detection rule plus a new investigation playbook that tells the tier 1 analyst what to do when it fires. If a hunt ends with a Slack message and no artifact, it did not happen.

Two identical glass specimen jars side by side on a metal bench, the left one empty with its lid tipped off beside it, the right one sealed and holding a small machined metal component.

Anatomy of a machine-readable playbook

CACAO workflow steps come from a closed step type vocabulary: start, end, single action, playbook, parallel, if condition, while condition and switch condition. Steps carry commands and targets. Targets include HTTP API, SSH CLI, individual, group, organization, location, sector and general network address. Playbooks carry variables, data markings including TLP, and optional detached digital signatures. Signing does not update the modified timestamp, because adding a signature is not a revision.

The shape below is abbreviated and not schema-complete. It shows the properties that matter when you are reading someone else's playbook for the first time.

{
  "type": "playbook",
  "id": "playbook--<uuid>",
  "name": "Investigate domain group enumeration",
  "playbook_types": ["investigation"],
  "created": "2022-03-01T00:00:00.000Z",
  "modified": "2022-03-01T00:00:00.000Z",
  "workflow_start": "step--<uuid-1>",
  "workflow": {
    "step--<uuid-1>": {
      "type": "start",
      "on_completion": "step--<uuid-2>"
    }
  }
}

Versioning rules are strict and worth stealing even if you never emit CACAO JSON. A playbook version is identified by the combination of id and modified. Only the object creator may issue a new version under the same id. If you fork someone's playbook, you mint a new id and populate derived_from. Revocation is permanent, and once revoked is true no later version may be created.

A hunt playbook that produces a detection

Here is the reconstruction of a small baseline hunt we run in the lab against a Windows event collector. Hypothesis: built-in net.exe domain enumeration is rare on workstations and common on a handful of admin jump boxes. The Execute phase is one query.

index=windows EventCode=4688
| search (New_Process_Name="*\\net.exe" OR New_Process_Name="*\\net1.exe")
| stats count, dc(ComputerName) as hosts, values(Account_Name) as accounts by Process_Command_Line
| sort - count

Event ID 4688 only carries Process_Command_Line when command-line auditing is enabled through the ProcessCreationIncludeCmdLine_Enabled policy. Without it the query returns image names and nothing useful. We use Sysmon Event ID 1 where it is deployed and 4688 everywhere else.

The Act phase output is a rule. This one is ours, written in the lab, not lifted from a public ruleset.

title: Domain Admins group enumeration via net.exe
status: experimental
description: Detects enumeration of the Domain Admins group using the built-in net command
author: huntrule lab
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    - Image|endswith:
        - '\net.exe'
        - '\net1.exe'
    - OriginalFileName:
        - 'net.exe'
        - 'net1.exe'
  selection_cli:
    CommandLine|contains|all:
      - ' group '
      - 'Domain Admins'
  condition: all of selection_*
falsepositives:
  - Helpdesk scripts that audit privileged group membership
  - Endpoint management agents running inventory tasks
level: low
tags:
  - attack.discovery
  - attack.t1069.002

What it catches: the literal net group "Domain Admins" /domain pattern and its net1.exe variant. What it misses: LDAP queries from PowerShell or .NET, dsquery, ADSI calls, any BOF running in-process, and localized group names on non-English domains. It also misses renamed copies of net.exe unless OriginalFileName is present in your telemetry. We did not test it against Server 2016 collectors with 4688 command-line auditing disabled.

If you want the broader family of discovery content rather than this one rule, start at /rules?domain=windows and narrow from there.

Automating the response half

Microsoft Sentinel playbooks are Azure Logic Apps workflows. They run automatically from an automation rule, or manually against an entity or alert. The role model is where teams get stuck. Microsoft Sentinel Playbook Operator lets a user run a playbook manually. Microsoft Sentinel Responder lets a user open an incident but does not let them run the playbook. Microsoft Sentinel Automation Contributor must be granted to the Sentinel service account on the resource group holding the playbooks, otherwise automation rules silently cannot invoke them. Microsoft has stated that Sentinel in the Azure portal is not supported after 31 March 2027.

Cortex XSOAR models the same idea with typed tasks: standard, conditional, data collection and section headers, with inputs and outputs passed through incident context. Commands look like !file for generic indicator enrichment and !ADGetUser for the Active Directory integration. Different vendor, same decision tree.

Technique

ID

Playbook trigger

Permission Groups Discovery, Domain Groups

T1069.002

Sigma rule above

Account Discovery, Domain Account

T1087.002

net user /domain in the baseline query

Domain Trust Discovery

T1482

nltest /domain_trusts

Remote System Discovery

T1018

net view /domain

Summary

A playbook is a workflow of security actions with a defined trigger, defined steps and a defined owner. CACAO 1.1 gives it a schema and seven types, NIST SP 800-61r3 gives it a place in the Detect, Respond and Recover lifecycle, and PEAK gives the hunting variant its Prepare, Execute, Act structure. Templates describe intent. Executable playbooks name the tool, the role and the API. Write both, and never confuse one for the other in a tabletop.

Collect for playbook coverage:
  Security 4688 (with ProcessCreationIncludeCmdLine_Enabled)
  Sysmon 1 (process creation)
  Sysmon 3 (network connection)
  Security 4624 / 4625 (logon success and failure)
  PowerShell/Operational 4104 (PowerShell script block logging)

Review points before calling a playbook executable:
  named approver for containment actions
  named tool and API endpoint per step
  rollback step for every mitigation step
  version id and modified timestamp under change control

Starting points in the catalog: /rules?q=discovery.

Related articles