Recovering from Kyber Ransomware on VMware ESXi Hypervisors

The attack typically starts with initial access through phishing, stolen credentials, or exposed remote access, followed by lateral movement across the environment as the attacker harvests additional credentials and escalates toward high-privilege accounts. With domain-level control established, the operator pivots deliberately into the VMware management layer, abusing stolen vCenter or ESXi administrative credentials rather than exploiting a VMware vulnerability. From this position, Kyber deploys two coordinated payloads in the same operation. 

ESXi Variant 

The ESXi variant is a C++ ELF binary delivered over SSH. It uses native VMware tooling such as esxcli to enumerate running virtual machines, optionally shut them down gracefully to avoid corrupting VMDK files, and then encrypts files across /vmfs/volumes datastores. For each target file, it generates a 40-byte key/IV pair, wraps that key using an embedded RSA-4096 public key, and encrypts the file in-place in 1 MB chunks. On successful encryption the file is renamed from a transient .processing extension to .xhsyw. The variant replaces the ESXi Web UI index pages so administrators encounter a ransom note before they can authenticate, writes extortion messages directly to datastore paths, and can detach into a background process to continue encryption after the SSH session closes. Despite the group’s branding, the ESXi encryptor does not implement Kyber1024 key encapsulation; it uses ChaCha8 as the stream cipher with RSA-4096 wrapping the per-file key. Rapid7’s analysis is explicit that the post-quantum claim on this variant is marketing. 

Windows Variant 

In parallel, the Windows variant — a Rust-compiled binary — encrypts file servers and executes an aggressive anti-recovery playbook. It does implement the advertised hybrid scheme combining classical and post-quantum primitives, but the cryptographic novelty is secondary to its pre-encryption behavior: it deletes Volume Shadow Copies, disables Windows Recovery Environment (WinRE) and Windows boot repair, terminates SQL Server, Exchange, and backup-related services, clears Windows event logs, and empties the Recycle Bin. There is an experimental Hyper-V targeting path the authors flagged in their own code. The shared campaign identifier and Tor infrastructure across both samples confirm the operator deploys them in tandem — the Windows build erodes endpoint recovery options while the ESXi build collapses the virtualization tier. The combined result is an operational blackout: production VMs are unavailable, hypervisor management is disrupted, and local Windows recovery paths are destroyed. 

Indicators to Monitor 

• The .xhsyw file extension appearing on ESXi datastores. 
• The .#~~~ files associated with VMware management interface defacement. 
• Sudden mass shutdown events across a VM inventory and unexplained esxcli activity. 
• PowerShell or vssadmin activity deleting Volume Shadow Copies on Windows hosts. 
• Lateral movement through native Windows administrative tooling (wmic, reg, PowerShell) following valid-credential access.

Recommended Actions for Cohesity Administrators 

Kyber is a ransomware operation, not a patchable CVE. Cohesity administrators occupy a unique vantage point — knowing which VMware and Windows workloads are protected, how frequently they are backed up, and whether recovery points are immutable and scannable. Treat this as a 30-day program, not a checklist. The actions below are ordered by impact on Kyber-specific risk. 

1. Inventory and Prioritize Virtualized Workloads at Risk 

• Identify Tier-0 and Tier-1 VMs (domain controllers, vCenter, backup infrastructure, databases) and confirm dedicated backup policies with immutability enabled. 
• Flag protected VMs where backup jobs show sudden spikes in changed data or entropy — the strongest Cohesity-side signal of Kyber’s 1 MB chunked in-place encryption. 
• Document the inventory and share it with VMware and SOC counterparts so everyone is working from the same prioritization. 

2. Validate Immutability and Admin Controls on Critical Backup Policies 

• Confirm DataLock (WORM) is enabled on every Protection Group covering critical VMware clusters and Windows file servers, with a retention lock that exceeds your expected detection-to-decision window (14–30 days minimum). 
• Verify Quorum is configured for destructive operations requiring multi-person authorization, so a single compromised admin cannot shorten retention or delete snapshots. 
• If using Cohesity FortKnox, confirm recent vault copies are current and access policies enforce isolation. The vaulted copy is the recovery source you actually want when ESXi hosts have been wiped. 
• Review Helios and cluster admin accounts for MFA, least privilege, and separation from domain admin accounts. Restrict administrative access to a privileged access workstation (PAW) tier. 

3. Scan Existing Snapshots for Signs of Compromise or Pre-Encryption Activity 

Cohesity hash- and IOC-based scanning inspects files inside backup snapshots against known threat indicators from Cohesity feeds and integrated engines such as Sophos. 

• Rapid Threat Hunt: Run IOC and hash scans on Windows workloads for Kyber PE samples and droppers; on VMware workloads, look for ransom notes and encryption artifacts (.xhsyw, .#~~~) in guest file systems. 
• Anti-Ransomware scan: Detect mass encryption through entropy spikes and coordinated file changes — often the strongest Kyber ESXi indicator when the host binary was never backed up. 
• Anomaly detection: Review alerts for simultaneous changed-data spikes across multiple VMs in the same cluster, and confirm alerts route to the SOC, not just to a backup admin’s inbox. 

Note: hash matching requires the malicious file to exist at backup time. Combine hash, entropy, and anomaly signals, and align snapshot selection to the suspected attack timeline. 

4. Ensure Recovery Readiness by Identifying Last Known-Good Snapshots 

• Identify the most recent snapshot taken before any suspected compromise window; document timestamp, policy, and retention. 
• Apply extended retention or legal hold if needed to preserve recovery points through investigation. 
• Document restore priority order: domain controllers and DNS first, then vCenter and ESXi, then application tiers. 

5. Conduct a Hypervisor Ransomware Recovery Drill 

• Simulate loss of ESXi Web UI access and mass VM unavailability. 
• Practice recovery to a clean, isolated network segment using Cohesity instant recovery. 
• Validate restored VMs pass malware scanning in a clean room before production reconnection. 
• Confirm RPO and RTO targets for multi-VM sequential restore — most organizations discover their RTO assumptions are off by an order of magnitude during their first real rehearsal. 

6. Brief Your Counterparts 

• Walk the VMware admin team through the Kyber ESXi TTPs so they understand why disabling SSH on hosts, enforcing vSphere MFA, and locking down the management network is now a backup-recoverability issue. 
• Walk the SOC through your immutability posture so they stop treating “we have backups” as a binary. 
• Walk application owners through the RTO numbers you measured in the recovery drill so the next priority conversation is grounded in evidence. 

Conclusion 

Kyber ransomware is a reminder that the most dangerous attacks for data protection teams are the ones that target the virtualization layer. When ESXi datastores are encrypted, management interfaces are defaced, and Windows anti-recovery actions have destroyed local restore paths, the organization’s ability to resume operations depends entirely on whether immutable, scannable, tested backups were in place before the attack. 

Cohesity administrators are uniquely positioned to prepare for this scenario. They maintain inventory of the VMware and Windows workloads most at risk and control immutability policies. They can scan backup data for compromise and validate clean recovery before reinfection. They can drive the recovery drills that test the workflow that matters when production is affected. Endpoint controls, network segmentation, and vSphere hardening all matter — and your VMware and SOC teams should own those — but none of them are the recovery boundary. The recovery boundary is the Cohesity tier. 

For the latest malware advisories, adversary updates, and technical details, visit Cohesity REDLabs at https://www.cohesity.com/trust/redlab/advisories/.