Ransomware Response: The Decisions That Matter in the First 24 Hours

Stop thinking timeline, start thinking decisions

Most ransomware guides give you a tidy timeline: detect, contain, eradicate, recover. Real incidents do not unfold in phases. They unfold as a small number of high-stakes decisions made under pressure, with incomplete information, often at night. Get those decisions right and the timeline sorts itself out. Get them wrong and no timeline saves you.

Here are the ones that matter in the first 24 hours, in the order they usually hit.

Decision 1: Isolate now, or observe first?

The reflex is to pull every cable the moment encryption is spotted. Sometimes that is right. Sometimes it destroys your best options.

Isolate immediately when encryption is actively spreading, domain controllers or backup infrastructure are not yet hit, or you have no EDR visibility. Every minute of hesitation is measured in encrypted servers. Isolate at the network level (switch ports, VLAN ACLs, EDR network containment), and think hard before powering machines off: memory holds encryption keys for some families, running processes, and the attacker's tooling. A hard shutdown is evidence destruction.

Observe briefly when encryption appears complete and the attacker may still be in the environment. If you sever access instantly and loudly, you confirm detection, and any chance of watching their C2 channels, identifying their access path, or capturing tooling evaporates. This is a judgment call measured in hours at most, made together with whoever owns risk, not by an analyst alone.

Whichever you choose, one action is unconditional: get backup infrastructure off the network first. Modern operators hunt backup servers deliberately, and repositories that survive the first pass often die in the second.

Decision 2: Verify backups before you promise anything

Every downstream choice, including whether payment even enters the conversation, depends on one question: do usable backups exist? Answer it with evidence, not the backup dashboard.

• Are the backups themselves encrypted or deleted? Attackers commonly dwell for days and target repositories, snapshots and shadow copies before triggering encryption. Check the repositories directly, from a clean machine.
• Do restores actually work? Pick a critical system and test-restore it to isolated hardware now. A backup that has never been restored is a hypothesis.
• How far back must you go? If dwell time was two weeks, last night's backup may contain the attacker's persistence. Establish the intrusion date before choosing a restore point.
• What is the real restore throughput? Restoring 200 TB over a 10 Gb link has a fixed physics problem. Compute the honest number of days before leadership hears "we have backups" and mentally files the incident as solved.

Write the answers down. "Backups: verified, clean as of the 14th, 4 days to restore Tier 1" is the single most valuable sentence of day one.

Decision 3: Identify the strain

Identification is cheap and changes everything after it. Collect the ransom note, the encrypted-file extension, and hashes of any binaries or scripts left behind, then look the hashes up on mlab.sh to identify the family and pull related IOCs for scoping.

What identification buys you:

Decision 4: Scope encryption and exfiltration separately

Encryption is loud; you can enumerate what is locked. Exfiltration is quiet, and it is the half that follows you for years. Most established operators steal data before encrypting, then extort twice.

Scope them as two separate workstreams:

• Encrypted: which systems, which shares, which databases. Drives downtime and restore priorities.
• Exfiltrated: examine egress logs, NetFlow, proxy data for large outbound transfers in the days before detonation. Look for staging archives (.7z, .rar in temp directories), tools like Rclone or MEGA clients, and connections to file-sharing services nobody sanctioned.

Absence of evidence here is weak evidence of absence, especially with thin logging. If the strain you identified belongs to a group that runs a leak site, assume exfiltration until disproven, and say so internally in exactly those words.

Decision 5: Start the clocks you do not control

Several countdowns start at discovery whether you acknowledge them or not:

• GDPR: 72 hours to notify your supervisory authority once aware of a personal data breach, and ransomware with possible exfiltration almost always qualifies. You do not need full facts to notify; the regulation explicitly allows notification in phases. Missing the deadline because "the investigation was ongoing" is not a defense.
• Sectoral regimes (NIS2, DORA for financial entities, national health rules) can impose earlier initial notifications, some as short as 24 hours.
• Cyber insurance: most policies require prompt notice and use of approved vendors. Engaging the wrong forensics firm on day one can jeopardize coverage.
• Law enforcement: report early. Agencies sometimes hold decryption keys from infrastructure takedowns, and a report strengthens your regulatory position.

Get legal counsel into the incident channel within hours, not days, and route breach determinations through them.

Decision 6: The payment question, handled like adults

Someone senior will ask about paying. Prepare the honest briefing rather than a lecture:

• Payment buys a decryptor of unknown quality. Decryptors are typically slow, single-threaded, and fail on some files. Recovery-by-decryptor is still a weeks-long project.
• Payment does not delete stolen data. You are trusting a criminal enterprise's brand management.
• Sanctions exposure is real: if the group or its affiliates are sanctioned, payment can itself be an offense. This is a legal determination, not an IT one.
• If negotiation happens at all, it happens through experienced negotiators, brought in via counsel and the insurer. Negotiation also buys something underrated: time for restoration work, and proof-of-decryption plus proof-of-data samples that sharpen your scoping.

The organizations that navigate this well made the core decision in a tabletop exercise months earlier, not live on a bridge call at 2 a.m.

Decision 7: Rebuild trust, not just systems

The instinct after containment is to restore fast. Restoring into an environment the attacker still occupies produces the second encryption event, and second events are reputationally far worse.

Before recovery accelerates, gate it on:

• Access vector closed. If you have not found how they got in, you have not closed it. Patch the appliance, kill the exposed RDP, reset the phished account.
• Credentials rotated from a position of strength. Assume domain credentials are compromised. Reset privileged accounts first, then service accounts, then a staged reset of everything, including the krbtgt account (twice, respecting replication).
• Persistence hunted. Scheduled tasks, new services, rogue accounts, webshells, modified GPOs. Restored systems get scrutinized before rejoining the network, and rebuilt gold images beat cleaned images.
• Monitoring before reconnection. Every restored system comes back behind EDR and logging you now actually watch.

Keep the decision log or lose the incident twice

Every decision above, who made it, when, and on what information, belongs in a timestamped log from hour one. Regulators, insurers and lawyers will reconstruct your incident later; the version written live always beats the version remembered. This is exactly what mlab IR is built for: a self-hosted incident workspace with timeline tracking, task assignment and evidence handling, so the record builds itself while your responders work instead of reconstructing it during litigation. Self-hosted matters here: your incident data stays yours, in your infrastructure, mid-crisis.

Ransomware response is seven decisions made in the right order with written evidence. Decide them calmly now, in an exercise, or expensively later, on the worst call of your year.