Posted on 16th August 2017 by Secarma Threat Intelligence Team

Mole02, alleged to be a variant of the CryptoMix Ransomware family, first emerged in June 2017. It was distributed via a malvertising campaign which redirected its victims to the Astrum Exploit Kit (also known as Stegano EK) [1], exploiting several vulnerabilities in Flash and Internet Explorer to spread [3, 4, 5].

The malware, which appends the .MOLE02 extension, to encrypt records utilises RSA and AES encryption ciphers to encrypt files. It then demands 0.5 or 1.0 Bitcoin to decrypt the data.

While the malware does not leverage any specific exploits following infection and does not contain worm-like behaviour, it consists of several distinct components, including:

  • File system activity - creating new files on the system and encrypting data
  • Network based activity - communicating with a remote C&C server
  • Persistence - attempting to remain after resets
  • Stealth - attempting to prevent security warnings

Described below is the analysis of the binary, our thought process, and clues which led us to create a universal decryption tool. Additionally, the profile also provides actionable blue team intelligence to assist organisations in reacting to current and future infections.

The scope of this article is limited to the sample received by the Secarma Threat Intelligence Team with the following characteristics [2]:

Filename SHA256 Hash Size (bytes) Compile Time Description File Type
CarrollPLC Soft ( 846416b8b5d3c83e0191e62b7a123e9188b7e04095a559c6a1b2c22812d0f25e 225280 2017-06-13 15:11:08 Main payload + Encryptor Win32 EXE
Table 1 - Mole02 Sample File Characteristics

It is not the intention of this article to examine the behaviour of the Exploit Kit and associated campaigns, which we will be discussing in future articles.

Start up and Control Flow Overview

This section provides a high-level overview of the malware's behaviour when executed within our lab. Additional details of the relevant functions can be found within the next few sections.

One of the first actions taken by the malware that we noticed was checking the current Windows charset. The following figure shows this check being performed.

Figure 1 - Russian Character Set Check

The following high-level source code is provided for simplicity to represent the above.

if ((v2 = GetDC(0), GetTextCharset(v2) == 204)) // IF RUSSIAN CHARSET
    ExitProcess() // EXIT PROCESS


As highlighted in the figure above, the “204” value is the character set being checked following the executing of the “GetTextCharset” [6] function. If this is matched, the malware exits. The function relies on the “WinGDI.h” library. A quick check shows the 204 character set is the value for the Russian charset, which can be seen in the below snippet.

#define ANSI_CHARSET 0
#define HANGUL_CHARSET 129
#define GB2312_CHARSET 134
#define GREEK_CHARSET 161
#define HEBREW_CHARSET 177
#define ARABIC_CHARSET 178
#define BALTIC_CHARSET 186
#define THAI_CHARSET 222
#define OEM_CHARSET 255

In other words, if the host's charset is Russian then it will exit the process and will not proceed to encrypt files.

When the malware executes successfully, runtime analysis discovered the sample disabled multiple services which could interfere with its execution, including: Windows Security Centre, Windows Defender, and the Windows Auto Update Service. Moreover, to prevent system recovery, the sample also deleted the host's shadow files. A more detailed view of each service's behaviour is shown in the figure below.

Figure 2 - Service Analysis

For a listed output of the above commands please refer to Appendix A.

The next stage of the malware revealed its networking capabilities, with a POST request sent to an external address. Although currently offline the external host responded with a public key.

Following the HTTP activity, the sample copies itself within the “%APPDATA%” directory, includes a Zone Identifier Alternate Data Stream (ADS), and then executes itself from there. For persistence, new registry entries are also created, shortly before starting the encryption routine, which encrypts, renames, and replaces file extensions with “.MOLE02”.

When User Access Control (UAC) is enabled the victim is shown an additional window to entice to allow the malware to execute, as shown below.

Figure 3 - Fake Error Message

Once clicked the user is prompted with the following UAC window, which loops a couple times unless permitted.

Figure 4 - UAC Prompt

The next few sections provide a deeper level of details for each stage of the malware analysed. For a summarised list of all indicators, please refer to the end of this article.


Shortly after starting-up, but before establishing persistence or encrypting the files, the malware attempts to communicate with an external host. A POST request is sent to hxxp://137.74.163[.]43/css/styless.php, containing data about the version of the sample (in this case “6”), as well as a unique identification number (“GUID”), which we have redacted. The following figure illustrates this.

Figure 5 - Request to "hxxp://137.74.163[.]43/css/styless.php"

Although the remote host is no longer responding to requests the full HTTP request and response was as follows:

Request Response
POST /css/styless.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded Host: 137.74.163[.]43 Content-Length: 47 Cache-Control: no-cache
HTTP/1.1 200 OK
Date: Wed, 14 Jun 2017 12:19:47 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.45-0+deb7u8
Vary: Accept-Encoding
Content-Length: 276
Content-Type: text/html

-----END PUBLIC KEY-----

Table 2 - Full Request/Response

Although the host responded with a public key, it was not required for operation. This was confirmed through further analysis which showed the same hard coded key, as evidenced below:

Figure 6 - Static Public Key (Disassembly View)

Initially our thoughts were that the GUID's linked to their respective public keys. However, since the same key is hard coded, it seems likely that all victims of this particular variant could benefit if the private key were recovered.

This was the only network request attempted, and our first clue which meant that the ransomware authors used a static public key for encrypting files of all infected users.

Networking - Indicators of Compromise Summary

Indicator Comments
C&C IP address
C&C resource
POST /css/styless.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: 137.74.163[.]43
Content-Length: 47
Cache-Control: no-cache


Full C&C request
Public key


File System

Following the malware start-up routine discussed previously and the initial network request initiated, a file is created on the system. The filename was identical on different hosts we tested, hence could be used as an early indicator of compromise prior to the encryption process being started. This is possibly a remnant of a previous variant, which would contain the fetched public key previously mentioned. The file name and full path is as follows, which may also contain a prefix:



Further into the infection, the malware then copies itself into the same directory ("%APPDATA%") under a different name associated with the infected user’s GUID, and creates a Zone Identifier Alternate Data Stream (ADS) containing a ZoneTransfer ZoneId value of “0” ("Local machine"). A Windows ADS Zone Identifier stores information about a file on whether it was downloaded from the Internet, and whether it should be trusted. The reason behind this action is so that once the sample establishes persistence within the Windows registry, as we will see in the next section, the malware is executed without the user being presented a security warning. By way of example, the following figures demonstrate what would happen if this ZoneId was either set to "3" ("Internet"), or "4"("Restricted sites").

Figure 7 - Zone Identifier: ZoneTransfer ZoneId = 3
Figure 8 - Zone Identifier: ZoneTransfer ZoneId = 4

As can be seen above, a ZoneId of “3” or “4” would display security warnings, whereas a ZoneId of “0” would successfully execute with no warnings. Alternate Data Streams (ADS) are often used by malware authors to either hide data or in this scenario, disable security warnings.

After these actions new registry entries are added. This is discussed in the next section. The new PE file is then executed, and once the encryption routine starts, the malware identifies user paths and file extensions to process and starts encrypting files. Encrypted files are renamed with a 128-bit hexadecimal uppercase value, and their extensions replaced with “.MOLE02”.

The malware then writes several notes containing instructions laid out by the developers on how to pay the ransom and decrypt the files, including the Tor service, address unique “DECRYPT-ID” (which we refer to as “GUID”), to the “_HELP_INSTRUCTION.TXT” files, which reads as follows:


All of your files are encrypted with RSA 2048 and AES-128 ciphers.
More information about the RSA and AES can be found here:

Decrypting of your files is only possible with the private key and decrypt program,
which is on our secret server.

Follow these steps:
1. Download and install Tor Browser: 
2. After a successful installation, run the browser and wait for initialization. 
3. Type in the address bar: http://supportjy2xvvdmx.onion/ 
4. Follow the instructions on the site.
!!! Your DECRYPT-ID: <GUID> !!!

Table 3 - Redacted Ransom Note ("_HELP_INSTRUCTION.TXT")

File System - Indicators of Compromise Summary

Files created (including Alternate Data Streams):




Before executing its encryption routine, the malware creates registry entries to persist on the host system. Each entry points to the executable within the "%APPDATA% folder, as seen in the previous section. The following figures are examples of registry entries created by this sample:

Figure 9 - Registry Entries Created


Registry - Indicators of Compromise Summary

Registry entries created:

Registry Key Value


Anti Disassembly & Debugging

In this instance the sample was found to be using two native Windows API functions for the purposes of anti-debugging.


This is the simplest API function for determining whether the calling process is being debugged by a user-mode debugger. It searches the Process Environment Block (PEB) structure for the field 'IsDebugged' and returns a zero or non-zero value whether a debugger is attached.

OutputDebugStringA and OutputDebugStringW

These functions can be used to detect the presence of a debugger by sending a string to a debugger for display. If called and a debugger is attached the call would succeed and display the predetermined string value.

No Anti-VM techniques were found, the sample ran without issue within a Virtualbox environment.

Post Infection Analysis

Following the analysis of the malware, we decided to investigate further the process a victim would go through to recover their files. Navigating to the Tor hidden service, as instructed within the “_HELP_INSTRUCTION.TXT” files, we are presented with the following interface.

Figure 10 - Mole02 Ransomware Tor Hidden Service (supportjy2xvvdmx[.]onion)

As seen above, 1.0 BTC is required to be sent a decryption software and the associated private key, which would be used to decrypt the infected victim’s files. Earlier reports regarding the Mole02 ransomware showed only 0.5 BTC were needed at the time.

After submitting our "DECRYPT-ID", we received the following message, just hours later:

Figure 11 - Mole02 Ransomware Ransom Email

As seen above, a payment of 1.0 BTC must be made to the given address to receive a private key that will decrypt the infected user’s files. This address differs from other reports we came across. We identified at least two Bitcoin addresses during our analysis:

Figure 12 - 1CzoVXuzrKAe6ancEdMsfSkyzWffzyakUe (

Figure 13 - 1Lt5w9Yow8Q6ZX3SxxAebc3Qp4oouwBUH7 (

As the figures above show, based on these two Bitcoin addresses, the ransomware authors gathered an amount of around £25,000 at the time of writing. It is likely however that other addresses were used, which would result in a higher sum.

Post Infection Analysis - Indicators of Compromise Summary

Indicator Comments
Tor hidden service (payment website)
Ransom return sender
Ransom Bitcoin address 1
Ransom Bitcoin address 2



This sample and campaign are surely related to the CryptoMix family, as examining the code within already well written research papers proves it. It doesn’t contain particularly advanced features such as those seen in more notable malware. However, this also means a relatively quick and easier creation process, as has already happened since the release of Mole02’s decryption tool [7].

Stay tuned for future analysis and more in depth security related research. In part two we will examine the decryption and how we successfully exploited the poor encryption process.

We hope this article has given valuable insight into typical ransomware actions and resulting observables and thus assisted in developing better and more robust blue team tactics.









Appendix A

mole02.exe (1596) "C:\Users\infected\AppData\Local\Temp\mole02.exe"
sc.exe (2572) sc stop wscsvc
sc.exe (1144) sc stop WinDefend
sc.exe (444) sc stop wuauserv
sc.exe (1752) sc stop BITS
sc.exe (2720) sc stop ERSvc
sc.exe (1960) sc stop WerSvc
vssadmin.exe (2040) vssadmin.exe Delete Shadows /All /Quiet
5CAE89D2.exe (2820) C:\Users\infected\AppData\Roaming\5CAE89D2.exe


Indicators of Compromise Summary

Indicator Comments
C&C IP address
C&C resource
POST /css/styless.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: 137.74.163[.]43
Content-Length: 47
Cache-Control: no-cache


Full C&C request
Dropped files (including ADS)



Registry entries created (with values)
Tor hidden service (payment website)
Ransom email return sender
Ransom Bitcoin address 1
Ransom Bitcoin address 2