What Is a Detection Playbook?

vssadmin.exe delete shadows /all /quiet runs on a file server at 03:12. The rule fires. The analyst on shift has been awake for nine hours and has never seen this alert before. What happens in the next four minutes decides whether this is a contained incident or a full domain encryption event.

A detection playbook is the document that decides it. It is written months earlier, by someone unhurried, and it answers one question: this alert fired, now what.

Playbook, runbook, IR plan

These three get used interchangeably and they are not the same artifact.

A runbook is an operational procedure. How to restart the log forwarder, how to rotate a service account, how to onboard a new sensor. It is written for whoever operates the platform and it has nothing to say about adversaries.

An incident response plan is organisational. It names the incident commander, the legal contact, the notification clock for a regulator, the criteria for declaring a Sev 1. It is read by executives and lawyers roughly once a year and during a crisis. It does not contain a single query.

A detection playbook sits underneath both and is bound to one alert. It is written for the analyst who has the alert open right now, and every line in it is either a query they can paste, a criterion they can evaluate, or an action they are allowed to take. If a playbook contains a paragraph the analyst does not act on, cut the paragraph.

Anatomy

A playbook that works has seven parts, in this order.

1. The alert it belongs to. One rule, one playbook, by rule ID. A playbook covering "all ransomware alerts" is a wiki page, not a playbook.

2. What the rule actually detects, in behaviour terms, and what it does not. The blind spots matter more than the coverage. An analyst who thinks the rule sees everything will stop looking too early.

3. The first three enrichment queries, with the query text verbatim. Not "check the parent process". The literal SPL or KQL, with placeholders for host and time.

4. A decision tree with explicit disposition criteria. What makes this a true positive. What makes it benign. Named conditions, not judgement calls.

5. Containment actions and who is authorised to take them. An action nobody on the night shift can authorise is not a containment action.

6. The escalation trigger. One sentence, evaluable at 03:12.

7. Review date, tied to the rule's review date.

Worked playbook: shadow copy deletion

Alert: shadow copy deletion via operating system utilities. This maps to the SigmaHQ rule c947b146-0abc-4c87-9c64-b17e9d7274a2, ATT&CK T1490 (Inhibit System Recovery).

What it detects, and what it does not

The rule matches process creation events where the image is vssadmin.exe, wmic.exe, powershell.exe, pwsh.exe or diskshadow.exe and the command line contains both shadow and delete. It has two more branches: wbadmin.exe with delete, catalog and quiet, and vssadmin.exe with resize and shadowstorage plus either unbounded or /MaxSize= (resizing storage to a tiny value evicts every existing copy without ever calling delete).

What it does not detect:

• Deletion through the VSS COM API directly from malware, with no child process. There is no process creation event to match.

• REAgentC.exe /disable, which turns off the Windows Recovery Environment. Same objective, different binary, not in this rule.

• A renamed vssadmin.exe, unless your pipeline populates OriginalFileName. The rule checks both Image|endswith and OriginalFileName, so Sysmon Event ID 1 covers this and bare Security 4688 does not.

• Any of it, if command-line logging is off. Security Event ID 4688 carries a command line only when "Include command line in process creation events" is enabled. Confirm this before you trust the playbook.

The first three queries

Query one, the parent chain. The command is never interesting. The thing that spawned it always is.

index=windows source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  host=$HOST$ earliest=-30m latest=+10m
| table _time, User, ParentImage, ParentCommandLine, Image, CommandLine, ProcessGuid
| sort _time

Query two, the neighbourhood. Shadow copy deletion arrives with company: service stops, bcdedit calls, a dropper writing to C:\Users\Public.

DeviceProcessEvents
| where DeviceName startswith "$HOST$"
| where Timestamp between (datetime($ALERT_TIME$) - 30m .. datetime($ALERT_TIME$) + 10m)
| project Timestamp, AccountName, InitiatingProcessParentFileName, InitiatingProcessFileName,
          InitiatingProcessCommandLine, FileName, ProcessCommandLine
| order by Timestamp asc

Query three, fleet prevalence. This is the query that decides disposition more often than the other two combined.

DeviceProcessEvents
| where Timestamp > ago(90d)
| where FileName =~ "vssadmin.exe" and ProcessCommandLine has "delete"
| summarize Runs = count(), Hosts = dcount(DeviceName), FirstSeen = min(Timestamp)
    by InitiatingProcessFileName, InitiatingProcessFolderPath
| order by Runs desc

If the parent is a backup agent that has run this 4,000 times across 300 hosts since January, you are looking at your own backup software. If the parent has one execution in 90 days, you are not.

Disposition criteria

Benign, close the alert, when all of these hold:

• The parent process is a signed backup or imaging agent from an inventoried install path, and query three shows it running the same command line on more than one host over more than 30 days.

• The executing account is a service account, not an interactive user.

• Query two shows no process creation in the surrounding hour outside that agent's own process tree.

True positive, escalate, when any of these hold:

• The parent is cmd.exe, powershell.exe, wscript.exe, mshta.exe, rundll32.exe or an unsigned binary, and query three shows the command line is rare or new in the estate.

• The same account ran wbadmin delete catalog, bcdedit /set {default} recoveryenabled no or a service stop against a database or backup service within the same hour.

• The host had a RemoteInteractive or Network logon from an internal IP that is not the admin jump host, in the two hours before.

Everything else is the third bucket. Not benign, not confirmed, and it goes to the tier 2 queue with the three query outputs attached. The bucket must exist. Playbooks that force a binary call at 03:12 get the call wrong.

Containment and authority

• Isolate the host from the network. Tier 1 analyst, no approval needed, at any hour. This is the whole point of pre-authorising it.

• Disable the executing account. Tier 1 for standard user accounts. Service accounts and admin accounts need the on-call IR lead, because disabling a backup service account at 3am is its own outage.

• Kill the process tree and quarantine the parent binary. Tier 2 or IR on-call.

• Take a memory image before isolation if the host is a domain controller. IR on-call only.

Escalation trigger

Page the IR on-call if the same command line appears on a second host within 15 minutes, or if the host is a domain controller, backup server or hypervisor. Two hosts means it is scripted, and scripted means the rest of the estate is minutes away.

The disposition criteria are the hard part

Compare the shadow copy playbook to one for suspicious LSASS access. The Sigma rule 5ef9853e-4d0e-4a70-846f-a9ca37d876da (T1003.001, OS Credential Dumping: LSASS Memory) matches Sysmon Event ID 10 where TargetImage ends with \lsass.exe, GrantedAccess contains 0x1038, 0x1438, 0x143a or 0x1fffff, and CallTrace contains one of dbgcore.dll, dbghelp.dll, kernel32.dll, kernelbase.dll or ntdll.dll.

Note what is commented out in that rule upstream: 0x1010, 0x1400, 0x1410, 0x01000 and 0x40, all removed for false positive volume. That is a detection engineering decision with a direct playbook consequence. Your rule will not fire on a tool that opens LSASS with 0x1010, so the LSASS playbook needs a hunting step the shadow copy playbook does not, and its benign criteria have to name the EDR and AV agents in your estate by path. A playbook written without reading the rule's own exclusion list will send analysts hunting for something the rule already decided to ignore.

Playbooks rot faster than rules

A rule breaks when the log source changes. A playbook breaks when anything changes: the SIEM query language, a table rename, the EDR's isolation button moving, the on-call rota, the name of the backup agent. Rules have a compiler of sorts, in that a broken query usually errors. A playbook that says "check the parent process in the Advanced Hunting console" keeps reading fine long after the console was replaced.

The fix is unglamorous. Give every playbook the same review date as the rule it belongs to, and review them in the same sitting. When the rule's modified date moves, the playbook's does too, or the change is not finished. Detection content and response content are one unit of work, which is the argument made at more length in what is detection engineering.

And be honest about what a playbook is until it has been used. A playbook nobody has executed during a drill is a document, not a capability. Run the alert on purpose. The Atomic Red Team atomics for T1490 will fire the shadow copy rule in a lab. Hand the resulting alert to an analyst who did not write the playbook, time them, and watch where they stall. The stall is the defect. In our own drafts the stall lands on the disposition criteria, because the person writing the queries already knows which fields matter and does not write down why.

Summary

A detection playbook is bound to one alert and contains only things an analyst acts on: what the rule sees and misses, three enrichment queries in full, named disposition criteria, pre-authorised containment, and an escalation trigger. It is not a runbook and not an IR plan. Its review date belongs to its rule, because it decays faster than the rule does. And it is a document rather than a capability until someone who did not write it has been timed running it.

Browse the Windows detections in the catalog at /rules?domain=windows and the impact-stage rules at /rules?q=shadow copy. Every rule you adopt needs one of these written before it goes to production, not after the first page.

Event sources this playbook assumes are collected:

Sysmon Event ID 1    Process creation (Image, OriginalFileName, CommandLine, ParentImage, ParentCommandLine, User)
Sysmon Event ID 10   ProcessAccess (SourceImage, TargetImage, GrantedAccess, CallTrace)
Security 4688        Process creation, with command-line auditing enabled
Security 4624        Logon, for LogonType 3 and 10 correlation
System 7045          Service installation
PowerShell 4104      Script block logging