A .babyk Extension Is a Clue, Not a Recovery Plan
On encrypted NAS storage, fragile decryptors, and keeping a way back before attempting recovery.
A NAS is online. Its disks look healthy. The shares are visible, but the files no longer open, and their names now end in .babyk. A ransom note offers a simple explanation and, usually, an expensive solution.
It is an unsettling situation to imagine as an administrator: the storage is present, yet the business cannot use it. The temptation is to search for a decryptor and get something moving. I would start with a less satisfying question: what exactly has changed, and can we preserve it before changing anything else?
This is a discussion of published research and recovery practice, rather than a report of a particular customer’s incident. That distinction matters. A familiar extension cannot establish what happened inside an unfamiliar NAS.
Editorial illustration, not incident evidence. The depicted file states are possibilities to investigate.
First, separate four different problems
“The data is gone” describes an experience, not a diagnosis. I find it more useful to separate encryption, deletion, overwriting and corruption before discussing tools.
With encryption, transformed content remains. Recovery may depend on the right key, a compatible implementation and intact file metadata. Changing a filename back does not reverse that transformation.
With deletion, the filesystem may have removed a reference or released an allocation. Some underlying blocks might survive. Subsequent writes, snapshots, filesystem behavior and, on applicable devices, discard and garbage collection affect whether anything useful remains. A deleted filename is neither proof of destruction nor a promise of recoverability.
With overwriting, previous bytes in the affected region have been replaced. A decryption key cannot reconstruct unrelated plaintext that no longer exists there. Encrypted bytes are also written to storage, of course; the useful distinction is whether the original information survives in reversible ciphertext or has been lost through replacement, truncation or damage.
Corruption describes broken structure or inconsistent content. It might result from interrupted writes, an incorrect RAID reconstruction, storage faults, malware or faulty recovery software. It can coexist with encryption. Opening one file successfully does not settle the condition of its neighbors.
A conceptual triage aid; it does not diagnose a specific volume.
A family name does not establish compatibility
Babuk research covers Windows, ESXi and NAS implementations. Its leaked source also gave other operators material to reuse. A suffix alone cannot identify a build, its key pair or a suitable decryptor.
Kudelski Security’s 2023 analysis describes Curve25519-based ECDH: an ephemeral private key and the attacker’s public key produce a shared secret, from which symmetric key material is derived. The file’s ephemeral public key is stored at the end. That public value is useful metadata, not the missing attacker private key.
The same research maps ChaCha20 to its studied NAS code and Sosemanuk to ESXi; Windows uses HC-128. These are stream ciphers for bulk content transformation. ECDH provides key agreement. Those roles differ, and later derivatives need not retain either layout or algorithm.
For recovery, the practical consequence is modest: preserve the whole file, including its tail. Do not strip a suspected footer to make the size look right. Determine the actual format from samples; a footer length copied from another analysis is only a hypothesis.
Algorithm assignments refer to the implementations studied, rather than every Babuk derivative.
The ESXi warning deserves its own boundary
In April 2021, Emsisoft documented flaws in Babuk’s ESXi implementation. Files could be encrypted repeatedly. Another failure could leave a file merely renamed .babyk; the attacker's decryptor did not reliably distinguish that state and could damage previously intact content.
Get TUNGTEK Tùng 0963509115’s stories in your inbox
Join Medium for free to get updates from this writer.
That report concerns ESXi. It does not demonstrate the same defect in a NAS sample. The broader operational lesson is my inference: a recovery tool needs controlled validation before it receives the only surviving copy. An attacker supplying it is no assurance of sound engineering.
I would apply the same discipline to a reputable decryptor. Provenance helps assess software risk; it does not establish compatibility with an unknown file set. Testing on disposable copies protects against both incompatible software and ordinary operational mistakes.
Preserve the storage underneath the files
A multi-drive NAS has several layers: physical drives, RAID, possibly a volume manager, a filesystem, snapshots and application data. A healthy disk status does not validate that entire stack.
Before an intervention, record bay order, serial numbers, observed drive health, controller information and the storage configuration. Document earlier attempts, especially repairs, replacements and rebuilds. Do not assume a replacement disk is harmless just because the enclosure recognizes it.
Contain ongoing access and unnecessary writes. Decisions about power and volatile evidence depend on the situation; repeatedly rebooting a system is not a preservation strategy. A failing disk also calls for a different acquisition approach from a healthy one.
Forensic imaging should capture the necessary source media and metadata through a controlled process, using write blocking where feasible. Record acquisition logs, unreadable ranges and hashes. Hashes help establish the integrity of a captured artifact; they do not prove that every source sector was readable or that the files were healthy before acquisition. Preserve an acquisition master and analyze working copies.
Reconstruct RAID and mount filesystems in a manner that avoids source writes. Filesystem journal replay, automatic repair and an enclosure’s rebuild behavior deserve explicit attention. A tool described as “recovery software” can still alter storage if the surrounding workflow permits it.
Test a recovery hypothesis, then test the result
Choose representative copies across file types, sizes and directories. Include files that might be unaffected. Record input hashes and sizes, inspect headers and tails, and compare with known clean versions where available. High entropy alone cannot distinguish encryption from compression.
Run a candidate decryptor in an isolated working environment. Keep its version, parameters, logs and outputs. Prefer separate output files when supported. Otherwise, use expendable copies. Stop when the result contradicts the hypothesis instead of running several more tools over the altered output.
A successful exit status means a program completed its own checks. It does not mean a database is consistent or a business can resume.
For SQL Server, a plausible MDF header is a starting point. Restore or attach a working copy in an isolated environment, assess consistency and validate application records and relationships. Avoid destructive repair on the only copy. For virtual disks, mounting is an intermediate result: guest filesystems, applications and expected business data still need checking.
Keep a record of what was validated, partly recovered, damaged or not examined. Sampling supports a bounded statement about those samples. It cannot justify a recovery percentage for an entire NAS without further evidence.
Payment and free tools both need realistic expectations
Payment does not guarantee a correct key, compatible software or usable application data. It cannot undo unrelated data destruction, and receiving a decryptor does not establish whether information was copied out of the environment.
Free recovery is possible for supported cases. In January 2024, Cisco Talos described recovering Tortilla key material and sharing it with Avast. The resulting capability depends on supported variants and known keys. It is not a universal solution for .babyk files or a blanket answer for NAS storage.
I keep the technical references and NAS discussion together in the longer analysis on Ransomware.VN. The most useful question is still whether the evidence in front of us matches the proposed recovery method.
The recovery plan should leave room to be wrong without sacrificing the source. Preserve it, characterize the damage, test on copies, and verify the restored workload. When another method becomes available tomorrow, an intact original gives us somewhere to begin again.
Tùng TEK — TUNGTEK | IT & Data Recovery
