Containment and Evidence Decisions During a Ransomware Event

Order by patient safety, then containment, then evidence.

1. Convene clinical and incident leadership immediately. Do not power off the MRI suite or any system in active patient care; clinical availability outranks forensic convenience, and powering off also destroys volatile memory.
2. Isolate the encrypted server segment and the compromised domain controller using VLAN or firewall isolation, not wholesale shutdown. Preserve switch and EDR logs.
3. Disable the shared domain-admin account and reset its password twice. If a domain controller is confirmed compromised, plan a krbtgt reset twice with the required interval.
4. Capture volatile memory from the domain controller and one encrypted file server before any reboot, using a validated tool and chain-of-custody form.
5. Block SMB lateral movement between workstation VLANs and server VLANs. Verify backup server isolation is real, not just a firewall rule that still permits the same admin path.
6. Notify legal and the IR retainer; start the 72-hour regulatory clock based on counsel’s advice.

Do not restore yet. Restoration before containment risks re-encryption and destroys evidence.

Neither backup is automatically safe. The 36-hour backup is newer but untested and was created after the likely dwell time; if the attacker had domain-admin access, the backup may contain malware or the catalog may be compromised. The seven-day immutable snapshot is more resistant to tampering but loses up to seven days of clinical and billing data.

Use a clean-room restore sequence:

• Validate the 36-hour backup’s integrity and scan it in an isolated environment before production use. Check backup logs for anomalous access and confirm the backup server was not reachable by domain-admin credentials during the incident.
• If validation is clean, restore tier-1 clinical systems first, then imaging, then administrative systems. Keep restored systems on a quarantined network until EDR and patch baselines are verified.
• If validation fails or is inconclusive, use the immutable snapshot for critical systems and accept the data-loss tradeoff; reconcile missing data manually.
• Do not treat ransom payment as an engineering decision; it is a business and legal decision, and payment does not guarantee recovery.

Document the restore decision, data-loss estimate, and validation evidence for regulators.

Prioritize evidence that explains entry, lateral movement, persistence, and recovery risk, and that is volatile.

• Volatile memory from the domain controller and at least one encrypted server: running processes, network connections, injected code, and credentials in memory. Capture before shutdown.
• EDR telemetry and SMB session logs: lateral movement path, account used, timestamps, and source hosts.
• Domain controller security logs and authentication events: privileged logons, Kerberos anomalies, account creation, and Group Policy changes.
• Backup server logs: who accessed the catalog, whether backups were deleted or encrypted, and whether the immutable snapshot was touched.
• Ransom note, file extensions, and encrypted file samples for family identification, not for decryption promises.

Use write blockers for disk images, hash all evidence, and maintain chain of custody. Do not boot suspect hosts merely to collect files. Normalize timestamps and keep a timeline. Avoid collecting only encrypted servers; the domain controller and backup server explain both the intrusion and the recovery risk.