Ransomware Containment with a Compromised Domain Controller
At 02:14 on a Saturday, a healthcare provider's SOC receives an EDR alert: a domain controller is executing a known credential-dumping tool, and 38 servers show SMB write bursts to a file server. The on-call analyst sees that the backup team's service account has domain admin rights and that the immutable backup repository is configured but its last successful restore test was 14 months ago. The CISO is unreachable for 40 minutes. The incident response plan says to isolate affected hosts, but the CIO argues that isolating the domain controller will take down the emergency department's EHR. The ransom note demands 300 BTC within 72 hours. The organization has cyber insurance with a $5 million limit and a panel of IR firms, but the policy requires pre-approval before retaining counsel. A media outlet has called asking about an outage.
1. What containment sequence should the on-call team initiate in the first hour, given the CIO's EHR concern?
Read the worked answer
Declare a major incident and engage the IR retainer and insurer immediately. Contain spread at the network layer before shutting systems down: isolate the affected servers and the domain controller from unnecessary SMB/RPC, block known C2, disable the compromised backup service account, and preserve memory and logs. The CIO's EHR concern is valid, so activate clinical downtime procedures and coordinate with the emergency department; allowing a compromised domain controller to remain openly connected is worse than a planned authentication outage. Reset KRBTGT twice in the correct sequence and rebuild affected domain controllers from trusted media. Do not pay the ransom as a containment step. The first hour should prioritize patient safety, evidence preservation, and stopping lateral movement.
2. The immutable backup repository has not been restore-tested for 14 months. How should the team decide whether to rely on it, and what is the restore sequence?
Read the worked answer
An untested immutable repository is a hypothesis, not a recovery capability. Validate it in an isolated clean room: confirm backup timestamps predate infection, mount and scan the images, boot a test restore, and verify the EHR and domain services. Do not restore over production until the malware is eradicated and credentials are rotated, or the restore will be reinfected. If the repository is clean, restore prioritized clinical systems first and rebuild the domain. If it is not clean or cannot be validated, use the IR firm and insurance to rebuild from trusted media. A 14-month gap in restore testing is itself a finding to report to leadership.
3. What should the CISO do about the ransom demand and insurer/counsel pre-approval?
Read the worked answer
Notify the insurer before retaining counsel if the policy requires pre-approval; use the panel firm to avoid coverage disputes. Counsel should direct the ransom decision because of sanctions, legal, and privilege issues. Do not negotiate or pay before sanctions screening, verifying the decryptor, and assessing whether clean backups exist. Payment does not guarantee recovery and may create legal exposure. Document all decisions, preserve the ransom note, and coordinate law enforcement and patient notification. The CISO should communicate through the incident commander, not directly with the attacker.