Case study
Qilin encrypts a game studio's ESXi version control and build environment
Qilin encrypted a studio's Perforce/GitLab repositories, build machines, internal test servers and art asset servers across three ESXi hosts, deleting VM snapshots and exfiltrating unreleased art and design documents. Recovery combined storage-layer snapshots, VMDK structure repair and developers' local working copies, followed by an exposure assessment and management-plane hardening.
- Industry
- Gaming & Interactive Entertainment
- Family
- Qilin
- Scenario
- Virtual Machines Encrypted
- Handled
- 2026-07
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.
约 91%
Development data recovered
28 / 31 台
Virtual machines recovered
约 5 个工作日
Core dev environment back online
0
Ransom paid
Incident background
The client is a mid-sized game studio of just over a hundred people, working on an unreleased mobile title while shipping updates for a live product. Its development infrastructure sits on three ESXi hosts: Perforce and GitLab repositories, automated build machines, internal test servers, art asset servers and test environments — just over thirty virtual machines, all on datastores backed by a single SAN.
Outsourced artists and remote staff reach the development network over one SSL VPN, and several VPN accounts had no multi-factor authentication, including a long-dormant contractor account with a weak password. The virtualisation management plane was directly reachable from the office network, and operations staff routinely saved the vCenter password in a browser.
The incident happened late on a July weekend. On Monday morning the lead programmer found the repositories unreachable and vCenter rejecting logins. From the ESXi console the guests had been powered off within the same window; vmdk and vmx files in the datastore carried an appended random string, ransom notes named README-RECOVER-[random].txt sat under /vmfs/volumes, and every VM snapshot had been deleted. The note, customised for the victim, named the unreleased project by codename, supplied a Tor entry point with a per-victim company ID and threatened to publish the stolen art and design documents.
The Veeam repository was mounted over iSCSI from the same storage and was damaged with it, with no offline copy; the array snapshot policy covered only the two volumes holding the repositories and art assets.
What we did
Containment went out on the first call: keep the ESXi hosts powered but off the network; do not reinstall a host, create or resignature a datastore, or power on guests. In parallel the storage administrator suspended snapshot reclamation and overwrite policies on the array so usable restore points would not age out.
- Evidence and imaging. Block-level read-only images of the LUNs, plus hostd.log and vmkernel.log, SSH logon records and authorized_keys, vCenter event logs, and VPN and firewall records. All later work ran on copies.
- Family confirmation and recoverability assessment. Qilin uses no fixed extension, so the family was confirmed from the match between README-RECOVER-[random].txt and the extension string plus the RSA-wrapped block at the file tail — a Qilin ESXi encryptor. No public, free decryptor exists, so decryption was ruled out. Segmented entropy mapping of representative -flat.vmdk files showed skip-step intermittent encryption: large disks kept long intact stretches, while partition tables and the vmx and vmsd files of some guests were fully overwritten.
- Recovery. Three paths ran together: roll back the volumes holding the repositories and art assets from surviving array snapshots; for guests the snapshots did not cover, rebuild vmdk descriptors and the vmx, mount the disks and export Perforce depot and GitLab data from intact ranges; then close the gap after the snapshot point from developers' and artists' local working copies and archived build outputs. All work ran in an isolated environment with per-guest filesystem, repository and asset checksum verification.
- Attribution, exposure assessment and hardening. The intrusion chain was reconstructed, the exfiltration window and volume established, and directory listings compared to scope the art assets, design documents and test-account data involved. Hardening ran alongside: MFA on every VPN account and dormant ones removed, contractor access moved onto a controlled path authorised per work order, the management plane isolated with lockdown mode on, persistent SSH disabled, browser-saved operations credentials banned, and the backup repository separated from production storage with immutable backups.
- Deliverables. Recoverability assessment, recovery inventory with an explicit data-gap list, exposure assessment and notification recommendations, and an attribution and hardening report with follow-up guidance. No ransom was paid and there was no contact or negotiation with the attackers.
Recovery result
The repositories, build chain and art asset servers were back online in about five business days; 28 of the 31 affected virtual machines were recovered and verified, and development data recovery reached roughly 91% overall. The Perforce depot and GitLab repositories were restored to the last array snapshot taken before encryption, and the roughly six hours of commits made after that point were rebuilt from developers' local working copies and archived build outputs. The trunk was verified in the isolated environment to compile a playable internal test build.
What could not be recovered: two temporary build nodes and one test-environment VM, rebuilt rather than restored after assessment; about three weeks of player behaviour logs from the internal test server; and some intermediate art files never committed to version control: most source files sat locally with the artists, but layered and project files had gaps to redo against an asset inventory. Recovery and sign-off closed on the eighth business day.
Attribution: the attacker entered through a contractor VPN account without MFA, took the vCenter password from browser-saved credentials on an operations workstation, then pushed through vCenter and logged into ESXi over SSH to power off guests, delete snapshots and encrypt the virtual disks. Art and design documents for the unreleased project had been staged and exfiltrated before encryption. The client paid no ransom and did not negotiate; it issued scoped notifications to its publisher and partners from the exposure inventory and assessed notification obligations for the test-account data under the applicable cybersecurity and personal information protection rules.
Follow-up recommendations: daily immutable backups with an off-site copy for repositories and art assets, independent archiving of build outputs, quarterly review of VPN accounts and MFA coverage, and alerting on bulk outbound transfers and snapshot deletion.
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.
Gaming & Interactive Entertainment
A ransomware event at a game company usually runs on two separate loss tracks: the outage — account, top-up and leaderboard databases encrypted, with churn and refunds accruing by the hour — and double extortion over stolen source code, unreleased content and art assets. This page covers the typical entry points across live-ops and development environments, a recovery order built on data consistency and repository integrity, and how staged relaunch and exfiltration assessment are handled.
- No public decryptor
Qilin
Qilin (formerly Agenda) is a Rust-rewritten cross-platform RaaS operation focused on VMware ESXi and Linux estates. It has ranked as the world's most active ransomware group for several consecutive quarters since 2025, with confirmed victims among electronics manufacturers in Taiwan and Hong Kong.