In the last issue of our Ransomware Roundup series, we discussed a publicly available open-source ransomware toolkit called Cryptonite. As part of that investigation, we also discovered a Cryptonite sample in the wild that never offers the decryption window, instead acting as a wiper. We recently saw an increase in ransomware intentionally turned into wiper malware, primarily as part of a political campaign. So in this post, we take a closer look at the Cryptonite wiper sample.
Affected platforms: Microsoft Windows
Impacted parties: Microsoft Windows Users
Impact: Encrypts files on the compromised machine without offering decryption
Severity level: High
Cryptonite Summary
Let’s start with the good news: since the release of our Ransomware Roundup and with the help of the security community, the Cryptonite source code was removed from GitHub (Figure 1).
Figure 1 – Source code was removed from GitHub
And even though the original repository was forked 41 times on GitHub, all of these were also removed.
Looking at the contributions of the repository, we can see that it was primarily developed by the CYBERDEVILZ group, with the help of only a few contributors (Figure 2).
Figure 2 – Contributions to the original repository
Cryptonite’s ransomware sample only implements a barebones ransomware functionality. The operator can configure a few things, such as an exclusion list, server URL, email address, and bitcoin wallet. However, the encryption and decryption are very simple and not robust. It also does not provide any of the currently typical (but more complex) ransomware features, including:
– Windows Shadow Copy removal
– File unlocking for a more thorough impact
– Anti-analysis
– Defensive evasion (AMSI bypass, disabling event logging, etc.)
Even though this ransomware variant provided an easy entry for newcomers to the ransomware business, it isn’t a serious tool.
Ransomware turned into a wiper
The sample we discuss in this post has the SHA1 hash of a891e774eeb9671ff2dd1334e1628ba18fb60575. We started to dig deeper into this sample because we have been actively hunting for wiper malware in the wild, and this sample acted like one.
Whether executed manually or in a Sandbox, it seems to function correctly at first. It shows a progress bar (Figure 3) as it pretends to be a software update. The progress, however, actually represents the progress of encryption. And, of course, it encrypts files as expected.
Figure 3 – Progress of encryption
However, it never displays the window that allows the victim to start the decryption process with the decryption key. Of course, there could be many reasons for this. But one possibility is that the threat actor intentionally turned this ransomware into a wiper. To validate this assumption, we turned our attention to static analysis.
Static Analysis
We knew from the source code on GitHub that the sample is a python program bundled with pyinstaller into an executable. I wrote a blog post about how to unpack such executables. Using those techniques, we unpacked the program with pyinstxtractor and decompiled it with uncompyle6. To determine whether the actor made any changes in the code, we created a diff between the decompiled code and the malware template from GitHub (Figure 4).
Figure 4 – Difference of the sample and the original template
You can see the analyzed sample on the left and the template from GitHub on the right. It looks like five lines were removed while the program enumerates the filesystem.
However, after further review of the code, it seemed that removing those five lines would completely break the program’s functionality. For example, Line 87 on the right is the only place where the fileLists variable is populated. It should contain all the files that will later be encrypted. This means that the code on the left should not encrypt any files. This was confirmed by testing the code separately.
To check whether our tools are lying to us (spoiler: they did), we looked at the Cryptonite.pyc (the file we used to decompile the code) on a python bytecode level. This is the intermediate language python uses in .pyc files. Figure 5 shows the assembly-like bytecode of the findFiles() function.
Figure 5 – Python bytecode of the findFiles() function
In Figure 5, between line 396 and line 412, we see the code from line 85 to line 87 shown on the right side of Figure 4. This indicates that the code is there but somehow got lost in the decompilation process. This is a lesson learned in reverse engineering: always double-check when something isn’t right.
Apart from this, there was no functional difference between the sample’s code and the template.
Dynamic Analysis
To investigate further, we turned to dynamic analysis. After several executions, we found the tool that gave us answers: running the sample in cmd.exe. There we can see the python exceptions once the program crashes, as shown in Figure 6.
Figure 6 – Python traceback after the program crashes
The traceback shows 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.
No Way to Recover
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, as shown in Figure 7, a key is generated in line 10 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.
Figure 7 – Initialization of the encryption keys
In line 12, another random number is generated. In the constructor of the Cryptonite class, the dkrpt value is used to populate the decryptPlease variable (Figure 9).
Figure 8 – dkrpt used to set up the decryptPlease variable
Later, this key is sent to the operator (Figure 8). This is the key provided to the victim if a ransom payment is made.
Figure 9 – Data sent to the ransomware operator
To check whether the victim has the correct key, the submitted value is compared to the decryptPlease, as shown in Figure 10.
Figure 10 – Checking the submitted key
For the actual decryption, the Fernet instance that has already stored the initial generated key is used.
Figure 11 – Decryption uses the Fernet instance
This leads to the problem that the actual encryption key vanishes when this program ends. Not even the operator will have access to 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.
Conclusion
This sample demonstrates how a ransomware’s weak architecture and programming can quickly turn it into a wiper that does not allow data recovery. Although we often complain about the increasing sophistication of ransomware samples, we can also see that oversimplicity and a lack of quality assurance can also lead to significant problems. On the positive side, however, this simplicity, combined with a lack of self-protection features, allows every anti-virus program to easily spot this malware.
Fortinet Protections
Fortinet customers are already protected from this malware variant through FortiGuard’s Web Filtering, AntiVirus, and FortiEDR services, as follows:
FortiGuard Labs detects known Cryptonite ransomware variants with the following AV signatures:
- W32/Filecoder.KY!tr
- W32/Filecoder.KY!tr.ransom
IOCs
- a891e774eeb9671ff2dd1334e1628ba18fb60575 – sample’s SHA1 hash
- hxxps://e4c0660414bf[.]eu[.]ngrok[.]io – reverse proxy
- bc1qrs642t7jv7chpy4qt9u0j7knqqt7e06hp68ddj – attacker’s bitcoin wallet
- vlastyjanov_at_gmail[.]com – email address in sample
FortiGuard Labs Guidance
Due to the ease of disruption, damage to daily operations, potential impact to an organization’s reputation, and the unwanted destruction or release of personally identifiable information (PII), etc., it is vital to keep all AV and IPS signatures up to date.
Since the majority of ransomware is delivered via phishing, organizations should consider leveraging Fortinet solutions designed to train users to understand and detect phishing threats:
The FortiPhish Phishing Simulation Service uses real-world simulations to help organizations test user awareness and vigilance to phishing threats and to train and reinforce proper practices when users encounter targeted phishing attacks.
Our FREE NSE training: NSE 1 – Information Security Awareness includes a module on internet threats designed to help end users learn how to identify and protect themselves from various types of phishing attacks and can be easily added to internal training programs.
Organizations will need to make foundational changes to the frequency, location, and security of their data backups to effectively deal with the evolving and rapidly expanding risk of ransomware. When coupled with digital supply chain compromise and a workforce telecommuting into the network, there is a real risk that attacks can come from anywhere. Cloud-based security solutions, such as SASE, to protect off-network devices; advanced endpoint security, such as EDR (endpoint detection and response) solutions that can disrupt malware mid-attack; and Zero Trust Access and network segmentation strategies that restrict access to applications and resources based on policy and context, should all be investigated to minimize risk and to reduce the impact of a successful ransomware attack.
As part of the industry’s leading fully integrated Security Fabric, delivering native synergy and automation across your security ecosystem, Fortinet also provides an extensive portfolio of technology and human-based as-a-service offerings. These services are powered by our global FortiGuard team of seasoned cybersecurity experts.
Best Practices include Not Paying a Ransom
Organizations such as CISA, NCSC, the FBI, and HHS caution ransomware victims against paying a ransom partly because payment does not guarantee that files will be recovered. According to a U.S. Department of Treasury’s Office of Foreign Assets Control (OFAC) advisory, ransom payments may also embolden adversaries to target additional organizations, encourage other criminal actors to distribute ransomware, and/or fund illicit activities that could potentially be illegal. For organizations and individuals affected by ransomware, the FBI has a Ransomware Complaint page where victims can submit samples of ransomware activity via their Internet Crimes Complaint Center (IC3).
How Fortinet Can Help
FortiGuard Labs’ Emergency Incident Response Service provides rapid and effective response when an incident is detected. And our Incident Readiness Subscription Service provides tools and guidance to help you better prepare for a cyber incident through readiness assessments, IR playbook development, and IR playbook testing (tabletop exercises).
Learn more about Fortinet’s FortiGuard Labs threat research and intelligence organization and the FortiGuard AI-powered security services portfolio.