Kyber's ESXi encryptor takes a percentage parameter. The binary validates it between 0 and 100, and the value Rapid7 observed was 10. On a 500 GB virtual disk that is roughly 50 GB touched, and with that the machine will not boot.
Rapid7 recovered two binaries on the same network during a March 2026 incident response engagement and published the analysis on 21 April: a 64-bit C++ ELF written for ESXi and a Rust PE for Windows servers. They share a campaign ID and Tor infrastructure, so everything points to one affiliate aiming at both halves of the same house. Worth saying up front: partial encryption is nothing new. LockFile was doing it by mid-2021 — encrypting 16 bytes out of every 32 to defeat the chi-squared analysis some products use to spot encrypted files — and since 2022 Black Basta, ALPHV/BlackCat, PLAY, Agenda and Qyick have advertised it to recruit affiliates. What Rapid7 adds is the disassembly with the numbers in plain view, and those numbers have concrete consequences for your recovery plan.
What it actually does to each file
It walks /vmfs/volumes recursively and does not follow symlinks. For each file, three bands:
- Under 1 MB: encrypted in full.
- Between 1 and 4 MB: only the first MB.
- Above 4 MB: a proportional slice, the configurable percentage Rapid7 observed set to 10.
Rapid7's stated reason: it cuts encryption time sharply "while still rendering large files (e.g., VMDKs) unusable". Encrypted files get the .xhsyw extension; it skips .locksignal, .processing, .cryptdata_backup, .tmp, readme.txt and .sf, the VMware system files.
90% of the VMDK is still yours, byte for byte, and it makes no difference. Rapid7 does not publish where that slice falls inside the file, and you do not need to know: a virtual disk with 50 GB of noise somewhere in it will not boot, and the contents will not be salvaged by hand on any timescale that helps. Resist the temptation to turn this into "ten times faster": we cannot claim that and neither does Rapid7 — it says encryption time drops sharply, with no factor attached — because walking the datastore, opening each file and waiting on I/O are all still there. What can be said is that the window between "it has started" and "it no longer matters" gets shorter, by an amount nobody has published. If your detection takes an hour, the exact factor is an academic argument: you are late.
Before encrypting, it switches off the witnesses
The on-host sequence is short. It enumerates with esxcli vm process list, kills with esxcli vm process kill type=soft world-id <id> — with an optional allow-list to spare specific machines — and, before encrypting anything, replaces three files with the ransom note: /etc/motd and the Host Client's two index.html files. We covered the switching-off-defences-first part in detail when we wrote about DeadLock and its list of services, so here we only note what changes on a hypervisor: the machines it kills are where your detection lives. Whatever is left to see, the host has to see.
There is no agent on the hypervisor, and that is not your oversight
Broadcom says it in its own knowledge base article, 330057: "It is not supported to install 3rd Party Agents or Antivirus Software directly on the VMware vCenter Server Appliance (VCSA) or ESXi hosts." You did not forget to roll the agent out to your hosts: it is not supported, and the day you open a case they will remind you. ESXi sits closer to a router's firmware than to a general-purpose operating system, and it is not built to run software written for Windows or Linux; what the article itself suggests is agentless tooling, some of which comes in over SSH, with everything that implies.
Defending the host comes down to three decisions, and none of them is a purchase. Who may talk to it: lockdown mode forces operations through vCenter, with two doors to audit because they stay open even in strict lockdown — the DCUI.Access list and Exception Users with administrator privileges, who keep DCUI, ESXi Shell and SSH. What it is allowed to run: execInstalledOnly blocks binaries that did not arrive in a signed VIB, and since ESXi 8.0 the internal runtime option ships activated by default; the boot option does not. So there is nothing to switch on here: there is something to check, namely that nobody switched it off to install something — common enough that Broadcom has its own article about hosts upgraded to 8.x showing it deactivated. What it ships out: remote syslog, because if your motd and Host Client get defaced, yesterday's copy needs to live on another machine. Our managed EDR/MDR does its job inside the virtual machines and on the servers; on the hypervisor, what you watch is the management plane. When a conversation about ESXi opens with "which antivirus do I install on the host?", it has gone wrong in the first sentence.
The ransom note does marketing too
The note the ESXi encryptor leaves behind boasts of "AES-256-CTR, X25519 and Kyber1024". The binary uses ChaCha8 and RSA-4096 key wrapping; Rapid7 pinned it down from the rotation constants and the "expand 32-byte k" sigma. No X25519, no Kyber anywhere. The Windows variant does deliver what it claims — Kyber1024 with a 1,568-byte public key, which is the right size, and AES-256-CTR for the bulk — so it is not that they cannot: it is that in the encryptor aimed at your hypervisor they did not bother. Rapid7's summary: ransom notes "prove to be more aspirational than accurate".
Take that detail to the board when the question of paying comes up. The actor lies on the spec sheet of its own product, where lying gains it nothing; the promise to hand your data back comes off the same press. This morning we wrote about the people who turn up afterwards offering to rescue you; this is the other end of the same rope.
Your backup is a target, not the fallback
The same affiliate's Windows variant stops services whose names contain msexchange, vss, backup, veeam and sql, and runs wbadmin DELETE SYSTEMSTATEBACKUP, also with -deleteOldest. Veeam is named explicitly in the list. It also carries an experimental Hyper-V feature: Get-VM | select VMId, Name | ConvertTo-Json to take inventory and Stop-VM -Force -TurnOff for a hard shutdown.
Translated: a backup administered with the same credentials as everything else is not a backup, it is another folder. We have written about the extreme version of this — the backup server sitting inside the domain it is supposed to restore — and it is still the circular dependency we meet most often. What does hold: retention the administrator themselves cannot shorten, pruning executed on the backup server rather than the client, credentials separate from the domain's, and at least one copy no production process can reach.
"Fine, I'll move to Proxmox"
We hear it often, and we understand it, but no. Halcyon documented the Linux variant of Pay2Key — detected in late August 2025 — with logic hand-written for Proxmox: it checks for /etc/pve, takes inventory with pvesh get /cluster/resources, stops VMs and containers with qm stop --skiplock and pct stop --skiplock, and on backups it first lifts the latch with pvesh set .../content/<backup> --protected 0 and then deletes them with pvesh delete. We went through that one with the pve-storage source in front of us: Proxmox's protected flag is not a lock.
A VMware to Proxmox migration is decided on cost, licensing and architecture, and there has been no shortage of reasons these past two years. But if someone is justifying it to the board on security grounds, that argument falls apart with the Halcyon analysis on the table: what there is less of today is encryptors written for Proxmox, and the attacker's market share is not a layer of your defence.
What changes the outcome this week
- Get the management plane off the flat network: vCenter, the hosts, the PVE interface, the iDRAC/iLO cards. It is the dullest item here and the one that changes the ending most.
- Named accounts and MFA on vCenter and on Proxmox. No shared root password half the company knows.
- Lockdown mode, SSH off outside a justified window, and a look at who is in
DCUI.Accessand on the Exception Users list: that is where the access you thought was closed slips through. - Host logs, off the host. If the management interface gets defaced, what happened before it needs to live on another machine.
- A timed restore of a large machine. Not "verifying the backup": booting it and watching the clock.
When we would not do any of this
If you run three hosts, one array and two IT people, do not spend this week reworking secure boot on your hosts. execInstalledOnly already ships on in 8.x, and where it will grate is the day a vendor asks you to run a loose installer or push an unsigned VIB: that is a decision, and it deserves to be written down. Start with the first item on the list and the last: the management network and the stopwatch. There is nothing to buy today either — the first four are configuration — and if someone offers you an EDR "for the hypervisor", the polite question is where exactly the agent gets installed.
In the end, the figure from this analysis that ends up in your minutes is not the 10%: it is the minutes between "this is encrypted" and "this machine is serving again". Our last full recovery drill took 14 minutes, and it is worth saying what that means: a planned drill on our own infrastructure, not a real incident with forensics in the middle, which looks nothing like it. It is a test of ours, not a service commitment; you will only know your own company's figure once you time it. If you never have, the RTO written in your plan is an intention, not a measurement.
Sources: the three size bands, the configurable percentage defaulting to 10, the line about rendering VMDKs unusable, the .xhsyw extension and the exclusions, the esxcli vm process list/kill sequence, the defacement of /etc/motd and the Host Client, the mismatch between the note (AES-256-CTR, X25519, Kyber1024) and the binary (ChaCha8 + RSA-4096), the genuine Kyber1024 in the Windows variant with its 1,568-byte public key, the stopped services, wbadmin DELETE SYSTEMSTATEBACKUP and the experimental Hyper-V feature — Rapid7, "Kyber Ransomware Double Trouble", 21 Apr 2026; third-party agent support on ESXi and VCSA — Broadcom, article 330057; what DCUI.Access users and Exception Users with administrator privileges keep under normal and strict lockdown (DCUI, ESXi Shell and SSH) — vSphere 8.0 documentation, Broadcom; the fact that the internal execInstalledOnly runtime option is activated by default from ESXi 8.0 while the boot option is not — vSphere 8.0 documentation, and hosts upgraded to 8.x showing it deactivated — Broadcom, article 401376; the history of intermittent encryption (LockFile in mid-2021 encrypting 16 bytes out of every 32 to defeat chi-squared analysis, later adopted by Black Basta, ALPHV/BlackCat, PLAY, Agenda and Qyick) — SentinelOne Labs, Oct 2022; the Proxmox-specific logic in the Linux variant of Pay2Key (/etc/pve, pvesh, qm stop --skiplock, --protected 0) — Halcyon, "Pay2Key Linux". The 14-minute drill is an everyWAN internal figure: it is what it took us last time, not a service commitment.
How long does it take you to bring a big machine back?
The disaster recovery we build is measured with a stopwatch, not a spreadsheet: immutable copies out of reach of production credentials, and a real, timed restore every quarter. If what you already have survives the test, we will say so and leave.
Talk to everyWAN