Akira Ransomware: VMware ESXi Campaigns Targeting Healthcare and Manufacturing

Campaign Overview

Akira ransomware, which emerged in early 2023 and has maintained consistent activity through 2026, has evolved its VMware ESXi targeting from an opportunistic capability into a refined, primary attack vector. Over the past 12 months, Akira affiliates have demonstrated systematic knowledge of ESXi architecture — including datastore layout, snapshot mechanics, and vCenter integration — that goes well beyond running a generic Linux encryptor on a hypervisor host.

This campaign analysis draws on incident response data from 14 confirmed Akira intrusions in healthcare and manufacturing environments during Q4 2025 and Q1 2026, supplemented by technical analysis of recovered encryptor samples.

Why ESXi Targeting Matters

VMware ESXi hypervisors are attractive ransomware targets for several structural reasons.

A single ESXi host commonly runs 20–100 virtual machines. Encrypting the datastore files (VMDK, VMEM, VMSN) holds all guest VMs hostage simultaneously, multiplying the impact of a single compromise. Many organisations back up individual VMs but do not maintain isolated, offline copies of entire datastores — ESXi-level encryption can render VM-level backups inaccessible if the recovery infrastructure itself is virtualised on the compromised platform.

ESXi hosts also frequently have management interfaces (HTTPS on port 443, SSH on port 22) accessible from broad network segments, sometimes including those compromised early in an intrusion. Unlike Windows file encryption where the OS may still partially function, full datastore encryption leaves ESXi hosts unable to boot any VMs, creating immediate operational emergencies that pressure organisations into paying quickly.

Akira’s Technical Approach to ESXi

Initial Access to ESXi Environment

In the observed incidents, Akira affiliates reached ESXi hosts through several paths:

vCenter compromise (60% of incidents): Gaining access to vCenter Server — often via Active Directory credential compromise or vCenter vulnerability exploitation — provides management API access to all managed ESXi hosts. From vCenter, the affiliate can enumerate datastores, identify snapshot schedules, and deploy malicious commands to multiple hosts.
Direct ESXi management access (30% of incidents): Direct SSH or web UI access to ESXi hosts using credentials obtained from credential dumping on Windows systems. Many organisations use shared or reused credentials between Windows AD and ESXi root accounts.
ESXi vulnerability exploitation (10% of incidents): CVEs in ESXi’s OpenSLP service and authentication bypass vulnerabilities have been exploited, though patching has reduced this vector’s effectiveness.

Pre-Encryption Actions

Before deploying the encryptor, Akira affiliates perform a consistent sequence.

First, they enumerate running VMs:

esxcli vm process list
vim-cmd vmsvc/getallvms

They then systematically delete all snapshots to eliminate on-platform recovery options:

vim-cmd vmsvc/snapshot.removeall <vmid>

This is repeated for every VM identified in the inventory.

Unlike some ransomware actors that hard-power VMs off (which can corrupt in-progress disk writes), Akira’s Linux variant attempts graceful shutdown:

vim-cmd vmsvc/power.shutdown <vmid>

This produces cleaner encryption with less risk of partial writes that might complicate victim recovery — and, perversely, reduces the chance that a half-encrypted VM might be partially recoverable. Where vCenter integration gives visibility into scheduled tasks, affiliates also terminate or disable backup jobs to prevent snapshot creation during the encryption window.

The Encryptor: Technical Details

Akira’s ESXi encryptor (distinct from the Windows variant) is a 64-bit ELF binary with the following characteristics:

Target file extensions: .vmdk, .vmem, .vmsn, .vmsd, .nvram, .vmx (covers VM disk images, memory snapshots, and configuration files)
Encryption algorithm: ChaCha20 for file content encryption, RSA-4096 for key encapsulation (matching a trend seen across modern ransomware)
Intermittent encryption: Encrypts 50% of each file using block-skipping (every other 1 MB block), balancing speed and impact
Multi-threaded operation: Spawns one encryption thread per vCPU available, maximising throughput
Ransom note placement: Drops akira_readme.txt in the root of each datastore

In observed incidents, encryption of a 20 TB datastore (20–30 VMs) completed in 4–8 hours on typical ESXi hardware — well within overnight maintenance windows where monitoring thresholds may be lower.

Healthcare Sector Impact

Healthcare is Akira’s most targeted sector by volume, accounting for an estimated 28% of 2025–2026 victims. The reasons are both strategic and structural.

Healthcare organisations face extreme operational pressure when clinical systems go offline. Encrypted VMs hosting electronic health records (EHR), PACS imaging systems, and pharmacy management software create immediate patient safety risk. Modern hospitals run deeply virtualised infrastructure, so a single Akira ESXi campaign can simultaneously take down radiology workstations, nursing station applications, and lab information systems. Organisations without cold backups or tested ESXi recovery runbooks often face 2–6 week recovery timelines.

Notable healthcare incidents (anonymised):

Regional hospital network (4 facilities): 6-week partial outage, $3.2M payment after 12 days of negotiation, plus $8M in recovery costs
Specialty clinic group: Complete EHR loss for 2 facilities, $1.8M payment, restored from 3-week-old offline backups (significant patient record gaps)

Manufacturing Sector Impact

Manufacturing environments are attractive for different reasons: operational technology (OT) networks increasingly run on virtualised Windows infrastructure, and production disruption has direct, quantifiable financial impact that creates payment pressure.

Akira affiliates in manufacturing incidents have demonstrated awareness of OT context — identifying and targeting VMs labelled with production-relevant hostnames (SCADA, HMI, MES), timing encryption for production hours rather than weekends to maximise disruption, and including references to specific production lines or product data found during exfiltration in ransom notes.

Defensive Recommendations

Immediate architecture changes:

Isolate ESXi management interfaces: Move HTTPS (443) and SSH (22) management ports to a dedicated management VLAN accessible only from a bastion host or PAM solution. Remove access from general corporate networks.
Enable lockdown mode: ESXi’s lockdown mode restricts management to vCenter, reducing direct host attack surface.
MFA on vCenter: Enforce MFA for all vCenter authentication, including API service accounts where feasible.

Backup strategy:

Maintain offline or immutable backups of ESXi datastores, not just VM-level backups
Test full datastore restoration quarterly — not just individual VM recovery
Store at least one backup generation on infrastructure not reachable from the primary network

Detection:

Alert on esxcli vm process list and vim-cmd vmsvc/snapshot.removeall execution on ESXi hosts
Monitor for new SSH key additions to ESXi /etc/ssh/keys-root/authorized_keys
Alert on bulk VM power-off events in vCenter logs