Babuk / BabyK on NAS: cryptography, data loss and forensic recovery

1. The 2021 leak and distinct NAS/ESXi/Windows branches

Babuk emerged in 2021. Leaked source code and builders allowed other groups to reuse components. SentinelLABS identified ten Babuk-derived ESXi locker families in its 2023 study, not as a current total for October 2026. [S2][S5][S7]

Kudelski Security describes the NAS branch as Go-based and buildable for ARM/x86. Other branches differ, and a shared extension or code ancestry does not prove shared key material, threat-actor identity or decryptor compatibility. [S2][S5]

• Distinguish NAS hardware, RAID volumes, filesystems, SMB/NFS/iSCSI and VM files residing on network storage.
• ESXi decryption success should never be extrapolated to NAS by default.

3. Emsisoft's verified ESXi decryptor failure

Emsisoft documented that an ESXi Babuk variant could repeatedly encrypt files or only rename files to .babyk without encryption. The attacker's decryptor could process unchanged files incorrectly and corrupt them. [S1]

This is documented for a studied ESXi sample; it does not prove an identical flaw for all BabyK NAS variants. Always test decryptors on verified copies and validate with the creating application. [S1]

• Never run decryptors on the sole original data copy.
• Start with representative copies and check application-level results.
• Pause bulk decryption if unexplained errors occur.

4. Encrypted, deleted and overwritten require separate recovery methods

Encrypted content may survive as ciphertext. Deleted file references may leave recoverable blocks. Overwritten data may no longer contain plaintext even if a correct private key becomes available.

These states can overlap: malware may write encrypted copies before deletion, snapshots may be lost, and unsafe recovery efforts can trigger new writes. Filesystems, snapshot behavior, RAID, TRIM and garbage collection affect outcomes.


• Encrypted: assess headers, footers, transformed spans and known keys.
• Deleted: investigate metadata, snapshots, journals and allocation maps.
• Overwritten: identify damaged spans and partial salvage options.
• Corrupted: separate malware effects from RAID, filesystem and decryptor faults.

5. NAS forensics: preserve RAID and filesystem evidence first

For multi-disk NAS units, record drive identity and bay order, controller condition, RAID level, LVM, Btrfs/ext4 and snapshots before any recovery attempt. Wrong RAID reconstruction or unverified initialization can destroy remaining options.

Safe handling means reducing writes, obtaining read-only or forensic copies where appropriate, hashing copies and using a separate examination environment. Ransom notes and file extensions are starting indicators, not a substitute for storage evidence.

• Capture relevant logs, storage configuration and timelines.
• Label disk order prior to controlled handling.
• Avoid reset, format, initialize or rebuild on the only originals.
• Keep intrusion investigation distinct from file extraction.

6. Representative file analysis and application validation

Select samples across size and format classes: documents, images, archives, databases and virtual disks. Compare known-good exemplars where available, inspect magic bytes, per-region entropy, size deltas, pages and footer layout. Such observations help distinguish encryption from renaming or corruption.

Reading a recognizable header does not prove data restoration. Validate SQL databases for consistency and virtual machines for bootability and usable data. One file cannot represent the entire volume.

• Preserve encrypted originals for repeated analysis.
• Record file outcomes as valid, partial, unverified or damaged.
• Report only findings proven by the actual sample.

8. Ransom payments and a six-stage safe-response workflow

A payment cannot reverse overwriting or reconstruct irreversibly damaged filesystems. Emsisoft provides a concrete case in which an attacker-supplied ESXi decryptor could cause further damage; declaring every payment universally futile still goes beyond the evidence. [S1]

Suggested sequence: (1) isolate and halt writes; (2) document drive order, RAID and logs; (3) acquire verified copies; (4) identify file/metadata behavior and variant; (5) test recovery only on copies; (6) restore in a clean environment and validate access, application data and future backups.

• One successfully decrypted file is not a full recovery guarantee.
• Treat exfiltration risks separately from decryptability.
• Never publish a case-specific success probability without evidence.

9. Supported findings, remaining unknowns and next steps

Primary research supports distinct platform variants, broad reuse after source leaks, severe ESXi decryptor faults and recovered keys for some Tortilla variants. [S1][S2][S4][S5]

Without direct forensic evidence, one cannot conclude all files on a NAS were deleted, that original blocks were overwritten, that one key covers every file or that any particular recovery percentage applies. Artwork is editorial, not victim photography; AI assisted in preparing this article.

Research: https://Ransomware.VN. Specialist assessment and extraction of ransomware-encrypted data: https://CuuDuLieuMaHoa.com — TUNGTEK, +84 963 509 115. Preserve evidence and classify data state before attempting recovery.