Ransomware on a Live File Server With Legal Hold
At 07:40, a 40 TB Windows file server at a 2,000-employee logistics firm begins renaming files to .locked and dropping README_RESTORE.txt. The server is still powered on; EDR shows a signed but malicious process injected into lsass and an outbound SMB connection to 10.10.8.22. Backups run nightly at 01:00 to a domain-joined NAS; last night's backup completed but has never been test-restored. Legal has a preservation notice for an HR matter involving three user mailboxes on the same server. The incident commander must decide whether to pull the power, isolate, or image. The server hosts an active file share used by dispatch, and the business wants restore before 12:00. The server is a VM on ESXi; snapshots exist but are six days old.
1. Should the responder pull the power, isolate the VM, or image it first? Give the order of operations and the reasoning.
Read the worked answer
Do not pull the power first. Pulling power loses volatile evidence such as process memory, network connections, and possibly encryption keys or the running binary, and it can leave the file system in an inconsistent state. The first action is to isolate the VM at the hypervisor: remove or disable the virtual NIC or apply an isolated port group. That stops outbound SMB to 10.10.8.22 and blocks further lateral movement while keeping the guest running.
Next, capture volatile data in order: memory, running processes, network connections, logged-on users, scheduled tasks, and service state. If encryption is still actively progressing and isolation does not stop it, suspend the VM rather than power it off; suspension preserves memory state and disk state. Then create a forensic image or snapshot for analysis before any restore.
The business wants restore by 12:00, but restoring over the live server destroys evidence and may reintroduce the attacker. Build a clean restore target in parallel. Preserve the original VM and its memory image under legal hold, then restore from a verified backup to a new host.
2. What evidence must be preserved given the HR legal hold, and how should the backup be validated?
Read the worked answer
Preserve the original server image, memory capture, Windows event logs, EDR telemetry, SMB connection logs, PowerShell or command history, and the ransom note with its hash. Because the HR matter involves mailboxes on the same server, do not limit collection to ransomware artifacts. Preserve mailbox databases, message tracking logs, and access logs for the three custodians, and document chain of custody for every image. Legal hold means no destructive restore and no wiping until counsel releases the data.
Validate the backup before restore: verify the backup job catalog and checksums, restore to an isolated clean host, scan the restored files, and confirm the NAS itself was not compromised. The NAS is domain-joined, so attacker credentials may reach it. Check NAS logs for the same source host and for deletion or encryption activity. If the backup is intact, restore to a new VM with a new local administrator credential and no domain trust until validated.
Do not restore over the original. Keep the original powered off or suspended after memory capture, and document the restore target, backup set, and validation results.
3. What containment and credential actions should follow, and why is the six-day-old snapshot not a safe restore point?
Read the worked answer
Contain the identity path, not just the server. The malicious process injected into lsass suggests credential theft. Reset privileged accounts that logged on to the server, rotate service account passwords, and revoke Kerberos tickets by resetting the krbtgt account twice if domain compromise is suspected. Review 10.10.8.22 for signs of lateral movement and isolate it if it is also compromised. Block the outbound SMB path and inspect firewall logs for other hosts contacting that address.
The six-day-old snapshot is not a safe restore point because it may already contain the attacker's foothold, persistence, or stolen credentials. A snapshot restores the system state, including potentially compromised binaries and scheduled tasks. It is also stale relative to the HR data and may not satisfy the legal hold. Use it only as an investigative reference, not as the production restore source. Restore from a backup validated against a known-good baseline and then monitor the restored host closely.