Encryption at the Hypervisor Layer During Finance Close
At 03:20 the backup team reports that a hypervisor host in the DR site shows fourteen VMs whose VMDK files were renamed with a .locked extension; vCenter task history shows snapshot deletions issued by a domain service account that also owns the backup service. Guest VMs have EDR agents, but the hypervisor itself is outside EDR coverage, and the only hypervisor log source is vCenter tasks forwarded every 15 minutes. The ERP cluster runs on this host and the finance close begins in six hours; the last verified immutable backup copy is 4 hours old and the repository lock window is 26 hours. Legal has asked whether notification clocks start now. The ransom note names no group and demands payment in 48 hours.
1. State the containment order and defend the first action.
Read the worked answer
Account, then management plane, then guests.
- Disable and rotate the backup service account credentials. The vCenter task log shows snapshot deletions issued by that identity; until the credential is dead, re-entry is trivial and containment is undone. Also locate every other system where that account is reused, because the DR host is unlikely to be the only exposure.
- Restrict the hypervisor management network, meaning vCenter and ESXi management interfaces, to the IR jump host. Guest data traffic can stay up. The encryption occurred at the datastore layer and the hypervisor has no EDR, so the management plane is the only control point available.
- Isolate guest networking on affected VMs only where EDR shows live malicious process activity.
Do not start with the guests. Isolating fourteen already-encrypted VMs achieves nothing operationally and destroys the network evidence showing how the account was used. Order matters because each later step depends on the credential no longer working.
2. Power off the host to stop the spread, or keep it running?
Read the worked answer
Keep it running unless there is evidence of an active destructive process right now.
For keeping power on:
- Hypervisor volatile state, including running processes, management-plane connections and any live attacker session, is lost on power-off and cannot be reconstructed from vCenter tasks.
- vCenter forwards only every 15 minutes, so up to 15 minutes of task history may never have reached the SIEM. Pull the host's local shell, vmkernel, vmkwarning and authentication logs directly before anything else.
- Powering off takes the ERP cluster fully offline, which may be a worse availability outcome than a contained host.
For powering off: a second encryption pass is actively running, or the attacker holds an interactive session that cannot be severed. In that case capture memory first if the platform supports it.
Decide on observed activity, and record the reasoning in the incident log, because this choice will be reviewed.
3. Does the notification clock start now? Which facts does legal need from you?
Read the worked answer
Do not assert that it does or does not. The answer is jurisdiction- and sector-dependent, so the IR lead supplies facts and lets legal decide.
Facts legal needs:
- Scope: fourteen VMs on one host, whether any holds personal or regulated data, and whether volumes were copied as well as encrypted. Encryption plus a ransom note is often double extortion, so check for staging archives and egress before assuming confidentiality is intact.
- Availability impact: the ERP cluster is down and finance close is in six hours. Operational-resilience obligations can trigger on service disruption without a confirmed data breach.
- Recovery: the last verified immutable copy is 4 hours old inside a 26-hour lock window. Recoverability affects both the risk assessment and any ransom decision.
- Timeline: earliest credible compromise time, corrected for the 15-minute forwarding delay.
Tell legal the exfiltration question is unresolved, and book a checkpoint for when it is answered.