Posted on 19th April 2018 by Secarma Threat Intelligence Team

In the first article [1] 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 [2] 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 [3], 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 variantent 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:

DECRYPT-ID: *********
No correct PC

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 [4] 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.

Figure 1 - Comparison Check (Hex-Rays' IDA View)

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" [5], 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:

Figure 2 - Comparison Check (OllyDbg View)

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.

Figure 3 - NOP Sled (OllyDbg View)

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.

Figure 4 - Encrypted Test Files and Patched Decryption Tool

All is left to do now is execute our patched decryption tool. The following screen capture demonstrates what happens when we do so.

Figure 5 - Patched Decryption Tool Success

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.

Discussing Decryption

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:

Figure 6 - Windows Registry Query

Figure 7 - Queried ID Check vs. Hard Coded ID

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 [1]. It also highlights the main and most obvious weakness of this Ransomware variantant, 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.

Figure 8 - Hard Coded Private Key


We hope this short series of articles has given valuable insight into analysing a typical Ransomware variantant, 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.