Ransomware incident response: the first 24 hours

The call comes in before the coffee's cold: file servers are throwing access errors, a finance machine has a README_RESTORE.txt on the desktop, and someone's phone is already ringing with a ransom demand. The instinct in the room is to do something drastic — pull every plug, or start negotiating. Both can make the next 24 hours worse.

Ransomware is the one incident where the pressure to act fast and the need to act carefully are most directly at odds. Power a machine off and you lose the memory that holds the encryption keys and the attacker's tooling. Restore too early and you re-encrypt into a still-compromised network. Pay too quickly and you may breach sanctions law. This is a containment-and-evidence-first playbook for the first 24 hours — grounded in NIST SP 800-61 and SANS PICERL — built so that the decisions you make under pressure are ones you can still defend a month later to an insurer, a regulator, or a board.

Two clocks are running

From minute one you're managing two clocks at once. The operational clock — how fast can we get the business back — and the evidence clock — how much of what happened can we still prove. Most ransomware response goes wrong when the operational clock stampedes the evidence one: machines wiped and rebuilt before anyone captured what the attacker did, leaving you unable to answer whether data was stolen (the question that drives every breach-notification and insurance obligation you have).

The ordering below protects both: contain to stop the spread, preserve before you destroy, scope before you recover.

Hour 0–1: Confirm and isolate — do not power off

First, confirm it's actually ransomware and not a failed update or a single rogue machine. Then move immediately to stop lateral spread — but isolate, don't shut down:

• Isolate at the network layer. Pull affected hosts off the network (disable the switch port, or use your EDR's isolate function such as Microsoft Defender for Endpoint's Isolate device) rather than powering them off. A running machine still holds volatile evidence — encryption keys in memory, the malware process tree, live network connections. Powering off throws that away.
• Protect the crown jewels first. If encryption is still spreading, prioritise isolating domain controllers, backup servers, and hypervisors over individual workstations. Ransomware crews specifically target backups before detonating.
• Start the clocks that matter legally. Notify your cyber insurer (many policies require notification within hours and have a panel of approved responders), and loop in legal early — breach-notification deadlines may already be ticking.

The output of this hour: the spread is stopped, nothing has been destroyed, and the right people know.

Hour 1–4: Preserve, then triage the entry point

Before you change anything on an affected host, capture it. For the patient-zero and a representative sample of encrypted machines, take a disk image and, where feasible, a memory capture — while they're still powered on and isolated. This is the evidence that later proves scope, dwell time, and whether data left the building.

Ransomware is almost never the first thing that happened — it's the last. The encryption is the end of a chain that usually started with a phished credential or an exposed service days or weeks earlier, then moved laterally through Active Directory. Identifying that chain is what stops the attacker simply re-encrypting after you recover. The AD ransomware-precursor playbook covers the lateral-movement sequences (Kerberoasting, DCSync, ticket attacks) to hunt for here; if the entry was a stolen identity, the credential-compromise first-hour playbook is the parallel thread to run.

Hour 4–8: Scope the blast radius and identify the strain

Now answer the four questions leadership will ask: how did they get in, how far did they get, was data taken, and is it still happening?

1. Identify the variant. The ransom note, the encrypted-file extension, and a sample (uploaded to a service like ID Ransomware) often identify the strain — which tells you the known TTPs, whether a free decryptor exists, and whether this group practises data theft.
2. Find patient zero and the dwell time. Work back from the first encrypted file's timestamp to the initial access event. Dwell time — how long they were in before detonating — tells you how much to distrust.
3. Hunt for exfiltration. Modern ransomware is double extortion: they steal before they encrypt. Look for large outbound transfers, archiving tools (7z, rclone, WinRAR), and traffic to cloud-storage or file-sharing hosts in the days before detonation. Whether data was exfiltrated is the single fact that most changes your legal exposure.

A Defender advanced-hunting query for the mass-encryption moment helps pin the timeline and the spread:

DeviceFileEvents
| where Timestamp between (datetime(2026-06-04) .. datetime(2026-06-05))
| where ActionType == "FileRenamed" or ActionType == "FileModified"
| summarize changed = count() by DeviceName, bin(Timestamp, 5m)
| where changed > 500
| order by Timestamp asc

Hour 8–16: Eradicate — remove the access, don't just remove the malware

Recovering before you've removed the attacker's access is how organisations get encrypted a second time mid-recovery. Eradication means closing the door they came in and any they propped open:

• Reset credentials at scale — privileged accounts first. In an Active Directory compromise, reset the krbtgt account twice (with a delay between) to invalidate forged Kerberos tickets, and assume every cached credential on a touched host is burned.
• Remove persistence — the scheduled tasks, new service accounts, GPO modifications, and remote-access tooling the crew left behind.
• Validate your backups before you trust them. Confirm you have backups that are offline or immutable, that they pre-date the initial compromise (not just the encryption), and that they're themselves clean. Test-restore in isolation first.

Hour 16–24: Recover in the right order — and decide on the ransom

Recovery is phased, not a big-bang restore. Bring back domain controllers and core identity first, into a network segment you've confirmed clean, then critical business systems, monitoring continuously for any sign of re-encryption. Keep the isolated environment isolated until you're confident the access is gone.

On the ransom itself: that's a business and legal decision, not a technical one, and it belongs with leadership, legal, and your insurer — not made in the heat of hour two. One hard constraint worth stating plainly to decision-makers: paying can carry sanctions exposure (in several jurisdictions, paying a sanctioned group is itself unlawful), and a decryptor, if you get one, is often slow and imperfect. Clean backups are almost always the faster path back.

The decisions you'll have to defend

When the dust settles, the questions come from people who weren't in the war room: an insurer deciding whether to pay out, a regulator asking whether personal data was exposed, a board asking what happened. Every answer depends on evidence you either preserved in hour two or lost. Hashing each artefact, logging who touched it, and keeping an unbroken chain of custody is what turns “we think no data left” into a defensible statement — the chain-of-custody guide covers how to do that to a standard that survives legal review.

Running this consistently with tooling

A ransomware incident is the worst possible time to be coordinating a response across spreadsheets and chat threads. The work that decides the outcome — preserving evidence, scoping lateral movement, sequencing recovery, recording every containment action — is exactly the work that gets dropped when a dozen people are firefighting at once.

This is where a single investigation workspace earns its place. In CICADA IR, the incident lives in one case: evidence is collected with a chain of custody from the first action, events from every source land on one timeline so you can see the spread and reconstruct dwell time, and entity pivots let you trace the lateral movement from patient zero across the estate. Containment actions — isolating a host, disabling an account — run through an approval gate and an append-only audit trail, so the destructive decisions made at 3 a.m. are defensible at the inquiry. Because it's self-hosted, it keeps working even when the environment it's investigating is compromised, and the case data never leaves your network.

See Getting Started to set it up, or the companion guides on detecting AD ransomware precursors and PCAP-driven IR for the threads that feed this one.