Ransomware Response Playbook
Ransomware is the incident most interviewers will walk you through, because it touches everything at once: detection, containment, identity, backups, legal, executives and the question "do we pay?". Modern ransomware is double extortion: the attackers steal data first, then encrypt, so restoring from backup fixes only half the problem. This page is the playbook, hour by hour, with the decisions you will be asked to defend.
Last verified2026-10
What Modern Ransomware Looks Like
What is this?A ransomware attack is usually run by an affiliate renting a group's malware and leak site (ransomware-as-a-service). The encryption is the last step of an intrusion that took days or weeks.
-
Initial accessAccessday 0
- Exploited VPN or edge device, stolen credentials without MFA, help-desk social engineering, infostealer logs
-
Discovery and privilege escalationSpreaddays
- AD enumeration, credential dumping, domain admin; remote tools like AnyDesk installed
-
ExfiltrationStealhours to days
- Rclone or MEGA uploads, often at night; this is what the leak-site threat is based on
-
Kill recoverySabotageminutes before
- Delete shadow copies and backup catalogues, disable EDR, target hypervisors (ESXi)
-
Mass encryptionEncryptminutes
- Pushed via group policy, PsExec or hypervisor; ransom note with a Tor chat link and deadline
Memory hookencryption is the alarm bell, not the break-in. By the time files are encrypted, the attacker has had admin rights for days and already has your data. So the investigation has two halves: recover the systems and answer what was taken and how they got in. Skip the second half and they come back through the same door.
The First 24 Hours
How it works
-
Declare and assembleMobilisehour 0–1
- Incident commander, IR team, IT ops, legal, comms, executives; out-of-band channel (attackers may read Teams and email)
- Call the cyber insurer early: many policies require it and appoint the IR firm and counsel
-
Stop the spreadContainhour 0–4
- Isolate affected hosts and segments via EDR or switch ports; don't power off (memory holds evidence and sometimes keys)
- Disable compromised accounts, reset privileged credentials, block attacker remote tools and C2 at the firewall
- Take backups offline if they are still intact
-
Work out what happenedScopehour 2–24
- Which systems are encrypted, which ransomware family, how they got in, what was exfiltrated and when
- Preserve evidence: memory, EDR telemetry, firewall and VPN logs, the ransom note
-
Business decisionsDecidehour 4–24
- Restore priorities, regulatory notifications, whether to engage the attacker, customer and staff comms
In practiceWhat the early evidence usually looks like:
# EDR timeline on a file server, abridged
02:11 svc_backup cmd.exe vssadmin delete shadows /all /quiet ← recovery sabotage: minutes before encryption
02:12 svc_backup cmd.exe wbadmin delete catalog -quiet
02:14 svc_backup psexec \\\\* -s C:\\ProgramData\\w.exe ← pushed to every host at once
02:15 SYSTEM w.exe 4,212 files renamed *.locked; README.txt dropped
# Firewall, three nights earlier
00:43 10.2.4.17 → 185.x.x.x:443 rclone/1.66 41.8 GB out ← the exfiltration the leak threat is based on🎯On the job. The two questions leadership asks in the first hour are "how bad is it?" and "when are we back?". Answer honestly with what you know and when the next update will be, rather than guessing. Give updates on a fixed schedule, for example every two hours, even if nothing has changed.
Recovery: Rebuild in the Right Order
What is this?Restoring is not "press restore on everything". If you restore systems before you've removed the attacker's access, you'll be encrypted again.
Rebuild or clean Active Directory / Entra ID first: reset krbtgt twice, all privileged and service accounts, remove attacker persistence. Everything else trusts it
DNS, DHCP, networking, backup system, EDR console, logging, so you can see what happens next
In the order the business agreed in its continuity plan: payments, production, patient care
Rebuilt from clean images where possible rather than decrypted, with patches and EDR before reconnecting
Backups decide everythingThe useful questions are:
- Are they offline or immutable (object lock, write-once storage), or could the attacker's domain admin delete them?
- When were they last tested as a full restore, not just a file restore?
- Do they predate the intrusion? Restoring a backup taken after the attacker got in restores the backdoor.
📰Real incident — British Library (2023). The Rhysida group got in, probably through a remote-access account without MFA, stole about 600 GB and destroyed servers to hamper recovery. The library refused to pay, and the data was auctioned and leaked. Its published review in 2024 explained why recovery took many months: much of the infrastructure was legacy software that could not be restored or no longer had vendor support, so it had to be rebuilt. Lesson: technical debt sets your recovery time, and the time to fix it is before the attack.
To Pay or Not to Pay
What is this?The ransom decision belongs to the executives and the board, with legal advice. The security team's job is to give them accurate inputs.
| Factor | Question to answer |
|---|---|
| Can we recover without the key? | Are backups intact, recent and restorable in a time the business survives? |
| Is it legal? | Is the group or its wallet sanctioned? Paying a sanctioned party (for example under US OFAC rules) can itself be illegal |
| Does it buy anything? | Decryptors are often slow and buggy; payment doesn't guarantee the stolen data is deleted |
| What does it cost to wait? | Lost revenue, safety or patient impact, contractual penalties per day of downtime |
| Is there a free decryptor? | Check No More Ransom (the Europol and industry project) for known families |
| Who else must agree? | Insurer, regulators in some sectors, the board |
📰Real incident — Change Healthcare (2024). ALPHV got in through a Citrix remote-access portal without MFA. UnitedHealth paid a $22 million ransom, after which the affiliate, cheated out of their share by ALPHV's operators, took the data to a second group, RansomHub, which demanded another payment. About 190 million people's data was affected. Lesson: paying doesn't make stolen data disappear, and you are negotiating with criminals who don't keep promises even to each other.
📰Real incident — Colonial Pipeline (2021). Colonial paid about $4.4 million in bitcoin the day after the attack. The decryptor was so slow that the company relied largely on its own backups anyway. The FBI later recovered about $2.3 million of the payment by tracing the wallet. Lesson: test how fast your backups restore before deciding a decryptor is the faster path.
Notifications and Clocks
Last verified2026-10
Several regulatory clocks can start at once. Legal decides, but you need to know they exist so evidence is collected in time:
| Regime | Who | Deadline |
|---|---|---|
| GDPR | Anyone holding EU personal data | Notify the supervisory authority within 72 hours of becoming aware of a personal-data breach |
| NIS2 | Essential and important entities in the EU | Early warning within 24 hours, notification within 72 hours, final report within one month |
| DORA | EU financial entities | Initial notification within 4 hours of classifying an incident as major (no later than 24 hours after detection) |
| SEC (Form 8-K Item 1.05) | US-listed companies | Disclose within four business days of deciding the incident is material |
| Contracts and insurance | Customers, insurer | Often 24–72 hours in contracts; insurers usually want notice before you engage anyone |
Interview Questions
I declare an incident and assemble the team on an out-of-band channel, since the attacker may be reading email and chat, and we call the insurer, who may appoint counsel and an IR firm. In parallel I contain: isolate affected hosts and segments through EDR rather than powering them off, so memory evidence survives; disable the accounts used; block the attacker's remote tools and command-and-control; and get backups offline if they're intact. Then I start scoping: which family, how they got in, what was exfiltrated. Leadership gets an honest status and a time for the next update. Encryption is the end of the intrusion, so containment has to assume they still have admin access.
Because every other system trusts Active Directory or Entra ID. If the attacker still has a domain admin account, a golden ticket or a rogue app registration, anything we restore can be re-encrypted the same day. So identity comes first: reset krbtgt twice, reset privileged and service accounts, remove persistence like new admins, scheduled tasks and remote tools, then bring back core infrastructure like DNS, backups and logging, and only then business systems in the order the continuity plan sets.
It's a business and legal decision, not a security one, but I'd give leadership clear inputs: can we restore from backups in a time the business can survive, is the group sanctioned, which would make paying illegal, and what does each day of downtime cost. I'd also be clear about what payment doesn't buy. Decryptors are often slow, as Colonial found in 2021, and the data isn't really deleted: Change Healthcare paid $22 million in 2024 and was then extorted again by a second group with the same data. Most of the time intact, tested backups are what make "don't pay" a realistic choice.
First check what really survived: offline or immutable copies, cloud snapshots in another account, replicas, even exports in SaaS systems, and check No More Ransom for a free decryptor for that family. In parallel the business decides what it can rebuild from scratch, for example from infrastructure-as-code and source control, versus what is truly lost. The lesson for afterwards is that backups the domain admin can delete aren't backups against ransomware: they need immutability or a separate administrative domain, and regular full restore tests.
The precursors are what you want alerts on: new remote-management tools like AnyDesk appearing on servers, AD enumeration and credential dumping from a workstation, large outbound transfers with Rclone or to file-sharing sites, typically at night, new domain admins, and backup or EDR tampering. The last step before encryption is usually deleting shadow copies with vssadmin and wiping backup catalogues, which is a high-confidence alert worth an automated isolation response.