Case study
INC Ransom encrypts a blockchain firm's ESXi cluster and explorer index database
Hosted chain nodes, validator proxies, the block explorer's PostgreSQL index and the development estate all ran on one ESXi cluster, which INC Ransom's Linux/ESXi encryptor shut down and encrypted. On-chain assets were untouched; recovery centred on resyncing nodes from the chains and restoring the index from immutable offsite backups, with a full audit of signing key custody.
- Industry
- Blockchain & Crypto
- Family
- INC Ransom
- Scenario
- Virtual Machines Encrypted
- Handled
- 2026-04
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.
约 94%
Overall business data recovered
38 台 / 46 台
Virtual machines restored
约 5 个工作日
Public services restored
0
Ransom paid
Incident background
The client is a blockchain technology company providing node hosting, a block explorer and data APIs for public and consortium chains. Production ran on a self-managed ESXi cluster: three hosts carrying 46 virtual machines, including full nodes and validator proxies for several chains, the explorer's PostgreSQL index and search services, the public API gateway, and a complete development and test estate.
Validator signing keys lived on dedicated signing appliances and hardware security modules in a separate rack, outside the virtualisation cluster. The hot wallet signing machine sat on its own network segment, but its administrative jump host shared the same operations accounts as the cluster.
Cluster management was published through an SSL VPN appliance several releases behind the vendor's advisories, and vCenter shared operations accounts with the Windows domain. Backups ran from a virtual machine inside the cluster to an NFS volume on the same storage, with a daily copy synchronised to immutable offsite object storage under credentials entirely separate from the production domain.
Early on a Sunday, alerts showed every node offline and the explorer returning 502. Administrators found the virtual machines bulk powered off, vmdk and vmx files in the datastore carrying an appended .INC extension, INC-README.txt and INC-README.html in the directories, and the office printers producing the English ransom note at the same time. Hypervisor snapshots and the NFS backup volume on the same storage had been wiped along with them.
What we did
Containment went out on the first call: pause automated withdrawals and signing and raise manual review thresholds; keep the ESXi hosts powered but off the management and storage networks, no reinstall and no datastore reinitialisation, and preserve the SSL VPN logs while revoking every active session and token.
- Forensic imaging. Block-level images and array snapshots of the datastore LUNs, plus ESXi logs, SSH logon records and vCenter events.
- Family confirmation and recoverability. The .INC extension, paired INC-README notes and the appended signature block identified the Linux/ESXi build of INC Ransom rather than a same-lineage variant such as Lynx; no public decryptor exists. Large -flat.vmdk files proved only partially encrypted with long intact stretches, while small vmx files were overwritten in full.
- Recovery. The immutable offsite backup survived and restored the index database to a recent pre-incident point, the gap closed by re-indexing. Nodes and validator proxies needed no backup: rebuilt clean and resynced from their chains. Remaining VMs were recovered by rebuilding descriptors and mounting the flat disks, then verified clean on an isolated segment before return to production.
- Keys and hardening. Signing key custody and access records audited, operations credentials and API keys rotated, the ESXi management plane moved to a dedicated VLAN with lockdown mode, the VPN appliance upgraded and decoupled from domain credentials, backups rebuilt on independent credentials with an offline copy.
- Deliverables. Incident report, kill chain timeline, exfiltration scope conclusion and a per-VM recovery inventory.
Recovery result
Thirty-eight of the 46 virtual machines came back online and roughly 94% of business data was recovered. The block explorer and public APIs were serving again within about five business days, with the index consistent with the chain head after re-indexing, and every hosted node and validator proxy caught up within about nine business days. Unrecovered items were mostly ephemeral instances and build artefacts in the development estate; with source in remote repositories, the client rebuilt them. No ransom was paid and no contact made with the attacker.
On-chain assets were unaffected: signing keys never entered the encrypted environment, and forensics reconciled on-chain transfers against internal approvals item by item, finding no evidence that the signing machines were accessed or keys exfiltrated. Because operations accounts were shared, keys were rotated and access paths narrowed anyway.
Forensics showed the attacker exploited an unpatched SSL VPN appliance to hijack an authenticated session, moved into vCenter on shared accounts, and deployed the Linux encryptor at host level after a bulk power-off. INC runs multi-layered extortion, and logs confirmed exfiltration before encryption, scoped to internal documents and customer contracts, with no personal identity records involved. We advised notifying affected partners and meeting reporting obligations.
Recommendations: patch edge appliances monthly, separate management from business domain credentials, and keep an offline backup copy with regular restore drills.
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.
Related content
ESXi / Hyper-V Virtualization Encrypted by Ransomware
Hypervisor-level encryption causes the widest blast radius of any ransomware event: dozens of production VMs go dark within an hour or two. This page covers what Linux ESXi encryptors actually do — shut down guests, encrypt vmdk, delete snapshots — the recovery value of flat disk files, and how Hyper-V and Proxmox cases differ.
Blockchain & Crypto
For blockchain firms, exchanges and custodians, mining operations and node providers, the attack surface sits almost entirely off-chain: nodes, index databases, KYC records and signing hosts are what actually get hit. This page covers the threat paths, a recovery approach built around key-custody audit and on-chain/off-chain reconciliation, and hardening priorities.
- No public decryptor
INC Ransom
INC Ransom emerged in 2023 and has passed 800 claimed victims by 2026, making it a top-tier RaaS operation. Marked by the .INC extension and INC-README notes, it exploits Citrix and SonicWall edge flaws and ships an ESXi encryptor. No public decryptor exists.