Ransomware at a 240-Bed Hospital: Containment and Recovery Choices
At 03:10 on a Tuesday, the SIEM at a 240-bed hospital raises 40 alerts in six minutes: a service account named svc_backup is authenticating to workstations it has never touched, and files on three departmental shares are being renamed with a .locked extension. The EHR is SaaS and unaffected, but the PACS imaging archive and 60 TB of shared drives are on-premises. By 04:00 the security team confirms encryption is spreading over SMB and that the account held domain-wide logon rights because of a misconfigured group policy. The hospital has two recovery sources: nightly backups to a NAS joined to the same domain, and an immutable, air-gapped cloud copy replicated weekly. The most recent verified restore point on the cloud copy is 11 days old, because a credential rotation broke the replication job nine days ago and nobody noticed. The PACS vendor's stated recovery time objective is 24 hours. Surgery is scheduled from 07:00 and clinical leadership wants to know whether to shut down the network entirely. No ransom note has been found and there is no evidence either way about data theft.
1. Recommend the containment posture for the first four hours. Address clinical leadership's proposal of a total network shutdown.
Read the worked answer
Do not default to a total shutdown, but do not argue for keeping things as they are either. A hospital-wide power-down of networking can itself cause patient harm and cuts access to the SaaS EHR - which is currently the one system known to be clean, provided the path to it is trustworthy.
Recommended posture - segmented containment with life-safety first:
- Disable and rename
svc_backup, reset its credentials, and hunt for every other account granted rights by the same GPO. Assume the attacker had domain-wide reach. - Isolate affected VLANs and subnets at switch and firewall level rather than powering hosts off - this preserves volatile evidence and lets you measure scope.
- Block SMB (445/139) between workstation VLANs and to the file servers; this directly stops the spread mechanism already confirmed.
- Keep clinical systems required for care running, but sever their route to the file shares and the PACS archive until those are cleaned.
- Capture memory and disk images of two or three representative hosts before any reimaging; the rest can be rebuilt.
- Activate the IR plan with a timestamped incident log; engage outside counsel for privilege and notification advice.
Governance: the CISO owns the technical decision, but the CMO/CIO own the clinical risk of any outage. Document who accepted which trade-off and when. Also correct one assumption: the absence of a ransom note means nothing - encryption is confirmed, and theft should be assumed possible until logs say otherwise.
2. Recommend a recovery source and sequence, and describe what evidence would change your choice.
Read the worked answer
Default to the immutable 11-day copy. The reasoning is trust, not recency. The attacker held domain-wide credentials and the NAS is domain-joined, so the nightly backups sit behind the same authentication the attacker already used - backup infrastructure is a standard target precisely because organisations depend on it. A restore point 'verified nine days ago' is more recent but not trustworthy if the adversary could reach or tamper with it. The immutable, air-gapped copy is the only one whose integrity is defensible.
Cost of that choice: an 11-day RPO. For imaging that means roughly 11 days of studies; much of it can be reconstructed from modality worklists, prior reports, paper requisitions and re-scanning non-urgent patients. Compare that to restoring a corrupted or re-encrypted backup, which can turn a contained event into a multi-week outage.
Sequence: rebuild identity first (reset krbtgt twice, rotate all privileged and service credentials), rebuild backup infrastructure credentials, restore into an isolated recovery network, validate and scan, then reconnect in clinical priority tiers - PACS first against the 24-hour RTO, then departmental shares.
Evidence that would change the decision: checksum verification and a successful test restore of the immutable copy; log proof the NAS was never accessed and is not domain-authenticated; confirmation the nightly job was isolated from the compromised account. The nine-day silent failure is itself a finding - replication monitoring must be an alert, not a dashboard.
3. How do you handle breach-notification obligations when exfiltration is neither confirmed nor excluded?
Read the worked answer
Notification clocks usually start at discovery, and the trigger is often 'unauthorized acquisition' or 'risk of harm' - not confirmed exfiltration. Waiting for certainty is how organisations miss deadlines.
Immediate actions in parallel, not in sequence:
- Engage outside counsel to direct forensic scope and advise on jurisdiction-specific timelines; route the decision through them so it is privileged and documented.
- Preserve the sources that settle the question: firewall and proxy egress logs, VPN records, SMB and file-access auditing, EDR telemetry, mail and cloud-storage logs. Freeze retention on those before rebuilds destroy them.
- Do not wipe or reimage hosts until images are captured.
- Start the harm assessment now: what data sits on the affected shares, how many individuals, does it include PHI, and is there a low-impact exemption in the applicable regime.
The decision rule: make the call inside the regulator's window on the best evidence available, and record the reasoning and the uncertainty. In many regimes the obligation turns on a risk-of-harm assessment, so a defensible 'we assessed and notified' beats a late 'we now know for certain.' With PHI on the shares and an unclear forensic picture, leaning toward earlier notification is usually the safer posture.
Also decide, separately: payment is not the primary recovery path - it does not guarantee restoration and may raise sanctions and legal issues; keep it as a documented last resort with counsel and insurer involved.