Rapid7 has published a technical teardown of Kyber, a ransomware operation whose branding finally catches up to what every vendor has been predicting for three years: the first ransomware family to ship NIST-standardized post-quantum cryptography in a production encryptor. Sort of. During a March 2026 incident response, Rapid7 recovered two distinct Kyber variants deployed on the same network by the same affiliate, sharing the same campaign ID and Tor infrastructure. The Windows variant does implement Kyber1024 + X25519 + AES-CTR, a genuine hybrid PQC scheme. The ESXi variant advertises the same scheme in its ransom note, but the binary actually uses ChaCha8 wrapped under RSA-4096 — conventional elliptic-curve-era crypto with a marketing layer on top. The discrepancy matters, and we’ll get to why.

What got deployed, where

  • Kyber-ESXi: A Linux encryptor purpose-built for VMware environments. Enumerates and mounts all datastores visible to the hypervisor, optionally terminates running VMs via esxcli vm process kill, encrypts .vmdk/.vmx/.vswp/.log files in place, and defaces the VCenter/ESXi management UI with a ransom HTML page. Files are renamed from .processing to .xhsyw on successful encryption.
  • Kyber-Windows: A Rust binary. Walks mapped drives, network shares, and — via a feature the sample code itself labels “experimental” in source strings — Hyper-V volumes reached through the Microsoft-Hyper-V VSS provider. Same .xhsyw extension on success.

Both binaries are signed (self-signed certs, revoked at time of writing), share a hardcoded campaign ID, and phone home to the same .onion negotiation portal. That shared infrastructure is why Rapid7 is confident this is one operation with two encryptors, rather than two separately-sourced tools an affiliate happened to chain.

The crypto, accurately

The “post-quantum” framing is load-bearing in Kyber’s marketing because it’s the first ransomware family to claim it. That claim is only half-true at the binary level.

Windows variant (real hybrid PQC). Key protection is CRYSTALS-Kyber (Kyber1024) composed with X25519 in a KEM hybrid — standard post-quantum hedging, same pattern you’d see in a modern TLS 1.3 stack. Bulk file encryption is AES-CTR with a per-file symmetric key that gets wrapped by the hybrid. The Rust implementation appears to use the pqcrypto-kyber crate and x25519-dalek. At the cryptographic primitive level, there is nothing wrong with it; the affiliate who wrote this has read the NIST standardization documents.

ESXi variant (conventional crypto, PQC-themed ransom note). The binary ignores everything the ransom note promises. File encryption is ChaCha8 — already an unusual choice; ChaCha20 is the modern default and ChaCha8 is primarily used in contexts where speed matters more than an extra safety margin against cryptanalysis — with a 40-byte key/IV bundle generated per target. That bundle is wrapped using an embedded RSA-4096 public key. No Kyber. No X25519. Nothing post-quantum. The ransom note telling a Linux victim they were hit with Kyber1024 + X25519 + AES-CTR is a plain lie; it appears to have been copy-pasted from the Windows variant’s note.

The practical implication is that an RSA-4096 ciphertext captured today is not, in fact, secure against a future cryptographically-relevant quantum computer. For an ESXi victim refusing to pay and willing to wait two decades, “harvest now, decrypt later” is a real option — in the same way it’s a real option against any conventional public-key-wrapped ransom blob. For the Windows variant, it isn’t. So the customer-facing threat model of the two binaries is genuinely different, even though the branding treats them as one.

Why infrastructure engineers should care more than the average headline reads

The post-quantum angle is the headline, but it’s the less interesting half of the story. The real signal here is the ESXi variant itself. Over the last eighteen months, ransomware-as-a-service operators have treated ESXi encryptors as table-stakes add-ons to their Windows-first families — LockBit, Play, RansomHub, 8Base, Akira, the pattern is universal. Kyber continuing that pattern confirms it, and the ESXi variant’s feature set is specifically tuned to defeat the mitigations that a lot of organizations added after the 2023–2024 ESXiArgs campaigns:

  • Datastore enumeration through the hypervisor API rather than the filesystem, which means SLP-disabled / port-80-locked-down hosts are not out of reach.
  • Optional VM-kill before encryption, specifically to beat inline backup agents that rely on VM quiescence.
  • Management UI defacement as an extortion accelerant — the helpdesk at a breached shop now has to triage a visibly broken VCenter before they can even start recovery.

If your recovery plan for a ransomware hit on the virtualization tier assumes the ESXi hosts themselves stay up, this class of encryptor is designed to break that assumption.

Mitigation — what to do right now

  1. Audit who can reach the ESXi management plane. Port 443/5480/902 on the ESXi hosts and port 443 on VCenter should be reachable from an administrative bastion and nothing else. Any path from a general-purpose workstation network to ESXi management is a path Kyber-ESXi will take.
  2. Disable the vSphere Web Services API on hosts that don’t need it. If a host is managed exclusively through VCenter, it doesn’t need direct API access exposed; drop it at the firewall.
  3. Rotate any VCenter SSO credentials that have been reused from a Windows AD identity. The common access pattern for this family is: compromise a Windows admin → discover their VCenter login → reuse it.
  4. Pull datastore backups off the same cluster. If the backup datastore is mounted on the cluster it’s protecting, the ESXi encryptor will encrypt it. This bites people more often than it should.
  5. For Windows fleets: assume Hyper-V volumes are in scope. The “experimental” Hyper-V path in the Windows variant suggests the operator plans to generalize it. Backups of Hyper-V VHDX files need the same off-host treatment ESXi backups do.
  6. Don’t pay on the theory that “at least it’s not quantum-safe.” For ESXi victims this is technically correct — the ciphertext is RSA-4096 — but a decryption window measured in decades is not a recovery plan.

References