Ransomware on the Engineering File Server During Backup Failure
At 07:05 Monday, a file server hosting 40 TB of engineering drawings begins showing .locked extensions; by 07:20, 12,000 files are encrypted. EDR shows PsExec lateral movement from a finance workstation to two other servers. The backup system uses immutable cloud storage, but Friday's backup job failed because the service account password expired; the last successful backup is Thursday 23:00. The domain controller is healthy, but the attacker used a compromised domain admin account that is still active. Two hundred Windows endpoints are online; 60 are in the engineering VLAN. The CEO wants operations restored by 17:00 and asks whether to pay the ransom. You have a legal hold from a pending lawsuit requiring preservation of engineering records.
1. What are the first containment actions, in order, and what would you avoid?
Read the worked answer
Contain identity and lateral movement first. Disable the compromised domain admin account and revoke its sessions and tickets; reset krbtgt twice with a controlled process if domain admin compromise is confirmed, because the attacker may have forged tickets. Isolate the encrypted file server, the finance workstation, and the two laterally targeted servers at the network layer, but keep them powered so memory and encryption artifacts are preserved. Block PsExec and SMB lateral movement between the engineering VLAN and finance. Protect the domain controller and backup infrastructure; verify immutable backups are not reachable with the compromised credentials. Avoid wiping or reimaging before forensic images are captured, and avoid paying. Notify legal because the legal hold requires preservation of engineering records, including encrypted originals. The CEO's 17:00 target is not achievable for 40 TB; communicate a phased recovery based on critical services.
2. How do you decide restore sequence and whether Thursday's backup is usable?
Read the worked answer
Verify Thursday's backup before relying on it: check catalog integrity, restore a sample to an isolated VLAN, scan restored files, and confirm the backup service account and credentials were not compromised. Because Friday failed, Thursday is the only clean restore point, but it may contain the attacker's persistence if the intrusion began before Thursday. Rebuild restore targets from trusted media, reset local and domain credentials, and restore in a segmented network with monitoring. Sequence by business criticality: domain services, finance reconciliation, then engineering drawings. For the legal hold, preserve the encrypted original disks and file metadata; restore working copies separately and document the chain of custody. Do not overwrite the original server. If Thursday's backup is incomplete, prioritize file-level recovery from immutable storage and accept longer RTO rather than restoring unverified data.
3. The CEO asks whether to pay the ransom. How do you frame the decision?
Read the worked answer
Frame payment as a policy, legal, and insurance decision, not an IT recovery shortcut. Paying does not guarantee decryption, may fund criminal activity, can raise sanctions or legal issues, and encourages further extortion. The company should consult counsel, the insurer, and executive leadership, and document the rationale either way. From an incident-response view, the priority is restoring from immutable backups, containing the identity compromise, and not letting ransom negotiation interfere with evidence preservation. If leadership considers payment, require legal review of sanctions and extortion laws and use a specialist negotiator; do not let IT communicate with the attacker. The 17:00 deadline should not drive an irreversible decision. State clearly that recovery without payment is technically plausible but will take longer than the CEO's target.