Ransomware Runbook: From Encryption Event to Recovery Decision
Cybersecurity
Ransomware is the incident that turns finance, legal, and engineering into the same team for two weeks. This is the runbook we use, including the pay-or-not decision matrix and the regulatory clock most teams forget.
By Arjun Raghavan, Security & Systems Lead, BIPI · March 14, 2024 · 9 min read
Ransomware is the incident that exposes every weak preparation choice the organization made for the previous five years. The runbook below assumes you have already made the mistake of not testing backups quarterly and not segmenting the network. We work with what you have.
Trigger and confirm
The first sign is rarely the ransom note. It is the help desk getting twelve calls about file shares throwing errors, the SIEM lighting up with mass file rename events, the backup job alerting that its destination volume just got encrypted. Confirm by sampling a few hosts and looking for the encrypted file extension, the dropped ransom note, and the new entries in the file system journal. ID Ransomware and the NoMoreRansom project will tell you the family from the note and a sample encrypted file.
Contain without amputating
Network isolation is the obvious move and the easy one to overdo. Yank the internet at the perimeter to stop active C2 and exfil. Then isolate at the segment level: pull the affected subnets, leave the unaffected critical services running. Disable domain admin accounts whose credentials were on the patient zero host. Block the SMB and RDP ports that the ransomware used for lateral movement. Do not power off encrypted hosts, that destroys memory artifacts you need.
- Sever internet at perimeter, preserve internal connectivity for IR work
- Disable any domain admin account whose token may have been stolen
- Block SMB (445) and RDP (3389) between segments until scoping is complete
- Capture memory from at least three encrypted hosts before any cleanup
- Quarantine the backup infrastructure if it shows any sign of compromise
Preserve evidence before you wipe
The temptation is to rebuild as fast as possible. Resist for 24 hours. Image the patient zero, image two laterally compromised hosts, pull EVTX and memory from a dozen more. The forensic record matters for the regulatory filing, the insurance claim, and the law enforcement referral. It also matters for the next incident, because the data leak side of double-extortion ransomware means the same actor may come back through a different door.
The pay-or-not decision matrix
The decision is rarely binary. It depends on backup viability, regulatory exposure, sanctioned-entity risk on the payment, and whether the actor has a track record of decrypting. The matrix below is what we walk through with the CFO and the General Counsel inside the first 72 hours.
- Are clean backups restorable within the business tolerance window? If yes, do not pay
- Is the actor on an OFAC sanctions list or known to be? If yes, payment is illegal in most jurisdictions
- Is exfiltrated data covered by clean off-site storage that limits regulatory damage? If yes, the leak threat is weaker
- Has the actor historically delivered working decryptors? Some families have a track record, some do not
- Will the decryptor actually decrypt at acceptable speed? Some families produce decryptors that take weeks per terabyte
Negotiation reality
If payment is on the table, you do not negotiate. A professional negotiator from your incident response retainer does. They have leverage you do not (knowledge of typical discount levels, awareness of the actor's reputation, access to monitored crypto channels). The negotiation is a stalling tactic as much as a price discussion. Every day you stall is a day your team buys to validate backups and reduce the leverage.
Regulatory notifications: the clock starts now
Most regulators want notification within 72 hours. GDPR is 72 hours from awareness. SEC public company disclosure is 4 business days from materiality determination. State breach notification laws vary, several require notification within 30 or 45 days. Build the notification timeline into your runbook so the deadlines do not surprise you on Day 5. The CISO does not make this call alone, the General Counsel signs off.
Restoration strategy
Rebuild from known-good. That means trusted operating system images, patched, joined fresh to a rebuilt domain or to a temporarily segregated parallel environment. Restore data from the backup point most likely to be clean, validated by hash comparison and AV scanning. Do not restore from a backup taken within the attacker dwell window without scanning every file. Bring services back in dependency order, smallest blast radius first.
The first system to come back online is not the most important one. It is the one whose failure would prevent everything else from coming back.
Lessons that recur in every ransomware case
- Test backup restoration quarterly, not when you need it
- Keep domain admin tokens off endpoints, period
- Segment so a single compromised credential cannot reach the backup server
- Pre-negotiate an IR retainer that includes ransomware negotiation services
- Brief the board on the pay-or-not framework before you ever need to use it
Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.