Ransomware across file servers and ESXi with a backup server in the blast radius

Priority order: backups, identity, volatile evidence, then breadth. Encryption is running at roughly 73 files per second; nothing you do in the next hour un-encrypts what is already gone. What you can still lose is the ability to restore and the ability to prove what happened.

1. Declare and log. Incident bridge, named incident commander, single timeline in UTC recording who did what and when. Every later legal question depends on this artefact.
2. Isolate the backup server before anything else. Switch-level network isolation, not just account disable. Then disable the shared backup service account and rotate its credentials. Verify the last known-good restore point and whether the backup catalogue itself was touched. Rationale: destroying backups is the attacker's next step and the step that converts a bad week into an existential event.
3. Separate the ESXi management plane. ACL the vCenter and host management networks away from user VLANs. Do not shut the hosts down: 48 VMs go dark, the hypervisor logs you need are lost, and encryption already completed is unaffected. If you need VM memory for evidence and time allows, suspending a VM writes its state to a .vmss file - defensible, but it changes state, so document it and do it selectively.
4. Capture memory before containing the DC and one file server. Triage order puts the DC first, because credential material and the attacker's tooling live there. Use EDR network containment on those hosts rather than powering off; containment keeps memory, the process tree and the encryption key material recoverable.
5. Cancel the 04:00 patch window. Rebooting 30 servers will wipe volatile state and may trigger cleanup or re-encryption scripts on next boot. Get written confirmation from the patch team.
6. Egress controls. Block known C2 infrastructure, but expect rotation; check for exfiltration before assuming this is encryption-only.

Powering off everything is the one action that reliably destroys the evidence needed to answer "how did they get in" and "was data taken" - and it does not restore a single file.

Scope questions to answer in parallel, not in sequence: initial access vector; persistence on the DC; which accounts are compromised; whether data left the network before encryption; whether the backup catalogue or immutability settings were altered.

Evidence to capture before any rebuild:

• Forensic images of the DC and at least one file server; capture the ESXi host logs (/var/log, vmware.log, vpxd logs) before anyone reinstalls.
• Memory images where the toolkit and time allow, DC first.
• Export relevant SIEM and EDR telemetry to write-once storage so it cannot age out or be deleted by a compromised admin account.
• Hash every image, record tool name and version, and log the transfer chain.

High-value artefacts for the timeline: shadow-copy deletion (vssadmin/wmic), service creation (7045), RDP logons (4624 type 10), remote execution tooling, new privileged group members, and the moment the shared backup account was used from an unexpected host.

Exfiltration assessment drives the notification decision. Pull firewall, proxy and DNS egress volumes for the preceding 14 days and compare against baseline. Ransomware with confirmed exfiltration is a different regulatory conversation from encryption alone.

Data-category mapping. Sample the encrypted file lists from each share to determine which servers held personal data and roughly what volume and categories. The DPO needs categories and approximate record counts, not a file count.

Restoration decision. Verify a restore from an isolated, known-good copy - not from the domain-joined backup server - and confirm the immutability window was not shortened. Rebuild rather than clean; treat the DC as compromised until proven otherwise, which implies a krbtgt reset once evidence capture is complete.

To the CEO - give a decision, not a status report. "No, we are not powering everything off. Here is why: encryption already completed on those shares; shutting down the ESXi hosts would take 48 production VMs offline, destroy the evidence we need for the regulator and the insurer, and not recover a single file. Containment is in place at the network layer: the backup server is isolated, the shared service account is disabled and rotated, and the patch reboot is cancelled. We have verified a restore point from [time] and [n] of the affected shares can be recovered from clean media with an estimated [x] hours to restore. The DC is presumed compromised and will be rebuilt; expect [list] services degraded until then." Add a next-update time and name an owner. Do not promise an entry vector you have not established.

To the DPO - give facts, unknowns, and a recommendation with a deadline.

• What is known: which servers, which data categories, approximate volume, and time of encryption.
• What is not known yet, and by when it will be: whether data was exfiltrated, and the full record count.
• Regulatory position: encryption of personal data is itself a personal data breach; the Article 33 clock starts on awareness, not on completion of the investigation. Unless the scope check before the deadline shows the affected shares held no personal data - unlikely - the working assumption should be that notification is required.
• Risk framing: if clean restores hold and there is no exfiltration evidence, risk to data subjects is lower; if exfiltration is confirmed, reassess Article 34 obligations for affected data subjects.

Keep the forensic report under legal privilege where counsel directs, and record every assumption you gave the DPO so the decision can be reconstructed later.