Ransomware Response Playbook
From the first encrypted file to negotiation decision to recovery — the full ransomware playbook with timing, decision gates, and the specific steps most organizations get wrong.
3:12 AM. EDR fires 400 alerts in 90 seconds: ransomware encryption activity on the finance VLAN. By 3:14, the help desk phone starts ringing. By 3:18, the SOC has confirmed it's LockBit — recognized by the file extension and ransom note format. They have 47 affected hosts with active encryption. 230 more hosts on adjacent VLANs that may or may not be affected. And a decision to make: isolate everything now — including systems critical for payroll processing in 6 hours — or take a surgical approach and risk more encryption. This playbook walks the full sequence.
Phase 1: Immediate Actions (T+0 to T+30 minutes)
Ransomware Triage Decision Tree
═══════════════════════════════════════════════════════════════════
T+0: Alert fires or user reports
│
▼
Confirm ransomware (not AV false positive):
→ File extension changed? Ransom note present?
→ EDR shows encryption activity (high I/O to many files)?
│
├── NO → continue standard triage
└── YES → IMMEDIATE RANSOMWARE RESPONSE
│
├── Is encryption still active? (files being changed right now)
│ YES → Isolate ALL actively encrypting hosts immediately
│ Do not wait for scope — stop active damage first
│
└── Encryption appears stopped?
→ Scope before contain (see below)
Risk: some encrypted hosts may still be beaconing
Use EDR telemetry to find any hosts with active C2
Then: simultaneous containment of all confirmed hosts
# Quick triage: identify actively encrypting hosts via EDR file event telemetry
# (Run in EDR search console or SIEM, not on the compromised host)
# For a Sysmon environment: look for file creation events with ransomware extensions
# Common LockBit extension: .lockbit, .abcd; Ryuk: no extension change but README note
# This query finds hosts creating >100 new files with same extension in 5 minutes:
# Splunk example:
# index=windows_sysmon EventCode=11 earliest=-10m
# | rex field=TargetFilename "\.(?P[a-zA-Z0-9]{4,10})$"
# | stats dc(TargetFilename) as file_count by host, ext
# | where file_count > 100 AND ext != "tmp" AND ext != "log"
# | sort -file_count
# PowerShell on a suspected host — is it encrypting right now?
$recentChanges = Get-ChildItem C:\Users -Recurse -File -ErrorAction SilentlyContinue |
Where-Object { $_.LastWriteTime -gt (Get-Date).AddMinutes(-5) } |
Group-Object Extension | Sort-Object Count -Descending | Select-Object -First 5
$recentChanges | Format-Table -AutoSize
# If you see >50 files with a .lockbit/.encrypted/.enc extension in last 5 min → active encryption Full Playbook Steps
| Time | Action | Owner | Decision required |
|---|---|---|---|
| T+0:00 | Confirm ransomware, P1 declared, IR lead paged | SOC on-call | No — automatic |
| T+0:05 | Call CISO. Call external IR retainer hotline. | IR lead | No |
| T+0:10 | Switch to out-of-band communication (Signal/phone) | IR team | No — mandatory |
| T+0:15 | Identify actively encrypting hosts — EDR telemetry sweep | EDR analyst | No |
| T+0:20 | Isolate all confirmed-encrypting hosts simultaneously | EDR team | No — automatic at this stage |
| T+0:30 | Scope: how many hosts are confirmed? How many are at risk? | IR lead | No — scoping task |
| T+1:00 | Identify the ransomware family (ransom note, file extension, behavior) | Threat intel | No |
| T+1:00 | Check for decryptors at nomoreransom.org | Threat intel | No |
| T+1:30 | Identify initial access vector — how did they get in? | IR forensics | No — critical for recovery |
| T+2:00 | First SITREP to leadership | IR lead | No |
| T+4:00 | Decision: pay ransom? Requires CISO + CEO + Legal + insurance | CISO/C-suite | YES — executive decision |
| T+6:00 | Eradication: full persistence hunt across all affected hosts | IR forensics | No |
| T+12:00 | Recovery planning: clean backup inventory, restoration sequence | IR + IT | Yes — which backup? |
| T+24:00 | Begin restoring from clean backups, Phase 1 systems | IT / Infra | Yes — authorization to restore |
The Ransom Payment Decision
Whether to pay a ransom is a business, legal, and security decision — not an IT decision. The IR team provides input; executives decide.
| Factor | Favors paying | Favors not paying |
|---|---|---|
| Backup availability | No clean backup available; data is irreplaceable | Clean backup available; restoration is faster than negotiation + decryption |
| Decryptor reliability | Ransomware group has known reliable decryptors (check threat intel) | Group known to take payment and not provide decryptors; or decryptor is slow/partial |
| OFAC sanctions | N/A if group is not sanctioned | Group is on OFAC SDN list — payment may be a federal crime |
| Insurance coverage | Cyber insurance covers ransom payment; reduces net cost | Insurance does not cover ransom; full payment is out-of-pocket |
| Data exfiltration | Paying may prevent threatened data leak ("double extortion") | No guarantee attacker deletes data even after payment |
| Business continuity | Ransomware-impacted systems are mission-critical; every hour is massive revenue loss | Business can operate degraded; restoration timeline is acceptable |
Every factor in the ransom payment decision changes dramatically when you have a clean, tested backup. With a good backup, you restore regardless of whether the decryptor is reliable. You avoid OFAC risk entirely. Your insurance claim is simpler. Your recovery timeline is predictable. And you deprive the attacker of leverage. Organizations that invest in offline, immutable backups tested regularly with restore drills are fundamentally different ransomware victims than organizations without them. The backup infrastructure investment is always worth it — measured against the cost of even one ransomware event.
Q & A
Q: You've identified the ransomware as LockBit 3.0. There's no free decryptor. Backups are 45 days old. Business is pushing to pay. What is your recommendation?
Present the full picture, not a recommendation that circumvents the business decision: "We have three options. Option 1: Pay. Current LockBit ransom demands for organizations of our size are typically $500k-$2M. We would need to negotiate, pay in cryptocurrency, and wait for the decryptor — typical decryption time for 200 hosts is 2-5 days after payment. Success rate is approximately 85% for LockBit (decryptor works but is slow). Option 2: Restore from 45-day backups. Data loss is 45 days. Restoration timeline estimate is [X days] based on our backup restore speed. Option 3: Restore partial data from 45-day backup and selectively pay for decryption of specific high-value data we can't recover. My recommendation is Option 3 if the 45-day data loss is acceptable for most systems, to minimize the ransom paid while recovering the critical recent data. But this is your decision — I need a yes or no within 4 hours so we can start restoration."
Q: You paid the ransom. The decryptor is working but extremely slow — estimated 10 days to decrypt all files. The business wants the files faster. Anything you can do?
Several things: (1) Prioritize critical systems in the decryption queue — most decryptors let you specify which directory to decrypt first. Run decryption on the highest-priority systems first. (2) Run multiple decryptor instances in parallel — if the decryptor allows it, run it on separate machines simultaneously on different file sets. (3) Restore the most critical data from the 45-day backup in parallel and accept some data loss for those systems rather than waiting for decryption. (4) Contact the ransomware group's negotiation channel — sometimes they will provide a faster decryptor or technical support when the recovery is going slowly. This is distasteful but is a real option when you've already paid. The external IR firm (if engaged) typically manages this communication.