Overview
Abyss Locker (also written as “Abyss”) first appeared in March 2024, announced through a dark web leak site claiming multiple victims in its first month of operation. Within six months the group had claimed over 60 victims across North America, Europe, and Australia. The group operates a double extortion model: encrypt the victim’s data, exfiltrate a copy, and threaten to publish on the leak site if ransom demands are not met.
What distinguishes Abyss Locker is its deliberate technical focus on VMware ESXi. Rather than deploying a Windows encryptor and relying on network share encryption to reach virtualised workloads, Abyss runs natively on ESXi hypervisors, encrypting virtual machine disk files directly. This approach maximises impact: a single successful ESXi compromise encrypts every virtual machine running on that host.
ESXi Targeting: Technical Detail
Abyss Locker’s Linux/ESXi encryptor is written in Rust. Rust-based ransomware has become increasingly common because the language produces single-binary executables without runtime dependencies, making deployment straightforward, and because Rust’s memory safety properties reduce the likelihood of bugs that would terminate the encryptor mid-operation.
On ESXi hosts, the encryptor targets the following file extensions associated with virtual machine storage:
.vmdk— virtual machine disk files.vmx— VM configuration files.vmsn/.vmem— VM memory snapshots.vswp— VM swap files.nvram— BIOS/UEFI state files
Before beginning encryption, the Abyss encryptor executes ESXi management commands to gracefully shut down running virtual machines:
esxcli vm process kill --type=soft --world-id=<vmid>
esxcli vm process kill --type=hard --world-id=<vmid>Shutting down VMs before encrypting their disk files avoids file locking that would prevent encryption and ensures the resulting encrypted .vmdk files are consistent and non-corrupted — a detail that matters for the ransom payment stage, as victims need confidence that decryption will restore working VMs.
The Windows encryptor uses AES-256 for file encryption with RSA-4096 for key protection. The Rust binary for Linux uses equivalent cryptographic primitives with the same key management pattern: a session key is generated per host, encrypted with the attacker’s RSA public key, and stored in a ransom note dropped alongside encrypted files.
Initial Access Methods
Abyss Locker has not been attributed to a specific initial access methodology across all victims. Observed patterns from incident response investigations include:
SSH brute-force and credential stuffing against ESXi management interfaces: ESXi hosts with direct internet exposure on port 22 (SSH) or 443 (web UI) are targeted with credential lists derived from previous data breaches and combinations of common default credentials.
VPN exploitation: Like many ransomware groups, Abyss acquires initial network access through vulnerabilities or compromised credentials in VPN appliances. Fortinet, SonicWall, and Pulse Secure vulnerabilities have all been observed in the intrusion chains leading to Abyss deployment.
Access broker purchases: Intelligence from ransomware ecosystem monitoring suggests Abyss affiliates purchase pre-established network access from initial access brokers, consistent with the broader RaaS ecosystem model.
Lateral movement from compromised Windows hosts: In enterprise environments with standard VMware deployments, the path from a compromised Windows workstation to ESXi hosts runs through vCenter Server. Abyss operators have been observed moving laterally to vCenter via credential theft before pivoting to individual ESXi hosts.
Leak Site and Extortion Model
The Abyss Locker leak site operates on Tor and uses a familiar double-extortion pattern:
- Initial encryption and demand delivered via ransom note dropped on the victim system
- Victim contacts the group via a Tor-based negotiation portal
- If no payment is received within a deadline (typically 7–14 days), partial data samples are published on the leak site as proof of exfiltration
- Full exfiltrated dataset published if negotiations fail
The group has shown willingness to negotiate downward from initial demands, a common characteristic of RaaS affiliates operating on a percentage-of-recovery model.
Ransom demands observed across known Abyss victims have ranged from approximately $100,000 to several million dollars, scaling broadly with the size and sector of the victim organisation.
Target Sectors
Analysis of Abyss Locker’s claimed victim list shows consistent targeting across several sectors:
Healthcare: Multiple healthcare providers have appeared on the Abyss leak site. Healthcare’s combination of critical operational systems, sensitive patient data with high regulatory exposure, and well-documented underinvestment in IT security makes it an attractive target.
Manufacturing: Industrial and manufacturing organisations frequently run VMware-based virtualisation for operational systems, ERP platforms, and production management applications. The operational disruption from VM encryption creates additional pressure to pay.
Financial Services: Law firms, accountancy practices, and financial advisory firms hold high-value client data with significant extortion leverage. Abyss has claimed victims in professional services categories adjacent to financial services.
Professional Services: Managed service providers, IT consultancies, and business services firms provide leveraged access — a single MSP compromise potentially providing reach into multiple client environments.
Defensive Priorities
Eliminate direct internet exposure of ESXi management interfaces. No ESXi host’s SSH port or web UI should be reachable directly from the internet. Place ESXi management interfaces behind a VPN or bastion host with MFA enforced. If ESXi management traffic is internet-reachable in your environment, this is the first remediation.
Audit ESXi credentials. Change default ESXi root passwords. Ensure ESXi service account credentials in vCenter are unique, complex, and not reused across other systems. Audit SSH authorised keys files on ESXi hosts.
Immutable backup of VM snapshots to an isolated target. Standard backup-to-network-share configurations are reachable from a compromised ESXi host. Abyss operators have demonstrated awareness of backup infrastructure and actively target it. Immutable backup targets (AWS S3 Object Lock, Veeam Hardened Repository, purpose-built backup appliances with isolated networks) are resistant to encryption.
Segment vCenter from general enterprise network access. The lateral movement path from Windows endpoint to ESXi via vCenter is a common ransomware route. Firewalling vCenter management access to a dedicated management VLAN, accessible only from specific jump hosts with MFA, significantly increases the attacker’s complexity.
Implement ESXi log forwarding. ESXi hosts generate authentication and VM lifecycle events that are valuable for detection. Configure syslog forwarding to a SIEM that is isolated from the production vSphere environment. Abyss’s pre-encryption VM shutdown commands (esxcli vm process kill) are detectable if ESXi host logs are being ingested.
Test VM restore capability. Organisations that have never tested a full VM restore from backup under time pressure will find the process slower than expected when it’s happening during an incident. Regular restore testing validates backup integrity and ensures the team can execute recovery without ransom payment.
Abyss Locker represents a technically capable group that has identified a productive attack surface — the virtualisation layer — that many organisations still treat as inherently isolated from general enterprise risk. The group’s Rust-based ESXi encryptor demonstrates genuine engineering investment in maximising impact per deployment. The defences are not complex, but they require deliberate action: none of them are on by default.