Yaamlabs
Ransomware

HYFLOCK ransomware's encryption bug and its limits

Check Point found a HYFLOCK build that encrypts only the first 4,096 bytes of large files. Why that recovers fragments, not files, and what to do.

By Yaali. November 12, 2026, 6 min read, Ransomware, Threat intel, Resilience.

Navy blue Yaamlabs cover with the text: HYFLOCK ransomware's encryption bug and its limits, 4,096 bytes, the only part encrypted

HYFLOCK is a ransomware family that does not stand still. Check Point's Exposure Management team tracked it through four separate builds between April and October 2026, watching the code change from one month to the next. The October builds were the ones that mattered, because they added file encryption, the ability to keep running through a Windows scheduled task, and reach into network shares.

One of those October builds was put together badly. A build dated October 17 was configured to encrypt files in full, but on larger files it scrambled only the first 4,096 bytes and left the rest readable. Check Point used that mistake to pull 73 intact pieces out of seven encrypted Office documents without ever finding the key. In a narrow way that is good news, but it is a long way from a decryptor, and it does not mean HYFLOCK files can be recovered. A different October build has the opposite problem, and it destroys data for good.

Timeline of four HYFLOCK ransomware builds from April to October 2026, showing the Rust core, the July loader, the early October carrier and the flawed October 17 encryptor

How it works

The October 17 sample is a standalone encryptor written in Rust. When it runs it registers a Windows scheduled task so it keeps executing, walks local drives and network shares looking for files, and tries to interfere with the system's own recovery options. Its configuration asks for full encryption of everything it touches.

The configuration and the result did not match. On larger files the build encrypted only the first 4,096 bytes, which is the first four kilobytes, and left everything after that point untouched. A small file that fits inside that first block can still be fully scrambled, so this is really a large-file weakness. The research team flagged exactly that limit, so do not assume it holds for smaller documents.

Leaving the opening bytes behind helps for a specific reason. A modern Office file, whether a Word document or an Excel workbook, is a ZIP archive, and inside it sit many smaller parts, such as the worksheet data and the shared-string table that holds a spreadsheet's text. Those parts are spread through the file, not stacked at the front. Because only the first 4,096 bytes were encrypted, most of those internal parts survived on disk.

Check Point recovered 73 of those internal components from seven encrypted Office files, and the components passed their cyclic redundancy checks. A cyclic redundancy check, or CRC, is a short checksum stored alongside ZIP data that a reader uses to confirm a block has not been corrupted. Passing that check means the recovered fragments were whole rather than garbled. The researchers did this without a plaintext key and without an RSA private key.

This is partial recovery of fragments and nothing more. Check Point did not rebuild a single complete file, did not recover an encryption key, and did not write a general HYFLOCK decryptor. Treating the bug as a route to your data back would be a mistake. It salvaged readable pieces of large Office files from one specific build, under lab conditions.

An earlier October build carried a different and worse defect. Its file processing could permanently discard parts of a file, which means some data would be gone even with the correct decryption key in hand. For anyone hit by that version, the key is not the whole answer, because the encrypted file itself is incomplete.

What changed across the four generations

The April sample was already a working Windows ransomware core written in Rust, so the group did not begin from scratch. In July the delivery method changed: a separate loader brought in the malware together with its configuration and key material, while the Rust foundation stayed the same.

The two October builds are where the behaviour broadened. The earlier of them used a small carrier program that unpacked and launched the real payload and tried to set up background execution through a scheduled task. The October 17 build dropped that carrier and ran as a single Rust encryptor that registered its scheduled task, encrypted files, and touched network shares in one package. Check Point did not see it spread across a whole domain, and the Group Policy spreading option was switched off in the configuration they recovered.

On October 13 the group posted eight victim claims on its leak site in a single day, across manufacturing, business services, government, retail and telecommunications. These are the attackers' own unverified claims, and Check Point's investigation did not establish how any of those organisations were breached.

Do and don't card on the HYFLOCK recovery bug: image disks and keep offline backups, do not pay assuming recovery or trust the bug for small files

What to do

Start from the assumption that you cannot decrypt HYFLOCK files yourself. The 4,096-byte bug is a last-resort way to salvage fragments of large Office documents from one build, not a recovery plan. If you are hit and have no clean backup, image the affected disks before touching anything, so a specialist can attempt fragment recovery from a copy rather than the original.

Keep offline, tested, immutable backups, and confirm they actually restore. The destructive October build is why this matters more than usual: when a build can throw away parts of a file, paying for a key does not guarantee the data comes back, so a backup you have restored from recently is the only dependable route.

A few controls catch a build like this early and limit how far it gets:

  • Restrict who can create scheduled tasks, and alert on new ones. HYFLOCK uses a scheduled task to persist, so watch Windows Security event ID 4698 and the Microsoft-Windows-TaskScheduler/Operational log for tasks created by accounts or hosts that have no reason to make them.
  • Limit network-share access to the shares each account genuinely needs, and strip broad write access to file servers. The October 17 build reached shares to encrypt beyond the local disk.
  • Segment the network so one infected host cannot reach every file server and workstation.
  • Monitor for mass file modification. One account renaming or rewriting many files in a short window, or files gaining a new extension across a share, is encryption in progress.

If you find an active infection, isolate the host from the network first to stop it reaching more shares. Preserve the ransom note and a sample of the encrypted files for identification, and only then start recovery from backup.

Building the detection and response side of this is security operations work: spotting the scheduled task and the burst of file changes, and knowing the first moves in the first hour. Cutting the blast radius ahead of time, through share permissions and segmentation, is safeguarding and hardening. For a focused look at where ransomware would spread in your environment, our on-demand risk reduction work targets that question directly. Open the chat and Yaali, our AI agent, will pass what you ask to the engineer who would do the work.


Sources: Check Point: HYFLOCK ransomware evolves with new builds and encryption weaknesses, Cyber Security News, GBHackers.

Read next

Back to the blog, or tell us about your system in the chat. Yaali, our AI agent, answers first and brings in an engineer.