Global XMPP Android Ransomware Campaign Hits Tens of Thousands of Devices

Introduction

Ransomware has been a well-known method of attack in the PC world for quite some time. Many PC-based ransomware variants have been thoroughly covered and their malicious payloads described by security researchers.

In the past few years, however, a new breed of ransomware has appeared. This time, the target platforms are no longer workstations, but mobile devices.

With some famous examples like the Simplocker[1] and Koler[2] variants, this new breed seems to be here to stay.

A typical mobile ransomware infection begins when a user downloads a legitimate-looking application from a third-party application store and tries to install it on his Android device. Suddenly, his files, photos and other information are not accessible and a scary ransom note appears: “Your files have now been encrypted.” Sadly, he has to consider paying ransom to regain access to everything stored on his device.

Of course, you wouldn’t knowingly install any application that locks your phone or encrypts your files. However, the malware masquerades as a legitimate application, looking exactly like one you might find in the official Google Play Store. This makes the attack vector very successful, especially when it comes to mobile devices.

As we will show, these Ransomware attacks on mobile devices are a very serious threat, and show a high level of sophistication. We estimate that tens of thousands of devices have been infected. We have evidence that users have already paid hundreds of thousands of dollars to get their files unencrypted, and the actual infection rate may be much higher. This particular campaign, which uses a form of instant messaging called XMPP for its communication, is a well-orchestrated and ongoing threat, with new samples still appearing on an almost daily basis.

A new sample arrives

During our ongoing research in the field, we recently analyzed a new sample of this ransomware family.

This sample was previously reported by Avast, but we decided to try and investigate further.

Unsurprisingly, the same masquerade techniques we saw previously appeared here as well; the ransomware disguised itself as a legitimate video/flash player application, as shown below:

Figure 1 – A ransomware requesting admin permissions after installation

What happens next? The phone owner, now a victim, sees a message holding his data hostage. The official-looking message shown below is also not a new ruse: the “NSA” allegedly accuses the mobile phone holder of wrong-doings such as browsing to pornographic sites on his phone, or violating copyrights law by holding/using protected content such as video, music, etc. To regain access to his device, he will have to pay a “fine.”

The victim seems to have no alternative. The app can’t be removed by a regular user. Even if he were somehow able to remove it, his files would still remain encrypted. The ransom payment, however, will probably not reach the NSA but rather make its way to the hands of a cyber-criminal.

Figure 2 – Ransom Note

Evasion via XMPP

How does the attack work? And what makes it so hard to defend against?

Most ransomware variants use HTTP/S protocol to communicate with their C&C servers immediately before the file encryption process occurs. The encryption key is usually kept on the C&C server and the malware is able to receive it only after this communication is finalized. This makes it impossible to statically extract the key from the malware code, and also supplies a new set of encryption keys for each infected target.

In the eyes of the malware operator, the main pitfall of this technique is that it is easy for security vendors to detect and block the malware’s communication with its C&C server. (Blocking the malware’s traffic can be done either by signing a unique traffic characteristic, or by blocking the URL address or static IP of known C&C servers.) Without this communication, the malware cannot initiate the key exchange process and files are not encrypted.

Our Ransomware sample takes a different approach for its communications. It uses a common instant messaging protocol called XMPP (Extensible Messaging and Presence Protocol) to send information from the infected device and to receive commands such as encrypt user files with a given key encryption, send an SMS, call a phone number, etc.

Using XMPP makes it much more difficult for security devices to trace the malware C&C traffic as well as distinguish it from other legitimate XMPP traffic. It is also makes it impossible to block traffic by monitoring for suspicious URLs.

Furthermore, as this technique uses external library functions to handle the communication, the malware does not require any additional application to be installed on the device. As XMPP supports TLS, the communication between the client and the server is also natively encrypted.

Tracking the malware

During our investigation, we successfully obtained hundreds of thousands of XMPP messages sent between the C&C servers and the infected mobile devices.

After breaking the obfuscation scheme implemented in these messages, we were able to read most of the message contents. This led us to obtain evidence that suggests that there are tens of thousands of devices infected with this malware. We also observed that ~10% of the users paid between $200 and $500 in ransom to decrypt their files. This means that for every 10k infections, the malware authors raked in $200k-$500k. While these numbers are stunning, this might just be the tip of the iceberg, as our dataset is incomplete and the actual infection rate is probably much higher.

Prevalence

Although the majority of the victims we identified were in the United States, there were many victims located in other countries.

It appears the malware writers designed the sample so both the device’s location configuration and the mobile operator name are examined upon successful infection. As a result, the ransom message displayed actually matches the area where the device is located, making this a very sneaky malware.

Figure 3 – Geographical Spread

Figure 4 – Locale check and custom ransom message

Another fact we observed is that the malware operators use an automated process behind an anonymous TOR node to pull messages from the C&C and send back commands to the devices. This shows an extra level of sophistication from the attackers.

Moreover, the hundreds of thousands of messages we intercepted shows that this is not a trivial incident, but rather a very serious and orchestrated campaign.

Active Response

During our campaign research, we discovered dozens of XMPP C&C accounts related to this infection. Over the past few weeks we’ve informed the relevant XMPP server operators, and those accounts have been suspended. This action will effectively disrupt the communications of any currently infected clients and prevent the malware authors from controlling these devices. In addition, the files on any machines newly infected with these samples should be safe, as the malware won’t be able to effectively encrypt the files without the C&C commands. Unfortunately, new samples from this campaign are still appearing almost every day.

Figure 5 – A new sample infection VirusTotal report.

Technical Details

Configuration

Once installed and executed, the malware loads the internal configuration from an encrypted string embedded in its code. This configuration contains details required by the malware regarding how to handle C&C commands as well as the initial parameters for communication with the C&C. It also contains the XMPP user accounts and passwords.

This is an example of a configuration extracted from one of the samples:

Figure 6 – Malware Configuration

The above configuration is divided into two types of information. The first one is data the malware should use, for example:

The other data types in the configuration are the server commands and how they should be handled. They are stored in the configuration in this format:

COMMAND_[key] = [value]

For example, “COMMAND_BOT_ID = c6mbl8m5m6” (as seen in the image above) is the C&C command used to set the BOT_ID value.

When the C&C wants the infected device to set a new BOT_ID value, it will send the command: “c6mbl8m5m6” : “kc9j0kl04e2i”. From now on, the BOT_ID value will be set to “kc9j0kl04e2i”.

The following table contains detailed descriptions of all available server commands:

Understanding C&C Communication

All messages to and from the C&C are both encrypted and base64 encoded XMPP messages. The image below shows a typical decoded C&C response message. (Server response messages are in JSON format).

Figure 7 – Example of an incoming C&C command

By analyzing the initial bot configuration parameters, we can match the COMMAND keys received from the server to the ones generated by the bot.

The actions are performed in this example:

“1cb1j8g173”:”kkeagkelb3eck2bhfngh3eihg7g238ac” sets new communication encryption key. PRIVATE_KEY now holds the value of “kkeagkelb3eck2bhfngh3eihg7g238ac”.

“28bd1e459f“:”0e68g0iaheckm644j234laa57hjn7jhm” sets the ENCRYPT_PASSWORD value to “0e68g0iaheckm644j234laa57hjn7jhm“.

This is the actual key that is used to encrypt the files.

The C&C command “l6dfbm5061”:1 signals the malware to encrypt all the files on the device.

The last command in this example is “2jkkgd0ac5: fcjm5km41g dcb…”

This is a special command that directs the bot to change all the COMMAND parameter keys to the new ones found in the value array in the same order in which they appear. (The array delimiter in this example is the space character).

Malware Operation

The malware uses the shadow accounts in the configuration section to send an initial message to the C&C server.

It then waits for the proper C&C response before changing the configuration, typically to one that contains new XMPP accounts and various other commands.

This initial malware message is used to identify the device. It does so by sending the following information:

• BUILD_ID
• AFFILIATE_ID
• IMEI
• OS_Version
• OperatorName
• PhoneNumber
• Country

Figure 8 – Code snippet from the malware’s message construction function

Messages sent to the C&C are in this format:

“BASE64_ENCODE[ BOT_ID   CRC(Message)   URL_ENCODE( Encrypt(Message) ) ]”

Messages received from the C&C are in this format:

BASE64_ENCODE [CRC(Message)   URL_ENCODE(Encrypt(Message))]

After the initial message has been sent successfully, the malware sends periodic messages (within 60-150 minutes intervals) containing the BOT_ID value as identification, along with a flag that indicates whether files were encrypted/decrypted. If the user pays the ransom and enters a voucher code, the malware sends a message to the C&C with the voucher information. It waits for the server response with the additional command to decrypt the files.

Encryption Scheme

As stated previously, all messages to and from the C&C are encrypted using a custom encryption scheme. The encryption method is a very simple polyalphabetic cypher, where each message byte is XORed with the corresponding byte in the key value.

The following illustration demonstrates this process. For simplicity’s sake, we assume the PRIVATE_KEY value size is 4 bytes and that the message size is 9 bytes.

Figure 9 – Custom encryption scheme illustration

Or as we can see it in the malware code:

Figure 10 – Malware encryption function

While the initial message is sent with an encryption key (PUBLIC_KEY) value that can be statically extracted from the configuration section, the first C&C response usually supplies a new key set (PRIVATE_KEY) and the command to change it. Any further messages will now be encrypted with a new dynamically generated key that cannot be predicted.

These are the initial key values we extracted from the samples:

Automating the Analysis

Figure 11 – Output of CuckooDroid Automated Analysis Framework

Using CuckooDroid, an Automated Android Malware Analysis Framework developed by Check Point Software Technologies, it is possible to inspect the entire malware communication functionality in real-time and thus provide a detailed analysis to be used to research this sample and its variants.

Check Point Anti-Virus blade and Mobile Threat Prevention protects against this threat – Ransomware.Android.Simplocker

Related Hashes

b6af41680a0df23fe28355afa57047ae3fa8c0b5

a1a1645909a5f53b9faa019206884246e8995748

9d7dd656310e2c1a6c24568573beacab18cfabaa

c77dfe1c313121c0f23fadcfc4cb7c39f420b616

f6da9be8ebeed54b9d7d640518c073e43c633f46

a9d816d209ee2d6ffd0444f6e8db6c6afdf7ace9

7bca2740d9cdc1a6a23fe3e9a987697505e7ef2c

bdccca79e87fd68a204eace7e9a138582a6fe9c8

6608d7bec34659d00349b69faa780041254dca86

[1] Analyzed by ESET on june-2014 – http://www.welivesecurity.com/2014/06/04/simplocker/

[2] Analyzed by Bitdefender – http://labs.bitdefender.com/2014/05/reveton-icepol-ransomware-moves-to-android/