Friday Night on the File Server: Ransomware with a Nine-Day Deadline
At 18:40 on a Friday, staff at Halberd Accounting (90 people, 400 active client files) report that documents on the shared drive open as unreadable files with a .locked extension, alongside a README.txt demanding payment in cryptocurrency. The endpoint agent quarantined one workstation an hour earlier, but the file server's shares are encrypted. Backups run nightly to a NAS in the same rack; the NAS is domain-joined and the backup job uses a service account with write access to the share. Weekly copies go to rotated USB drives kept in the office manager's desk drawer. The last recorded restore test was 11 months ago. The firm's stated recovery time objective is 24 hours, and a major corporate tax filing deadline is nine days away with 60 client files tied to it. The managing partner is asking whether to pay, and the IT manager wants to wipe and rebuild the server tonight to 'get ahead of it'.
1. Set out the first four actions in order, with a one-line reason for each.
Read the worked answer
Contain without powering off. Disable the file server's network links and the affected workstation's switch port, but leave both powered so memory-resident keys and running processes survive. Shutting down destroys evidence and does not stop encryption that has already run.
Protect the backups before anything else. Take the NAS off the domain and off the network, revoke the backup service account's credentials, and physically secure the rotated USB drives - out of the office manager's drawer and into a locked safe or offsite. Backups are now the only thing standing between the firm and its RTO, and backup targets reachable with a write-capable service account are a standard target.
Declare and escalate. Incident lead, managing partner, insurer and legal counsel. Set one bridge and one decision-maker. Note the 24-hour RTO and the nine-day filing deadline as business drivers, not as reasons to skip steps.
Preserve evidence and scope. Hash and copy the README files, record the extension and any ransom-note identifier, export server and endpoint logs to separate storage, and identify the entry point - the quarantined endpoint an hour earlier is the strongest lead. Then hunt for persistence and other encrypted hosts; one quarantine does not mean one entry point.
Do not pay, do not contact the attacker, and do not reimage tonight. The IT manager's instinct is understandable, but wiping destroys the scoping evidence needed to know what else is compromised and restores nothing faster.
2. Assess the backup posture. What can realistically be recovered, and in what order?
Read the worked answer
The posture is weak in three specific ways. The NAS is domain-joined and the backup service account has write access, so it shares fate with the server it protects and should be presumed encrypted until proven otherwise. The last verified restore was 11 months ago, so a green job status says nothing about recoverability. The USB rotation is genuinely offline - a drawer is not a safe, but it is air-gapped - giving an effective recovery point up to seven days back, and an unverified one.
Realistic answer: expect to restore from the most recent offline rotation, losing up to a week of work, unless the NAS proves intact - and test that first on isolated hardware, never by browsing it from a live machine.
Recovery order, driven by the nine-day deadline:
- Verify the newest offline drive mounts and that its catalogue and any encryption keys are usable. If it fails, move to the previous rotation immediately rather than debugging it under pressure.
- Restore identity and email first - staff cannot work or communicate without them.
- Restore file shares by client triage: the 60 files tied to the filing deadline first, then by statutory exposure and revenue. Not whole-share, not alphabetical.
- Rebuild servers from known-good images only after the entry point is identified, or the same door stays open.
Communicate expected recovery point and time to the managing partner in writing. They will be asked by clients, and over-promising creates a second incident.
3. Who must be told, in what order, and what should not be said?
Read the worked answer
Order:
- Internal, immediately: managing partner as decision-maker, IT, incident lead. Small enough to act, wide enough that nobody is improvising alone.
- Legal counsel and insurer, within hours. Counsel directs everything downstream. Many policies require prompt notification as a condition of cover, and privilege matters for the investigation.
- Regulator and/or law enforcement, per the applicable breach-notification rule. Where client personal data is involved, many regimes run a 72-hour clock from awareness. Notify on what is known and update later; do not wait for full scoping. Some jurisdictions also impose separate duties around ransomware payments or reportable cyber incidents - confirm with counsel rather than guessing.
- Affected clients, once counsel agrees the wording, prioritising those with the filing deadline and those whose data is confirmed exposed. If a client's own statutory deadline is at risk, they need time to act more than they need a complete explanation.
Do not say: that data is safe or backups are intact until a restore has actually been tested; whether payment is being considered, since that invites extortion escalation and may be legally sensitive; or anything speculative about attribution. Do not communicate with the attacker at all - that is a decision for counsel, and in some jurisdictions a regulated one.