Paying a ransom doesn’t guarantee you’ll get your data back—but what happens when the attackers themselves can’t recover your files, yet your security platform can?
Last week, Halcyon published our initial findings on a critical flaw in the Sicarii ransomware group’s encryption implementation. This wasn’t just a vulnerability—it was a fundamental bug that prevented the threat actors from decrypting victims’ files, even when ransom payments were made.
A Bug That Locked Everyone Out—Except Halcyon
The issue wasn’t a sophisticated defense mechanism—it was a coding mistake. Our analysis of Sicarii’s encryption logic revealed a bug in the group’s implementation that created scenarios where both victims and attackers lost access to encrypted data. No decryption key from the threat actors could fix what the flawed encryptor broke.
But here’s where it gets interesting: Halcyon could recover the files the entire time.
While the Sicarii group scrambles to fix their broken encryption implementation, Halcyon’s key material capture technology has been able to successfully recover encrypted files from affected samples the entire time. Our platform intercepted and captured the key material before the flawed routine could complete—meaning organizations protected by Halcyon could restore their data without payment, even when paying the ransom literally wouldn’t work. Our goal is to ensure we never reach the point of needing recovery. However, resiliency requires more than just protection, which is why we can prevent ransomware and recover if one of our customers falls victim to a completely novel ransomware attack that evades everything (an extremely rare occurrence).
Sicarii Is Fixing Their Code. We Still Have the Advantage.
Since our original alert, Sicarii has released updated versions of their encryptor that appear to address the bug we identified. This is expected behavior—threat actors monitor public disclosures and rapidly iterate their malware in response.
Halcyon continues to successfully recover files encrypted by both the flawed and corrected Sicarii variants through our key capture capabilities. You can see exactly how this works in the screenshots below, which walks through real-time file recovery using key material captured during an active encryption attempt.
What This Means for Defenders
This incident provides rare visibility into how live ransomware families iterate their code in real time. More importantly, it reinforces the need to have a ransomware resiliency strategy that doesn’t rely on paying a ransom to get your data back.
Even when the Sicarii operators have working encryption, payment still doesn’t guarantee recovery. Delays, disputes, broken decryptors, and extortion after payment remain common. Every incident response strategy should include technical validation of recovery options before deciding whether paying makes sense.
The broader lesson: having an anti-ransomware platform isn’t a backup plan—it’s a primary defense. When your security platform can recover files that even the attackers couldn’t decrypt, you’re not just protected. You’re staying one step ahead.
This Video Captures the Full Process of Sicarii Encrypting Files and Halcyon Recovering Them
Video Walkthrough Timeline:
Start – You can see the raw contents of three files: a zip, a pptx, and a pdf.
0:18 – Getting ready to run the Sicarii encryptor.
0:22 – Running the Sicarii encryptor.
0:28 – The encryptor starts collecting files for exfiltration into a file named “collected_data.zip”. In the background, it then attempts to upload this file to a remote location. This took a few minutes (which we have edited out of the video).
0:42 – Files are encrypted. Note the .sicarii file extension and the changed icons.
0:45 – The encryptor is done.
0:52 – Using the hex editor, we can see that the open files no longer exist (they were renamed by the ransomware). Instead, we see “?? ?? ?? ??” as the raw contents are no longer accessible.
1:05 – We open three encrypted files in the hex editor to view their contents.
1:13 – The Halcyon key material capture decryptor is executed in the background.
1:58 – The files are decrypted, the original file names are restored, and the file icons return to their original state.
2:10 – We open the same three files (now decrypted) in the hex editor and show the raw contents. The file headers are now clearly visible, confirming the decryption was successful.
Click Here For The Original Source.
