Hazard Ransomware – A Successful Broken Encryptor Story
Ransomware encryption can be one of the most devastating security events for an organization, potentially halting operations and causing significant financial and emotional stress. If backups are unavailable or compromised, an impacted organization might have no other choice but to consider paying the ransom to recover their data. The situation worsens if the purchased decryption program (“Decryptor”) is faulty or the wrong key is provided. As noted in a previous blog post [1], GuidePoint Security strongly advises creating full backups of encrypted data before starting the decryption process. While it may seem counterintuitive, this precaution helps prevent irreversible data loss if issues arise during decryption.
During a recent engagement, GuidePoint encountered the issue of an unreliable decryptor again, this time associated with Hazard Ransomware. In this case, the Threat Actor provided a decryptor that was unable to properly decrypt all of the victim’s files due to a flaw in the ransomware encryptor program. This flaw manifested when two encrypts were executed within seconds of each other on the same system — In other words, their encryptor had a bug.
Hazard Encryptor
When this ransomware encryptor was executed, there were four major steps it took to encrypt the files.
- Identify targeted file based on file extension
- Encrypt specified chunks of data within targeted file
- Append a footer of data with the encryption initialization vector (IV)[2]
- Rename the file with the ransomware file extension
A race-condition occurred when the Threat Actor executed multiple encryptors on the same system. During encryptor execution, a brief window between step two and four allowed a second encryptor to re-encrypt the file before the filename change. It was evident that this scenario was not anticipated by the Threat Actor’s programmer as it also resulted in missing bytes in the data chunk mentioned in step three.
The correct structure of the footer of a Hazard encrypted file is broken down into three sections:
- 768 byte Hex String identifier
- 32 byte hash verification value – Wrapped in red
- 16 byte Initialization vector (IV) – Wrapped in blue
Figure 1 contains an example of the tail of a valid encrypted file footer, where the IV contains 16 bytes of data.
Figure 2 contains an example of an invalid encrypted file footer, where the IV was corrupted due to multiple encryptors running at the same time. While the hash verification value is still the correct 32 bytes, the IV is missing the last three bytes of data.
Despite only containing 13 bytes for the IV, the decryptor program still required the full 16 bytes to properly decrypt the data. Since this value was randomly generated by the encryptor, it was impossible to predict the value of the missing bytes. The number of missing bytes in the IV represents 256X possible values, where X is the number of missing bytes.
Solution
After identifying the root cause of the decryption failure, GuidePoint attempted to contact the Threat Actor to see if they could provide assistance. However, whether due to a language barrier or technical gap, their “technical support” seemed incapable of understanding the problem. Instead, the Threat Actor simply provided a renamed version of a previously provided decryptor and ignored follow-up questions.
Nonetheless, due to the importance of the files that were encrypted, GuidePoint was able to implement a solution to recover the corrupted encrypted file. By patching the Threat Actor’s decryptor binary, GuidePoint was able to brute-force all possible remaining bytes in the IV until the valid value was found, resulting in a decrypted file. In the example above, that was 16,777,216 possible values that were brute-forced.
Key Takeaways
Consider Ransom Payment Risk: When deciding to pay a ransomware actor, organizations must consider that paying the ransom does not guarantee the recovery of their data. Ransomware actors may not provide a working key either due to deceit or technical failure, such as software bugs or operator errors by their affiliates. We are, unfortunately, dealing with criminals and not professionals, despite what some of them might try to convey through their marketing. That said, it is the smaller and less established Threat Actors that present a higher risk of corrupting data in this way.
Identify Warning Signs: There were red flags in this case that were identified during the forensic investigation before the decryptor was obtained that could have indicated potential decryption issues. The Threat Actor executed multiple encryption executables on some of the impacted systems, and there were encrypted files that contained evidence of multiple encrypted file footers. These files have a higher risk of decryption failure, so they are an ideal choice for obtaining proof of decryption from the Threat Actor.
Create Backups of Encrypted Data: It is important to stress that this success story would not have been possible without backups of the original encrypted data. The initial execution of the buggy decryptor executable without the proper file footer could have resulted in further data corruption, making the possibility of restoration exponentially more difficult. The availability of the original encrypted files allowed GuidePoint to identify the root cause of the issue and formulate a viable solution.
Data backup best practices: With a proper backup strategy, and an optimal security posture protecting it, organizations will always be in a better restoration position if a ransomware event does occur. GuidePoint continues to stress the importance that organizations improve their backup security to limit the impact of ransomware attacks like this one.
CISA offers an excellent guide on preventing ransomware attacks and securing backups, available here.
[1] https://www.guidepointsecurity.com/blog/update-from-the-ransomware-trenches/