The Ransomware Note That Arrived Before the Alert
At 02:14 on a Saturday, the on-call analyst receives a ticket from the help desk: a finance user cannot open her shared drive. By 02:40, 340 files across three departmental shares show the extension .lckd, and a ransom note named READ_ME.txt sits in each affected folder. The EDR console shows no detonation alerts, but a scheduled backup job ran at 01:00 and completed successfully. The organization has a documented RTO of 24 hours for finance systems and a 4-hour RTO for payroll, which is due to run Monday at 06:00. The incident commander must decide whether to isolate the file server, restore from the 01:00 backup, or both, and whether to pay the ransom given that the note claims 72 hours before keys are destroyed. The CIO is unreachable for the next 90 minutes.
1. What should the incident commander do first, and how should the isolation/restore decision be sequenced?
Read the worked answer
The first action is containment before restoration, not a binary choice between the two. Reasoning:
- Isolate the file server's network segment (or disable SMB shares) immediately. The absence of EDR detonation is a red flag: the encryptor may be living off legitimate tooling or running from a host the EDR does not cover. Restoring from backup while the encryptor is still active risks re-encryption of restored data, which is a classic and costly mistake.
- Preserve volatile state before shutdown - memory capture if tooling permits, and at minimum keep the host powered so logs and the process tree survive. A hard power-off destroys the evidence needed to find patient zero.
- Verify backup integrity rather than assuming the 01:00 job is clean. A backup that completed at 01:00 could already contain an encrypted or staged payload if the dwell time predates it. Mount the backup read-only and test-restore a sample.
- Restore only after the encryptor's foothold is identified or the environment is segmented so the restored data cannot be re-encrypted.
On the ransom: the 72-hour claim is unverified and paying does not guarantee keys. The commander should not decide to pay under time pressure from the attacker; escalate to the CIO/legal when reachable and proceed on the assumption of non-payment. The 4-hour payroll RTO means payroll restoration should be prioritized once the environment is confirmed clean.
2. The CIO later asks why the team did not simply restore from the 01:00 backup to meet the RTO. How should the commander justify the decision?
Read the worked answer
The commander should frame the answer around RTO versus data integrity and recurrence risk, not speed alone.
- RTO is a target for a controlled recovery, not a mandate to act before the threat is understood. Restoring into a compromised environment can produce a second encryption event, which would blow past the RTO entirely and destroy confidence in the recovery.
- The 01:00 backup is a hypothesis, not a fact. Backup completion does not equal backup cleanliness. The dwell time is unknown; the encryptor may have been resident for days. Test-restoring and scanning a sample is cheap relative to a failed recovery.
- Sequencing protects the 4-hour payroll RTO. Payroll is the tightest deadline; the fastest path to a durable payroll restore is to confirm the environment is clean and then restore payroll first, rather than restoring everything into a live threat.
- Document the decision and its rationale in the incident log so the post-incident review can evaluate whether the trade-off was correct, and so the CIO has an auditable record.