Dissecting a mobile malware

Pierluigi Paganini January 28, 2013

The capillary diffusion of mobile devices, the lack of security systems on these platforms and low level of awareness on principal cyber threats made them a privileged target for cybercrime. We have assisted in the recent year to an explosion of malware designed to hit principal mobile OSs, in a recent report Sophos security firm revealed that in Australia and the U.S. Android threat exposure rates exceeding those of PCs showing the urgency to implement proper countermeasures. The situation appears really critical that why I asked to the expert of Group-IB Forensics Lab to show me how these agents work with a really case study.

AndroidRate

Several month ago Group-IB Forensics Lab detected mobile-banking malware through Google Play by Sberbank request (Russian leading national bank). The File associated to the malware was named «sber.apk», it was an Android Package having size of 225,905 bytes and digest md5: F27D43DFEEDFFAC2EC7E4A069B3C9516).

Analyzing the functionalities of the agent is is possible to classify it as «SMSStealer.APK» designed to infect Android devices.

The first step is the decompression of the archive and subsequent conversion of the file with the name «classes.dex» from format «dex» to file format «Jar», subsequently using «Java Decompiler» it is possible to convert files.

ConvertedFiles

 

Evidence files after installation displays the following graphical user interface used to request user’s authorization through a phone number verification process.

 MalwareUI

After entering the phone number and pressing the «Do authorization» the application send system information to a remote server URL «http:// berstaska.com/m/fo125kepro ».

The data sent contains mobile phone number, the name and version of the operating system on a mobile phone, the name of the service provider, mobile country code and many others.

At this point the research was addressed to the malicious domain used to collect the info, “berstaska.com” and “lekerdeka.com” are known to security experts because they have been used in the past for placing Carberp malware.

The data related to the domains are:

Domain Name: BERSTASKA.COM 
Registrant: N/A
merab mekokayan        ([email protected])
sk 8  box18 NY ,334777 US
Tel. +1.3049583484
Creation Date: 26-Oct-2012
Expiration Date: 26-Oct-2013
Domain servers in listed order:
dc1.nserver.ru
dc2.nserver.ru
 
Domain Name: LEKERDEKA.COM
Registrant: N/A
Sergey Bezumov        ([email protected])
PU BOX 81 l 92 NY ,325236 US
Tel. +1.33873847374
Creation Date: 26-Oct-2012
Expiration Date: 26-Oct-2013
Domain servers in listed order:
dc1.nserver.ru
dc2.nserver.ru

 

Both domain names were linked to nserver.ru NS-servers and registered anonymously, according to the MalwareURL database and Group-IB Bot-Trek™ product more than twenty Carberp C&C were linked through the DNS of this operator.

 Carpben

At the time of the study network address «berstaska.com» was unavailable.

 code1

The malware establishes the function for sending and receiving SMS-messages using the following event handler:

handler

Received messages are processed and stored in the appropriate format in a file called «messages.txt» and can be sent to the above remote server. In this program makes logging investigated their actions in a file called «alarms.txt».

CodeAlarm

The scam schema based on the interception of SMS used in the authentication process could be very useful to banking frauds. US and Canada banks, but also other financial institutions,  use One Time Password token sent via SMS, clearly an attacker intercepting it could complete fraudulent transactions.

Many security firms such as Group-IB have observed that hackers begin to trade such kind of tools on blackmarket customized for specific banks.

Group-IB has developed unique solution for proactive prevention fraud without integration specific hardware or software to the banking server-side so called Botnets Intelligence.

Group-IB Botnets Intelligence team does sinkholing of botnet to collect the data from them, information that the expert provide to the bank for blocking the banking accounts victims of frauds notifying to the customer the incident.

Following some questions I made to the experts of Group-IB Lab

What information exactly sent by the app to the remote server?

“system information, containing a mobile phone number, the name of the operating system on a mobile phone, the name of the service provider, mobile country code, etc”

Is the phone identifier sent? Android version number? any personal data? any information about other apps already installed on the device?

Information about IMEI, Android version, mobile service provider and extracted cellphone number from SIM-card for identifying the victims.

How often is messages.txt sent to the remote server? Is the messages.txt file created as soon as a SMS arrives, and then sent to the server? Or does the messages.txt created a file with multiple messages, and then send it at a specified time?

It sends intercepted SMS as soon as it was intercepted by the trojan or it would be impossible to use such technique efficiently for banking theft, as you need to know the intercepted SMS and to login to the victims banking account. If you do it late, you need to wait for other chance.

Is the Trojan intercepting all SMS messages, or just bank-related?

Only bank related by special signatures from Sberbank (russian national bank) and Alfabank (http://alfabank.ru) – one of the largest and leading private bank in Russian Federation.

I am not clear from the code snippet what is inside alarms.txt. Is it just logging when SMS are received and when messages.txt is transferred?

Yes, you are right, it is special files for information exchange about the new SMS was got and you don’t need to send it once again to the hacker.

How different is this from what Zeus-in-the-mobile does?

It doesn’t do any active actions with online-banking, as some of mobile banking trojans do. It only intercepts the information from SMS to do future theft from the remote computer of the hacker.

Did the two banking apps (for the different banks) all use the same remote server?

No, the same server was used to 2 banks, as it seems to be that it was targeted attack on them, and the same team of hackers were interested in both of them.

Let me conclude the article thanks the experts of Group-IB Forensics Lab and in particular to the Head of International projects Andrey Komarov.

Pierluigi Paganini



you might also like

leave a comment