- Fortinet’s FortiGuard Labs team discovered that a variant of an open-source ransomware toolkit turned into a wiper accidentally.
- Cryptonite is an open-source ransomware toolkit that was available for free on GitHub until recently.
- The demonstration showed that when the program ends, the actual encryption key vanishes and not even the operator will have access to it.
On November 23, Fortinet‘s FortiGuard Labs published a post covering the Cryptonite ransomware, which is coded in Python. The open-source ransomware toolkit was available for free on GitHub, provided by a user CYBERDEVILZ until recently. The repository and its forks have been removed, for obvious reasons. It was using the Fernet module of the cryptography package and .cryptn8 extension.
From ransomware to wiper
Recently, FortiGuard Labs analyzed a new sample of the malware and published another report about it. According to the new report, published on December 5, a new sample of Cryptonite never offers a decryption tool, and thus acts as a wiper. We have already seen wipers act as ransomware in the past, but in this situation, it is a little different.
Cryptonite only implements barebone features for ransomware. It allows the operator to configure an exclusion list, server URL, email address, and bitcoin wallet, but still, it is very simple. It also lacks some important ransomware features, such as:
- Windows Shadow Copy removal
- File unlocking for a more thorough impact
- Defensive evasion (AMSI bypass, disabling event logging, etc.)
When analyzed, the team saw that the sample can encrypt files, as expected, but it doesn’t display the window allowing the victim to start the decryption process with the decryption key. At first, the team thought that it might be intentional and continued with static analysis.
The team created a diff between the decompiled code and the malware template from GitHub, which showed that five lines were removed while the program enumerates the filesystem. In the dynamic analysis, the team discovered that the ransomware fails when it tries to use the tkinter library in the warningScreen() function. At this point in this ransomware, the encryption process has already finished. The warningScreen() should show the ransom note and allow the victim to start the decryption. The team said,
« We can now see that the ransomware was not intentionally turned into a wiper. Instead, the lack of quality assurance led to a sample that did not work correctly. The problem with this flaw is that due to the design simplicity of the ransomware if the program crashes, or is even closed, there is no way to recover the encrypted files.
First, there is no way to run the program in a ‘decryption-only’ mode. Every time it is executed, it re-encrypts everything with a different key before offering the decryption to the victim.
Second, a key is generated to instantiate a Fernet instance for cryptography. This key is the real cryptographic key. However, it is never used again in the code and is not sent to the operator.
Another random number is generated. In the constructor of the Cryptonite class, the dkrpt value is used to populate the decryptPlease variable. Later, this key is sent to the operator. This is the key provided to the victim if a ransom payment is made. To check whether the victim has the correct key, the submitted value is compared to the decryptPlease. For the actual decryption, the Fernet instance that has already stored the initial generated key is used. »
Thus, the actual encryption key vanishes, when the program ends and even the operator can’t access it. In the case reviewed in this analysis, when the program crashes due to an exception, there is no way to recover the encrypted data.