Android Locker Malware uses Google Cloud Messaging Service

Last month, we found a new android locker malware that launches ransomware, displays a locker screen on the device, and extorts the user to submit their bankcard info to unblock the device. The interesting twist on this ransomware variant is that it leverages the Google Cloud Messaging (GCM) platform, a push notification service for sending messages to registered clients, as part of its C2 infrastructure. It also uses AES encryption in the communication between the infected device and the C2 server. In this blog we provide a detailed analysis of this malware.

A quick look at the malware

After the user launches the infected app, it requests device administrator rights, as shown below.

Figure 1. Requesting device administrator rights

Once the user grants administrator rights, the following screenshot shows the display view of the malware.

Figure 2. A view of the malware while running

The locker screen is shown below.  It demands a ransom from the user of up to 545000 Rub (about 9000 USD) for unblocking the device.

Figure 3. The malware locker screen

How the malware works

Here is the detailed technical analysis on how this malware variant works. The following is the key code snippet used when the malware starts launching.

Next, we analyzed these three key classes.

1.     Jfldnam Class

This is a service class that is used for GCM registration. The key code snippet is shown below.

Through our analysis, the class “Yzawsu” is the class “GCMRegistrar”. You can refer to https://chromium.googlesource.com/android_tools/+/master/sdk/extras/google/gcm/gcm-client/src/com/google/android/gcm/GCMRegistrar.java to learn more.

It is used for GCM registration, and v8.efjmaqtnlsph() returns the sender_id.

The GCM Broadcast Receiver declaration in AndroidManifest file is shown below.

There are three services declarations in the AndroidManifest file.

The class kbin.zqn.smv.Ewhtolr is the GCM Service Class. The following is the code snippet from the class Ewhtolr.

In the subclass Hkpvqnb, the following code is used to handle the action of intent related to GCM. If the action is equal to “com.google.android.c2dm.intent.REGISTRATION”, it means that GCM registration has been successful. The malware handles the response from GCM server.

The function xmrenoslft is shown below. It stores the registration_id in local storage.

The registration_id is stored in com.google.android.gcm.xml.

After the GCM registration is successful, the malware sends RegId to the C2 server.

From the above figures we can see that the malware uses AES to encrypt the json data that stores the reg_id, and it then sends the encrypted data to its C2 server.  Here, we have modified the originally obfuscated class name and function name of the encryption for easier understanding. The captured traffic is shown below.

The original json data in the http request body is shown below.

The decrypted data in the http response is shown below.

2.     Locker class

This is used to gain device administrator rights.

3.     Omnpivk class

This is used to display a locker screen that demands that the user submit their credit card information in order to unlock the device. A code snippet of Omnpivk class is shown below.

The locker screen is loaded from the asset folder. It looks like this.

Figure 4. The malware locker screen

The following is an English version translated by Google Translate.

Figure 5. The malware locker screen (English version)

Once the device is locked by this malware, the locker screen is overlaid on top of the system window. Users are prevented from doing anything on the device until their bankcard info is provided. Once the user enters their credit card information, the malware sends it to the C2 server. The captured traffic is shown below.

The data in the HTTP post request and in the response are both encrypted with AES. The decrypted body data of the post request is shown below.

The decrypted response is shown below.

In summary, the following figure explains how the malware works, and the process of sending commands from the C2 server that are executed by the malware.

Figure 6. How the malware command structure work.

C2 server sends commands via GCM

The C2 server first sends commands to the GCM server via HTTP or XMPP, then the GCM server pushes the command to the infected device.

In the above section we showed that the GCM Service Class Ewhtolr is used to communicate with the GCM server. Once it receives the command from GCM server, it calls the function cibuwlvohd in class Auepniow. The class Auepniow is used to handle commands delivered from the C2 server. These commands are also encrypted using AES.

The command list is shown below.

·     message_delivered: the message is delivered successfully to C2 server.

·     gcm_register_ok: gcm registration is successful.

·     add_msg_ok: add some new phones and msg to send SMS.

·     register_ok: update the http proxy list and patterns used to send SMS in local database.

·     imunity: update locker_immunity in local database.

·     UPDATE_PATTERNS: send the updated info including imei,country,operator,phone number,model etc to C2 server.

·     URL: update the c2 server and then send the device info to new C2 server.

·     STOP: stop the GCM service.

·     START: start the GCM service.

·     UNBLOCK: unblock the device.

·     MESSAGE: send the SMS message to custom phone.

·     RESTART: restart the GCM service.

·     PAGE: request a new page from url and send the response to C2 server.

·     CONTACTS: add new contact phones and send SMS test to them.

·     CHANGE_GCM_ID: change the new sender_id and register GCM with the new one.

·     LOCKER_UPDATE: try to get a message to locker.

·     LOCKER_BLOCK: launch the device admin lock.

·     LOCKER_UNBLOCK: release the device admin lock.

·     ALLCONTACTS: get all contacts numbers and send the contacts list to C2 server.

·     ALLMSG: get all SMS messages and send them to C2 server.

·     LOCKER: receive a new locker screen webpage and display an overlay on the device.

·     NEWMSG: add new message in SMS inbox.

·     ONLINE: send the current status of device to C2 server, it includes the status of admin,lock,imunity,network type.

·     UPDATE: update the new malware version or other malicious app and install it on the device.

·     CONTACTS_PRO: get valid contacts phone numbers and sent them to C2 server.

Its sophisticated design contains more than 20 commands. We chose the command “UPDATE” to perform further analysis.

The following is a key code snippet.

The definition of the class uijevngswhml is shown below.

We can see that the malware launches an http request to get an updated apk, and stores it in the /sdcard/Download folder. It then installs the apk on the device. The apk may be a new version of the malware or some other malicious application. We have been monitoring it.

C2 server and Proxy list

The malware does not hardcode the url of the C2 server in plain text. Instead, it uses AES to encrypt the C2 server’s url. The following is the key code related to the C2 server.

The unencrypted url is shown below.

hxxp://streamout.space

But the real C2 server is a subdomain of “streamout.space”. The following code is used to generate the real C2 server to communicate with.

It generates the dynamic sub-domain of “streamout.space”. The following is a partial list of the domains we found.

stkru[.]streamout[.]space

jfyds[.]streamout[.]space

dgywz[.]streamout[.]space

moazn[.]streamout[.]space

wjrxf[.]streamout[.]space

ykarbm[.]streamout[.]space

ucgeh[.]streamout[.]space

Meanwhile, we also found some proxy IPs hardcoded in the malware. The following is a code snippet.

The decrypted data is shown below.

["193.124.44.118:7777","194.58.100.175:7777","37.140.198.185:7777"]

The proxy list is also updated via the command “register_ok.” It appears that the malware does not use the proxy list to communicate with its C2 server, but it’s very possible for it to use it to communicate with a C2 server in a future variant. We will continue to monitor this malware family. The traffic is shown below.

The decrypted data in the http post request is shown below.

The decrypted data in the http response is shown below.

Local SQLite Database

The malware uses SQLite database to store some key information. The following code is used to create two tables in the database.

We exported the database file from the device and opened it with SQLite Expert Professional.

Figure 7. The database stored on the android device

We then used the decryption program in Appendix to decrypt these fields in the database, as shown below.

Traffic

The following shows other decrypted traffic.

The device receives the command “Message”, and sends an SMS message to specific phone numbers.

Solution

This sample is detected with Fortinet AntiVirus signature Android/Locker.FK!tr.

We have also reported the GCM IDs used by this malware to Google.

Conclusion

GCM is a useful service designed to push notifications to clients from legitimate software developers. It’s also a double-edged sword, since this malware demonstrates that attackers can also use it as part of their C2 infrastructure. The GCM service appears to be being abused by these Android malware authors as part of their C&C method. We will continue to monitor future activities from this malware family, along with other families using GCM.

Appendix

SHA256 Hash

286cbb181204e3c67151766d3c4d969c13ef10350c57ebd71e8bb02423d15609

The decryption program