Cryptonite ransomware is a Free and Open Source Software (FOSS) program that was made freely available to the public via a now-blocked github repository. The toolkit, claimed as being used for research, grew in popularity in Fall of 2022. Cryptonite is written completely in Python and allows for customization via a GUI or by manually editing the code. When the repository was live, an executable called ‘exeGen’ was available to generate the malicious payload and modify variables such as BTC information, email, file extension, and NGROK server URL (examples in the code shown below). The code also allows for the attacker to specify directories for exclusion from the encryption process.
Figure 1 Cryptonite Custom Variables
The code requires a functional remote NGROK server to be deployed in order to function properly. Without the server deployed, the ransomware will not execute properly, and the files will not be able to be decrypted. Although the URL is customizable, use of NGROK is a hard coded requirement for the attacker. The attacker receives general information such as IP and location along with the key required for decryption. The IP and location information if collected via the use of IP Info (ipinfo[.]ip)
Figure 2 Function Examples
Figure 3 Tkinter UI
Due to coding flaws, Cryptonite often leaves the victim without a means to recover the files even if the ransom is paid. The victim’s files will encrypt whether or not the decryption key is sent to the attacker successfully, and if Cryptonite crashes due to an error or is forcibly closed, there is no way to decrypt the files afterwards. If Cryptonite is re-run, it will re-encrypt the files with a new key and void the original unique key. There is no ability to run Cryptonite in a decrypt only function. This frequently turns Cryptonite into a ‘wiper’ malware.
While reviewing the code, we identified that there are no functions to provide the ability to spread through a network. Cryptonite is a very barebones and simple ransomware strain. As a cryptor/wiper, identification of this malware’s behavior would be at the end of an attack chain.
Figure 4 Fake Update
As seen in Figure 4 above, when the payload is executed, a fake ‘Update’ popup spawns. This popup tricks the end user into believing that system updates are being downloaded to the system. In actuality, the code outlined in green in Figure 2 is being executed. Once the update bar in the popup reaches one hundred percent, the files are then encrypted. Post-encryption, an error may flash across the screen.
Figure 5 Common Error
When the error above is observed, Cryptonite becomes wiper malware as the files will no longer be recoverable via the decryption key.
Figure 6 Encrypted Files
Once the files are encrypted, they will have the Cryptonite file extension. The default file extension for Cryptonite is “.CRYPTN8”. This is customizable by the attacker and therefore is not reliable as a sole indicator of compromise.
Figure 7 Network Traffic
Every detonated sample of Cryptonite reached out to ipinfo[.].io and ngrok[.]io. The python functions that are responsible for this behavior can be seen in Figures 1 and 2.
Cryptonite is a simple malware with multiple quality issues within the code. The customization of variables by the attacker makes static IOCs more difficult to detect but hardcoded behaviors such as the use of ipinfo[.]io followed by connection(s) to ngrok[.]io allow for high-fidelity behavioral alerts. Both ipinfo and NGROK are legitimate tools used by multiple organizations today. The combination of ipinfo followed by ngrok traffic creates a unique thumbprint of Cryptonite behavior.
Figure 8 NetWitness Network Events
In Figure 8 we can see DNS and SSL traffic for both ipinfo and ngrok. This behavior was observed with every sample that was detonated/observed.
Figure 9 NetWitness Endpoint Events
In figure 9, we can see the network events captured by Endpoint (EDR). These events show that a file/process made a network connection and provides information around the connection.
Figure 10 NetWitness XDR (Network and Endpoint)
Figure 10 shows the NDR and EDR events together. We’re able to see the process/file that created the network connections along with contextual information around the network connection made. With the combination of this information, we can determine the filename of the malicious payload and pivot into a file analysis.
Figure 11 File Static Analysis
One of the first things we can analyze is a static analysis of the identified file. A static analysis allows us to look at any cleartext strings within the file along with imported DLLs, architecture information, compile time, etc. If a file is determined malicious, it can be downloaded for later detonation/ further analysis.
Figure 12 Advanced ESA Rule
A simple detection rule for Cryptonite behavior would be identifying the ipinfo followed by ngrok traffic as this occurred with every sample and would be uncommon when compared to normal use of these tools. An example rule is shown in Figure 12.
Figure 13 Cryptonite Incident/Alert
Figure 13 shows an example of an incident and associated alerts that are created as a result of the ESA rule in Figure 12. We’re able to visually see how the artifacts are correlated and reconstruct their associated events.
Cryptonite ransomware was a FOSS project on github prior to its being taken down in the autumn of 2022. The code has multiple quality issues that create higher risk of data loss for infected victims. Although the repository no longer exists, there are still new samples appearing in tools such as VirusTotal. An infected host has a high-probability of the malware turning into a wiper due to defects within the code such as any error related crash or service restart, or a re-run of the exe that would re-encrypt the data with a new unique decryption key, which in turn removes the possibility of data recovery.
The code provides a GUI for variable customizations such as email, BTC amount, BTC wallet, NGROK URL, filename, etc. This makes static detections more difficult since each infection may have different indicators of compromise, and both hardcoded requirements (ipinfo and NGROK) are common within development (non-production) environments. However, the combination of an ipinfo connection immediately followed by an NGROK tunnel connection is a unique fingerprint for which we can write a simple behavior based detection rule (Figure 12). Any infection leveraging the Cryptonite code will be identifiable via this network-based behavior. The use of an EDR solution such as NetWitness Endpoint will also assist with flagging any known hash values associated with this ransomware strain and provide host-isolation for further analysis and/or remediation efforts
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.