Payload Ransomware Decryption & Data Recovery

Payload surfaced publicly on 17 February 2026, with Windows encryptor samples and leak-site victim entries appearing in the same period. Qihoo 360's February 2026 ransomware landscape report listed it among the new double-extortion families of that month.

The encryptor is built on the Babuk source code leaked in September 2021, so some engines may classify samples as Babuk - yet the leak site, negotiation portal and branding are entirely new. Current research leans towards Payload not being a RaaS; the footprint looks like a lone operator or a small closed team. By early September 2026 third-party leak-site tracking had recorded over 70 named organisations across more than 30 countries, with manufacturing leading the sector mix. The most recent leak-site entry we can verify was posted on 20 August 2026, with no new listings in the roughly three weeks since, though the leak and negotiation sites remain reachable.

One caveat stated plainly: public information on this family remains limited. It rests on a handful of reverse-engineering write-ups plus leak-site telemetry, with no government or tier-one vendor advisory and no published incident-response reporting on the intrusion chain. No report confirms targeted operations against mainland China organisations either - but an opportunistic actor puts the overseas branches of Chinese enterprises inside its target space all the same.

Extension and note. The .payload suffix is appended to the full original name, so report.xlsx becomes report.xlsx.payload; base filenames are not rewritten. The primary note is RECOVER_payload.txt, commonly dropped at the root of C:\ and in encrypted directories, with a RECOVERY-xx0001.txt variant also observed. It demands contact within 72 hours and states a 240-hour negotiation window; no email is given, so negotiation runs only through a Tor portal with per-victim credentials. The ESXi encryptor's extension has not been consistently confirmed in public analysis and may differ from the Windows build.

Sample-level markers (useful for separating Payload from other Babuk-derived lockers):

• Mutex named MakeAmericaGreatAgain.
• A 56-byte structure appended to every encrypted file, obfuscated with a static RC4 key, carrying the victim public key and nonce.
• The executable renames itself into an NTFS alternate data stream (appending :payload) and marks itself delete-pending, hiding it from ordinary directory listings.

Bottom line. The .payload extension plus RECOVER_payload.txt is enough to attribute the family. Because the shared code lineage means AV engines may label it Babuk, do not go looking for a Babuk decryptor on that basis - the key schemes differ. Preserve three to five encrypted files and the original note for build identification.

An honest statement first: Payload's initial access vector is not publicly attributed. As of September 2026 no vendor or CERT has published a full intrusion chain or incident-response report for this family; the available material only covers what happens after encryption.

Two indirect signals are worth noting. Third-party leak-site tracking finds that roughly 40 percent of Payload's named victims have matching credential exposure in infostealer logs - correlation rather than causation. Separately, the ESXi build parses vmInventory.xml to enumerate VM disks, implying the operators expect hypervisor management access or SSH on the host.

Until the pathway is established, the practical response is to close the high-probability generic entries: enforce MFA on internet-facing remote access and VPN, patch edge appliances promptly, segment hypervisor management interfaces away from the office network and disable unnecessary SSH, tier domain administrator credentials, and run a dedicated infostealer sweep with credential rotation. None of this depends on family-level attribution, and it covers a large share of contemporaneous emerging crews.

Algorithms. A Curve25519 ECDH plus ChaCha20 hybrid. A fresh 32-byte ephemeral private key and 12-byte nonce are generated per file; the shared secret is used directly as the ChaCha20 key with no key-derivation step, and key material is wiped from memory after use. A 56-byte trailer obfuscated with a static RC4 key holds the victim public key and nonce for the operators' own decryption. Reverse engineering has found no exploitable cryptographic weakness.

Encryption coverage (public analyses disagree - measure it). Analyses agree that encryption proceeds in 1 MB chunks. They do not agree on how much of a file is covered: one describes a partial strategy processing roughly file size / 5 for large files, while another describes the whole file being processed sequentially before the trailer is written. The two cases mean opposite things for recovery. If measurement confirms partial coverage, database files, virtual disks and mail stores may retain substantial untouched regions that structural repair can exploit; if coverage turns out to be full, that route does not exist. Encryption offsets must therefore be measured on the actual samples rather than assumed from any ratio, and even under partial coverage how much is recoverable still depends on whether critical structures - page headers, metadata, partition tables - fell inside an encrypted region.

Anti-forensics and recovery inhibition. vssadmin deletes all shadow copies; event logs are cleared via wevtapi; ETW is patched in memory to blind telemetry; over 40 services are terminated, explicitly including SQL databases, Veeam backup and several endpoint protection products. Evidence therefore disappears quickly, and imaging early is disproportionately valuable.

Virtualisation and double extortion. The Linux/ESXi encryptor is a stripped ELF of roughly 39 KB written specifically for VMware ESXi. It uses libxml2 to parse /etc/vmware/hostd/vmInventory.xml, enumerating virtual disk paths before encrypting them - one compromised host takes down every VM running on it. Analysis indicates this ELF lacks the full anti-recovery feature set of the Windows build, so host-side logs and snapshots may not have been purged the same way and are worth checking early. Data is exfiltrated before encryption, with a file tree and countdown published on the leak site and staged release if no payment is made.