March 22 2021
In the first article  of this series, we provided an in-depth analysis of the Mole02 Ransomware. In this part, we will examine the decryption and how we successfully exploited the poor encryption process in order to create a universal decryption tool  of the CryptoMix variant.
In part one we stated how we found clues that the Ransomware authors used a static public key for encrypting files of infected users. We speculated that if we could get access to one decryption tool from the malware authors, then there was a good chance we could patch it to work on all infected systems.
Stop, Collaborate and Listen
The ransom message said they would send a decryptor if a victim paid the 0.5-1.0 BTC (bitcoins). We don’t recommend paying a ransom , so we were not going to pay ourselves. Therefore, we needed to find a sample by other means.
During our investigation we made contact with @mavsec1337. They had obtained a decryptor from one of their customers, who unfortunately were victims of Mole02. They were also willing to share it with us and thus showing how important collaboration is within InfoSec.
We began the reverse engineering process of the decryption routine, and discovered a way to patch it so that it could recover files from all infected systems. This removed the impact for anyone infected by this variant. Nobody else needed to pay a ransom because the decryption tool was now available.
This was so successful that the malware authors were forced to update their practices and release a variant. In the cat-and-mouse game of malware both sides are constantly improving and the next variant is always potentially worse.
Patching the Decryption Tool
This section provides a high-level overview of the decryption routine within our lab.
As one would expect, running the tool without modifications fails, and we are presented with two messages that were useful for the rest of the analysis, as seen in the following snippet:
We can observe two things in the above. Firstly, the tool will attempt to retrieve the infected machine’s “DECRYPT-ID”. We can assume that this is based on this ID that the decryption key is retrieved in order to start the decryption process. Secondly, we can observe the “No correct PC” error message, as expected, showing that the provided tool was not the correct one for this infected lab machine.
Another interesting note was that there was absolutely no network activity during the whole execution of the tool. At this point, we were almost certain that only one decryption key was used regardless of the infected machine’s “DECRYPT-ID” value.
At this stage, we loaded the tool into Hex-Rays’ IDA  and looked for any interesting functions and, more specifically, comparisons. Straight away, we noticed two comparisons being performed by the tool, as seen in the following figure.
Notice the “No Correct PC” string on the right hand side that we obtained upon running the tool the first time round? That is the message you get when the tool does not run successfully. If we could somehow make the comparison so that this error is not reached, then something else would happen. So we attempted to patch the tool, be wild, and simply NOP sled our way to it! For this, we will use a debugger called “OllyDbg” , which will make it relatively straightforward. While IDA also has debugging and patching capabilities, we wanted to demonstrate different tools to you our treasured readers.
Loading the tool into OllyDbg, we find our comparisons again, as seen in the following screen capture:
In order to keep this article short and sweet, we will simply demonstrate what happens when we ignore the final outcomes (jumps) of each comparison so that instead of jumping to the “No Correct PC” error we execute another part of the program. By doing a “right click” on each jump (the “JE” and “JNZ” instructions above) then “Binary -> Fill with NOPs”, we get something like the following.
Finally, all that was left to do is apply the changes and save them to a new executable. By first doing a “right click” then “Copy to executable -> All modifications”. A new window should appear, where you can do another “right click” then “Save file”. We will give it a name of “mole02_decrypt_nops.exe”.
Now let’s see what happens when we execute this new file. For the purpose of this demonstration we have organised a directory with several files encrypted by the Mole02 Ransomware.
All is left to do now is execute our patched decryption tool. The following screen capture demonstrates what happens when we do so.
As seen above, the decryption routine successfully started, our files were decrypted and their original names and extensions restored. While this section provided a high level overview of how we went about patching the decryption tool, the next section goes into more depth regarding the decryption routine.
For the more curious of you, this section goes into detail about the main comparison that is being made. The program originally checks that the ID (“DECRYPT-ID” value) saved within the infected machine’s Windows registry matches the one present in the decryption tool. This can be observed in the following:
While Figure 6 shows the registry being queried for the “DECRYPT-ID” value, Figure 7 shows this value being checked against a value hard coded into the tool. This also confirms the findings presented in our previous analysis . It also highlights the main and most obvious weakness of this Ransomware variant, as it only performs a simple check before deciding whether to initiate the decryption routine, using a static public/private key pair. In fact the private key also can be retrieved, as seen in the following.
We hope this short series of articles has given valuable insight into analysing a typical Ransomware variant, as well as provided enough knowledge to help someone replicate similar findings out there.
Again, we never recommend paying the ransom following an infection. However if you do, please send us the decryption tool you are given (if any), and we might be able to help others who have been infected.