IR Playbook: Ransomware Response Procedures

NIST SP 800-61 defines four phases for incident handling: Preparation; Detection and Analysis; Containment, Eradication, and Recovery; and Post-Incident Activity. Ransomware compresses the middle phases together in practice — you are often containing spread and beginning eradication simultaneously, on hosts that are still actively encrypting data. Treating the framework as a strict sequence rather than a set of overlapping workstreams is one of the most common planning mistakes.

The value of anchoring to a named framework isn't academic. It gives responders, legal counsel, and executives a shared vocabulary during a stressful event, and it makes after-action reviews measurable against a recognized standard rather than an ad hoc checklist invented under pressure.

• •Preparation — tooling, backups, playbooks, and contracts in place before an incident
• •Detection and Analysis — confirming an incident is occurring and scoping it
• •Containment, Eradication, and Recovery — stopping the spread, removing the actor, restoring operations
• •Post-Incident Activity — root cause analysis and playbook improvement

Ransomware response quality is set months before the ransom note appears. Organizations that recover quickly almost always share the same baseline: tested, immutable or offline backups; an incident response plan that has been rehearsed with a tabletop exercise; and pre-negotiated relationships with an IR firm, outside counsel, and the cyber insurance carrier so those calls aren't being made cold at 2 a.m.

• •Immutable or air-gapped backups with regularly tested restore procedures, not just backup jobs that 'complete successfully'
• •An up-to-date asset and network inventory — you cannot contain hosts you don't know exist
• •EDR or equivalent endpoint visibility deployed fleet-wide, not just on servers
• •A written incident response plan with defined roles, escalation paths, and decision authority for high-impact calls
• •Pre-established retainer or contact with an external IR firm, breach counsel, and the cyber insurance carrier
• •An out-of-band communications channel (not on the potentially compromised network) for the response team

Most ransomware detections start noisy: a flood of file-modification alerts, a spike in CPU/disk I/O across multiple hosts, missing shadow copies, or a ransom note dropped in shared folders. The instinct is to start pulling plugs immediately — but a few minutes spent scoping pays for itself. You need to know how many hosts are affected, whether encryption is still in progress or already complete, and whether the initial access point is still active before you can contain effectively.

Shadow copy deletion is a strong early indicator worth hunting for specifically, since most ransomware families disable Windows Volume Shadow Copy Service backups before encrypting to prevent easy recovery.

• •Identify patient zero and the likely initial access vector (phishing, exposed RDP, VPN vulnerability, compromised credentials)
• •Determine how many hosts show encryption activity versus staged/pre-positioned access
• •Check for shadow copy or backup deletion commands (vssadmin, wbadmin, bcdedit) executed near the time of impact
• •Preserve volatile evidence (memory, running process list, network connections) on a representative sample of affected hosts before remediation

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1} |
  Where-Object { $_.Message -match 'vssadmin|wbadmin|bcdedit|wmic shadowcopy' } |
  Select-Object TimeCreated, Message

Containment decisions in ransomware cases involve a real trade-off between stopping the spread and preserving evidence. Powering off a host that is actively encrypting stops the damage on that machine but destroys the contents of RAM, which may hold the encryption process, injected code, or credentials used for lateral movement. Where feasible, prefer network isolation (EDR isolation, VLAN quarantine, or physically unplugging the network cable) over powering down, and capture memory on a small set of representative hosts before remediating them.

• •Isolate affected hosts at the network layer rather than powering them off, where time allows
• •Disable or reset credentials suspected of being used for lateral movement, prioritizing privileged and service accounts
• •Block identified command-and-control infrastructure at the perimeter and DNS layer
• •Segment backup infrastructure immediately — backups are a common secondary target
• •Capture memory images from a representative sample of hosts before reimaging

Do not trust a cleaned host. The standard practice is reimaging from known-good media rather than attempting to remove malware from a compromised system, because you cannot be fully confident every persistence mechanism, backdoor, or credential-harvesting artifact has been found. Recovery should restore from backups that have been verified as clean and predate the compromise, with hosts reconnected in stages rather than all at once so reinfection is caught early rather than after it has spread again.

• •Reimage compromised hosts from trusted media rather than attempting in-place remediation
• •Verify backups are free of the same indicators of compromise before restoring from them
• •Rotate all credentials that may have been exposed, not just ones with confirmed use
• •Patch or remediate the confirmed root cause before reconnecting affected segments
• •Reconnect systems in stages with heightened monitoring, not all at once

Ransomware response is not a purely technical exercise. Engaging outside breach counsel early is standard practice partly because it can extend attorney-client privilege over the investigation. Cyber insurance policies frequently specify which IR firms and vendors are pre-approved, so confirming coverage requirements before engaging outside help avoids reimbursement disputes later. Whether to pay a ransom is a business and legal decision — it carries regulatory and, in some cases, sanctions-related considerations that vary by jurisdiction, so it should never be made unilaterally by the technical team without legal input.

External communications discipline matters as much as the technical response: assume attacker visibility into email and chat systems until proven otherwise, and route sensitive discussion through an out-of-band channel.

The post-incident review is where most organizations either learn from the event or set themselves up to repeat it. A structured lessons-learned session — covering what was detected, how long it took, what worked, and what didn't — should feed directly back into the incident response plan, detection rules, and backup strategy. Track basic metrics like time to detection and time to containment across incidents so improvement is measurable rather than anecdotal.

• •Document root cause and the full attack timeline while details are still fresh
• •Update detection rules and the IR playbook based on gaps identified during the response
• •Track time-to-detect and time-to-contain metrics across incidents to measure improvement
• •Confirm any regulatory or contractual notification obligations with legal counsel — requirements vary significantly by jurisdiction and industry

The same handful of mistakes show up repeatedly in post-incident reviews across the industry.

• •Rebooting or shutting down encrypting hosts before capturing volatile evidence
• •Restoring from backups without first confirming they aren't also compromised
• •Communicating about the incident over the same email or chat platform the attacker may control
• •Treating the ransom-payment decision as purely technical rather than looping in legal and insurance
• •Reconnecting all systems at once instead of staging recovery with monitoring in place
• •Skipping the post-incident review once systems are back online