Skip to main content

Hit by ransomware? Isolate affected systems now. Do not reboot or reformat.

SheMo Noransom舍末无勒

Case study

Akira encrypts an ESXi cluster at a manufacturing group

After entering through a VPN account, the attacker powered off VMs and encrypted their VMDK files, taking MES and office systems down together. Key VMs were recovered from storage-layer remnants and partial disk repair.

Industry
Manufacturing Ransomware Response and Recovery
Family
Akira
Scenario
Virtual Machines Encrypted
Handled
2026-03

This case study is composed from typical scenarios to illustrate our approach and the recovery paths involved. It does not describe a specific customer incident; real cases involving customer data are published only with authorization.

  • 约 90%

    Virtual machines restored

  • 约 3 天

    Production back online

  • 事件前数小时

    Key system roll-back point

  • 0

    Ransom paid

Incident background

The client is a manufacturing group whose two ESXi hosts run roughly two dozen virtual machines — MES, OA, file servers, a domain controller and a backup server — on shared SAN storage. The backup software ran inside one of those VMs, with its repository mounted on another LUN of the same array.

An SSL VPN had been introduced the previous year for remote work. Accounts followed the old password policy, multi-factor authentication was not enabled, and the edge appliance firmware had gone long without updates.

The incident was discovered on the second day of the Spring Festival holiday: duty staff reported that MES clients could not connect, and IT found vCenter unreachable, most VMs powered off on the ESXi consoles, VMDK and VMX files in the datastores carrying a uniform appended suffix, and ransom note text in the datastore root. The VM hosting the backup server had been powered off and encrypted too, and most files in the backup repository LUN were overwritten.

Because it happened over a holiday, more than a day passed between the attack and its discovery, giving the actor a long window.

What we did

In a virtualization case the biggest danger is continued writing at the storage layer, so all recovery attempts were stopped immediately.

  • Containment. External and cross-segment connectivity for both ESXi hosts was cut, creating, migrating or cloning VMs on the original datastores was prohibited, and snapshot cleanup and reclaim jobs on the array were paused.
  • Evidence. ESXi host logs, vCenter events, VPN and firewall logs were exported, and read-only snapshots and images of the SAN datastores were taken.
  • Family determination. The extension, note filename and text format pointed to Akira's Linux/ESXi variant. This family commonly encrypts virtual disks intermittently for speed, which testing confirmed here.
  • Recovery path. The storage array retained several volume snapshots the attacker had not deleted, and these became the main recovery source. For VMs the snapshots did not cover, untouched regions were extracted from the encrypted VMDK files, the filesystem rebuilt and business data exported.
  • Rebuild order. The domain controller and MES-related VMs were rebuilt first in an isolated segment; after a full credential rotation and a backdoor re-check they were progressively allowed back onto the production network, followed by OA and the file servers.
  • Parallel remediation. MFA on the VPN, an edge appliance firmware upgrade, and cleanup of long-dormant accounts.

Recovery result

MES and domain controller VMs were restored from array snapshots to a state a few hours before the incident, and production resumed on the third day after response began. OA and file servers were recovered through a combination of snapshots and data extraction from virtual disks; a small number of temporary files and recent mail attachments could not be retrieved. Overall, the large majority of virtual machines were returned to a usable state.

Forensics showed the attacker logged in through a VPN account belonging to a departed employee that had never been disabled, using credentials from an external leak, then moved laterally with remote-management tooling, obtained ESXi host management credentials, powered off VMs in bulk and encrypted at the hypervisor layer — the classic pattern by which virtualization incidents expand so quickly. No clear evidence of bulk exfiltration was found, but because outbound traffic logs had a short retention period the report labelled the exfiltration conclusion "undetermined".

Remediation concentrated on two things. First, fully separating the ESXi management network from the business network so management interfaces are no longer reachable from the office LAN, with MFA on both VPN and host management. Second, rebuilding backup: the backup server now runs independently of the virtualization platform, the repository has an additional immutable copy, and a full cross-host restore exercise has been completed.

This is an illustrative case compiled from typical scenarios and anonymized; it does not refer to any specific client.

Emergency response

Data already encrypted? Stop and let an engineer look first

We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.