Kyber Ransomware Double Trouble: Windows and ESXi Attacks Explained

Overview

For executive leadership, the emergence ofKyberransomware represents a significant and immediate threat due to its specialized, dual-platform deployment capability targeting mission-critical virtualization infrastructure (VMware ESXi) and core Windows file systems. This cross-platform approach, coupled with effective anti-recovery measures, drastically elevates the risk of a total operational disruption. Organizations should treat Kyber not merely as another ransomware strain, but as a specialized tool capable of causing a complete operational blackout. Recent real-world incidents have demonstrated that this approach can result in large-scale operational impact across enterprise environments.

During a March 2026 incident response engagement, Rapid7 recovered two Kyber ransomware payloads deployed in the same environment, one targeting VMware ESXi infrastructure and the other Windows file servers. This provided a rare opportunity to analyze both variants side by side. In March 2026, Rapid7 recorded over 900 ransomware incidents being publicly reported.

The ESXi variant is specifically built for VMware environments, with capabilities for datastore encryption, optional virtual machine termination, and defacement of management interfaces. The Windows variant, written in Rust, includes a self-described “experimental” feature for targeting Hyper-V.

Despite these differences, both samples share a campaign identifier and Tor-based ransom infrastructure, confirming coordinated cross-platform deployment. Notably, the ransomware’s cryptographic claims are not consistent across variants. The ESXi sample advertises “post-quantum” encryption using Kyber1024, but in practice relies on ChaCha8 with RSA-4096 key wrapping, while the Windows variant does implement the advertised hybrid scheme. As usual, ransom notes prove to be more aspirational than accurate.

Kyber is a relatively new ransomware group that has recently gained visibility. Despite this, public technical analysis of the malware remains limited. The lack of spotlight on the group presented an opportunity to share our findings with the community.

Technical analysis

Kyber is a cross-platform ransomware family targeting Linux/ESXi and Windows environments. Both variants share Tor infrastructure and a campaign ID, but differ in programming language they are written, crypto, and features. While both reference the same encryption scheme in their ransom notes, only the Windows variant appears to implement it as described.

		AES-256-CTR + Kyber1024 + X25519
		PowerShell Get-VM (experimental)
		11 commands (elevation required)

In addition, both variants share a common campaign ID and Tor-based infrastructure, including a negotiation portal and leak site, indicating coordinated operations across platforms.

Tor chat:Mlnmlnnrdhcaddwll4zqvfd2vyqsgtgj473gjoehwna2v4sizdukheyd[.]onion

Tor blog:Kyblogtz6k3jtxnjjvluee5ec4g3zcnvyvbgsnq5thumphmqidkt7xid[.]onion

Linux/ESXi variant

The Linux/ESXi variant SHA-256:6ccacb7567b6c0bd2ca8e68ff59d5ef21e8f47fc1af70d4d88a421f1fc5280fcis a 64-bit ELF executable, not stripped, written in C++ and statically linked against OpenSSL1.0.1e-fips.

The sample was developed to target ESXi environments. As shown in Figure 2, the help text for the required path argument explicitly references the datastore path /vmfs/volumes, the root directory in VMware ESXi hosts where VMFS (Virtual Machine File System) datastores are mounted. The malware also relies on ESXi-native tooling esxcli and targets VMware-specific paths and artifacts.

Figure 1: The binary’s help text names /vmfs/volumes as the intended target path.

The execution flow is straightforward:

1. Parse CLI arguments (pathrequired,sizevalidated 0–100)

2. Optionally enumerate and terminate VMs (vmkill)

3. Load embedded RSA-4096 public key

4. Initialize thread pool (capped at 12 threads)

5. Traverse directories and submit encryption jobs

Background execution

To ensure encryption continues after an SSH session ends, the malware implements adetachflag. When enabled, it forks and exits the parent process, allowing the child to run in the background. The child then callssetsid()to detach from the controlling terminal, avoiding the SIGHUP signal typically sent when a session closes.

This allows the attacker to disconnect safely while encryption of/vmfs/volumesdatastores continues uninterrupted in the background.

Targeting VMware

If thevmkillflag is set, the binary enumerates all running VMs before starting encryption. It forks a child process that executes the ESXi-native management command esxcli vm process list, redirecting its output to a temporary file. The output is then parsed line by line to extract Display Name and World ID pairs

If a whitelist is provideds are terminated sequentially using esxcli vm process killtype=softworld-id <id>, with the parent process waiting for each shutdown to complete before proceeding

Two implementation choices stand out here. First, the ransomware usesfork/execlprather thansystem(). By callingfork()and thenexeclp()directly, ransomware developers bypass the shell entirely. This means the arguments are passed as anull-terminated array of strings(argv) directly to the execve system call. If a VM name contained a space or a special character, asystem()call might crash or behave unexpectedly, but execlp ensures the command is executed exactly as intended. This suggests the developer is familiar with low-level system programming.

Second, the use oftype=softrequests a graceful shutdown rather than a forced termination. This likely reduces the risk of corrupting VM disk state prior to encryption. After issuing shutdown commands, the binary sleeps briefly for about ~2 seconds before continuing, allowing ESXi to complete the operation. 

Directory traversal

The malware performs a recursive directory walk to identify targets. Interestingly enough, it drops areadme.txtransom note into every folderbeforethe encryption routine begins. The traversal logic does not follow symbolic links,as traversing them can lead to unexpected areas of the filesystem. The sample does not implement an extension allowlist. Files are encrypted unless explicitly excluded.

The binary explicitly ignores files with the following extensions or names:

.xhsyw (already encrypted)
.locksignal, .processing, .cryptdata_backup
.tmp, readme.txt
.sf (VMware System Files)

Figure 2: Confirmed exclusion list from protecting in-progress files, already-encrypted files, and VMware system files from double-processing.

Encryption: marketing vs reality

The ransom note claims that for encryption it uses AES-256-CTR, X25519 and Kyber1024 algorithms. 

Figure 3: Ransom note embedded in the ELF binaries claims AES-256-CTR and X25519/Kyber1024 algorithms.

Our technical analysis, however, says otherwise. Decompilation of the core encryption logic shows the cipher is actuallyChaCha8. Two indicators support this conclusion. First, in theECRYPT_encrypt_bytessubroutine (Figure 5) the loop executes 8 rounds (i = 8; i > 0; i -= 2), and the code applies32-bit right rotationswith constants16, 20, 24, and 25. These correspond to the standard ChaCha left-rotation constants (16, 12, 8, and 7) defined in RFC 8439.

Figure 4: IDA decompilation of ECRYPT_encrypt_bytes function

Second, theECRYPT_keysetupfunction (Figure 6) uses the “expand 32-byte k” sigma constant. For 256-bit keys, the malware initializes its state by placing this constant in words 0–3 and the key in words 4–11 — mirroring the standard ChaCha layout.

Figure 5: IDA decompilation of ECRYPT_keysetup function

OpenSSL is statically linked but only handlesRSA-4096key wrapping. We did not find any “post-quantum”. The operator likely just copy-pasted the ransom note from a Windows variant that actually supports Kyber1024.

Partial encryption strategy

Partial encryption logic is size-basedencryptFilePartly()function.

• Files under 1MB: entire file encrypted

• Files between 1MB and 4MB: first 1MB encrypted

• Files above 4 MB: only a calculated portion of each file is encrypted, with the proportion controlled bysize; the program validates this value as 0–100 inmain(), and the default observed setting is 10.

• This approach significantly reduces encryption time while still rendering large files (e.g., VMDKs) unusable.

Encryption workflow

Each file is encrypted with a unique ChaCha8 key. Before encrypting the file, the binary creates a.locksignalfile and renames the original to.processingto prevent concurrency. It then checks the last 535 bytes for a metadata trailer containing the markers KYBER,CDTA, andATDC.If these are present, the file is skipped as already encrypted.

For new targets, the malware generates a 40-byte key/IV set and wraps it using an embeddedRSA-4096public key. This metadata is appended to the file and verifiedbeforeencryption begins. A redundant copy is also saved as <file>.cryptdata_backup. Encryption is performed in-place in 1 MB chunks. On success, the file is renamed from.processingto.xhsyw. Any files left with the.processingsuffix indicate an interrupted or failed encryption attempt.

Defacing every entry point

Even before encryption, ransomware binary replaces three specific files:

• SSH Accessreplaces/etc/motd(Message of the Day), displaying the ransom note immediately to anyone logging in

• Web Managementreplaces the VMware web UI index pages at both/usr/lib/vmware/hostd/docroot/index.htmland the Host Client interface at/usr/lib/vmware/hostd/docroot/ui/index.html.

Whether an administrator logs inmet with the ransom note. On non-ESXi systems where these paths don’t exist, the rename fails gracefully and execution continues

Figure 6: Execution log from REMnux test: defacement fails gracefully on non-ESXi, encryption proceeds.

Windows variant

The Windows sample SHA-256:45bff0df2c408b3f589aed984cc331b617021ecbea57171dac719b5f545f5e8dis a 64-bit PE executable written in Rust and compiled with MSVC (VS2022). Much like the ESXi variant, the Windows binary as well is not packed, obfuscated, or even stripped. It retains full Rust panic strings and cargo dependency paths, including the build pathC:Usersuser.cargoregistrysrcindex.crates.io-6f17d22bba15001f.

Additionally, the binary’sversionflag reveals the project name aswin_encryptor 1.0.

Figure 7: Ransomware’s CLI interface

The Windows binary exposes a minimal CLI (Figure 8), requiring thepathargument to specify the target directory. It also includessystemflag which is self-described as “experimental” and intended to enforce a hard-stop on Hyper-V virtual machines.

Ransomware initializes full runtime initialization, even if invoked with justhelpflag. It aggregates entropy from four sources: system time, Windows CSPRNG, processor-based entropy viaRDRAND, and running process data and producing ~30 KB of randomness to seed an internal AES-CTR DRBG. Unlike typical ransomware, which often relies only onBCryptGenRandom, this strain implements a custom entropy pipeline which suggests the developer cared about key material quality.

After initialization, the binary checks whether it is running with elevated privileges by attempting to acquireSeDebugPrivilegeand logs are printed to the console (see Figure 8).

This privilege check determines if the destructive commands will be executed. Without elevation, the binary only does file encryption. With elevation, it unlocks its full toolkit: killing services, modifying the registry, and wiping shadow copies to prevent recovery.

Service termination and anti-recovery

When running with elevated privileges the binary first terminates services matching five patterns:msexchange,vss,backup,veeam,andsqlusingOpenSCManagerA,EnumServicesStatusA, andControlServiceAPI calls. The malware forces the system locale toen-USbefore service enumeration. This normalization makes certain that pattern matching for service names remains reliable regardless of the victim’s native system language.

It then executes 11 commands viaCreateProcessWthat you can see in the table below

	powershell -ep bypass -nop -c “Get-WmiObject -Class Win32_ShadowCopy | ForEach-Object { $_.Delete() }”
	wmic.exe SHADOWCOPY DELETE /nointeractive
	vssadmin.exe Delete Shadows /all /quiet
	bcdedit.exe /set {default} recoveryenabled No	Disable Windows Recovery Environment
	bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures
	wbadmin DELETE SYSTEMSTATEBACKUP
	wbadmin DELETE SYSTEMSTATEBACKUP -deleteOldest	Delete oldest system state backup
		Stop IIS to release locked web files
	reg add HKLMSYSTEMCurrentControlSetServicesLanmanServerParameters /v MaxMpxCt /d 65535 /t REG_DWORD /f	Increase SMB concurrent connections
	for /F “tokens=*” %i in (‘wevtutil el’) do wevtutil cl “%i”

Table 2: 11 commands executed by ransomware if it ran with elevated privilege

Hyper-V shutdown

Ifsystemflag is set, the binary enumerates Hyper-V virtual machines

Get-VM | select VMId, Name | ConvertTo-Json
Stop-VM -Force -TurnOff

Figure 8: PowerShell commands used for Hyper-V termination.

Each VM is terminated with a “hard stop” (-TurnOff) which forces an abrupt shutdown, releasing file locks so the malware can encrypt. As noted in the CLI help text, the developer currently considers this Hyper-V functionality “experimental.”

File encryption workflow

For each file, the binary checks for a prior encryption marker to avoid redundant processing. If the file is locked, the malware uses the Windows Restart Manager to identify and terminate the responsible process. If access is still denied, it modifies the file’s permissions (ACL) toEveryone:FullControland clears theread-onlyattribute. It retries this entire sequence up to three times per file to ensure it can successfully open and encrypt the data.

Once encryption succeeds, the file is renamed with the.#~~~extension, and aREAD_ME_NOW.txtransom note is dropped in the directory. Each successful operation is logged to the console asSuccessfully encrypted <file>. File size: <size>. To maintain system stability and to keep the OS bootable, the malware excludes critical system directories and files from encryption listed below:

$recycle.bin,perflog,system volume information,thumb,programdata,appdata,microsoft,netframework,c$, all users

READ_ME_NOW.txt,lockerlog_*,processed_file.icon,ntuser.dat,ntuser.dat.log,ntuser.ini,desktop.ini,autorun.inf,ntldr,bootsect.bak,thumbs.db,boot.ini,iconcache.db,bootfont.bin

Cryptography

Unlike the Linux variant, this sample actually uses what it claims: Kyber1024 and AES-256-CTR.

The sample uses a hybrid encryption design. The embedded public key is validated against the expected Kyber1024 public key size of 1568 (0x620) bytes.

Figure 11: Public key size check (1,568 bytes / 0x620) with branch to error on mismatch

Following validation, the sample initializes an AES-256 CTR context using a 32-byte key, which it expands into a 60-word key schedule.

This confirms that Kyber is not used for direct file encryption. Instead, Kyber1024 protects the symmetric key material, while AES-CTR handles bulk data encryption. 

Registry artifacts and icon registration

When executed with elevated privileges, the malware assigns a custom icon to encrypted files by registering the.#~~~extension. It createsC:fucked_icondirectory, writesprocessed_file.iconto that location, and configures it in the registry as the default icon.

Figure 12: Regedit output after execution of Kyber with elevated privileges

The malware executesie4uinit.exeto refresh the shell icon cache. This forces Windows to display the new icons immediately across the filesystem without a system restart.

Mutex

The choice of the mutex is interesting. The mutex nameboomplay[.]com/songs/182988982is stored as a wide string in.rdataand appears to be a link to a song on Boomplay, which is a legitimate African music streaming platform. We were unable to identify the specific track due to geo-restrictions we could not bypass.

Mitigation guidance

Based on the observed Tactics, Techniques, and Procedures (TTPs), organizations should focus on the following defensive actions:

Harden virtualization infrastructure (T1021.004)

Kyber’s reliance on SSH for ESXi host access and native tooling likeesxclihighlights critical control points.

• Implementleast-privilege accessfor ESXi shell and SSH, ideally disabling them entirely unless required for maintenance.

• Enforcemulti-factor authentication (MFA)on all management interfaces and accounts.

• Monitoresxcliexecution for VM termination (vm process kill) or configuration changes, which are late-stage indicators of compromise.

Prevent anti-recovery (T1485, T1070.001, T1562.001)

Kyber uses 11 distinct commands to impair defenses, including VSS deletion and log clearing.

• Restrict execution:Prevent unprivileged users from executing command-line utilities likevssadmin.exe,wmic.exe, andwevtutil.exe.

• Protect backups:Ensure backups (especially Veeam/SQL targets) are immutable and stored off-host or in segregated network segments that the Windows variant cannot reach, even with elevated privileges. The ransomware explicitly targets these services and file systems.

Detection focus (lateral movement & defacement):

• Monitor for defacement artifacts:Actively monitor for changes to VMware’s management files (/etc/motd,/usr/lib/vmware/hostd/docroot/index.html, etc.) in ESXi environments.

• Custom entropy check:The Windows variant’s custom entropy pipeline suggests an effort to ensure key quality. Analysts should incorporate the provided IOCs (mutex:boomplay[.]com/songs/182988982) and file extensions into their detection rules.

MITRE ATT&CK techniques

		Primary objective for both variants.
		Deletion of shadow copies and backups viavssadminandwmic.
		Terminating ESXi processes and Windows database services.
	Indicator Removal: Clear Windows Event Logs	Usingwevtutilto clear logs after infection.
		Primary vector for interacting with ESXi hosts.
	Impair Defenses: Disable or Modify Tools	Disabling Windows Recovery Environment and boot failure prompts.

Indicators of compromise (IOCs)

	6ccacb7567b6c0bd2ca8e68ff59d5ef21e8f47fc1af70d4d88a421f1fc5280fc
	45bff0df2c408b3f589aed984cc331b617021ecbea57171dac719b5f545f5e8d
	4ed176edb75ae2114cda8cfb3f83ac2ecdc4476fa1ef30ad8c81a54c0a223a29
		Encrypted file extension (Linux)
		Encrypted file extension (Windows)
		Mutex used by the Windows variant

Conclusion

Kyber ransomware isn’t a masterpiece of complex code, but it is highly effective at causing destruction. It reflects a shift toward specialization over sophistication. The operators didn’t need custom exploits or zero-days, because they didn’t have to use them. Instead, they simply used the standard ransomware playbook of abusing native tools like esxcli and vssadmin, and it was enough.

The encryption claims in the ransom note aren’t the main story. If anything, they highlight a gap between the campaign’s marketing and its execution.The sophistication of the defense must now be measured against the attacker’s specialization, not their code complexity. Ignoring Kyber’s multi-platform nature is an acceptance of a total operational blackout.

Article Tags

• Malware
• Ransomware