Ring! Ring! Mobile Malware calling
In the past, we've discussed the rise of mobile malware. More recently, Imperva’s ADC has analyzed mobile malware and our findings support the observation that we’ll see more Android malware than those targeted at Apple for two reasons:
- Technically, it is easier to write malware for Android.
- Currently, better channels exist to distribute for Android malware.
Google has bought Motorola (for the best market perspective on the acquisition, read Fabrizio’s take). Consolidation aside, mobile malware is on the rise. For instance, Juniper’s malicious Mobile Threat Threats Report found a 400% increase in Android malware since the summer of 2010. According to Paolo Passeri, the number of malware is growing exponentially, and has reached a huge peak in July. This trend is very important for the security industry. A recent Wall Street Journal headline captures the shifting landscape:
Microsoft Faces the Post-PC World
Now 25 Years Old, Windows Sales Slow as iPad Gains; Lowest Market Share in Two Decades—82%.
Security translation: make room PC malware, there’s a new player in town. The article also notes that in Q2’11, 43% of smartphones were sold with Android. We are already seeing issues: Dasient’s recent paper on mobile malware highlighted how applications consistently violate privacy, leaking consumer data to app makers. In their report, they note:
The history of mobile malware continues to be written. After a slow start, the pace of attack is accelerating, and it is possible that we should expect some "mobile malware madness" to occur in the near future, at the very least, if not longer.
What kind of malware can we expect?
The next generation mobile malware is going to be rootkits for mobile. Mobile malware is evolving similarly to how PC malware had evolved. While first-generation PC malware was not sophisticated, in time it achieved a variety of stealthy features: anti-detection, hidden deployment and forensics deletion capabilities. We should expect to see the same in the mobile realm where rootkits for mobile will be hidden from the victim and mobile system processes. In fact, a Proof of Concept was already released in last week’s Defcon. The researcher had shown that once the code was installed on an Android phone, the rootkit becomes activated via a phone call or a text message. Since the rootkit runs as a module in Android's Linux kernel, it has the highest level of access to the Android phone and can be a very powerful tool for attackers.
And hackers are taking note. We did an analysis of a hacker forum to determine the frequency that hackers discuss issues around mobile. A simple search over the past few years using iPhone, Android, Nokia and BlackBerry shows a fast-growing fascination:
Though our chart shows more iPhone discussions, we expect this to change.
In this series we’ll highlight how Android’s distribution model makes it easy to put malware on phones as well as take you through an analysis of a mobile malware. This malware first captures incoming SMS messages before any other system application. It then posts their contents to a drop server. What’s unique about this particular malware? The industry has been calling it ZitMo - the mobile equivalent to the notorious PC-based Zeus malware. To be clear, after analyzing this piece of code, the ADC cannot guarantee 100% that this is the Zitmo code, but it seems likely.
In this 4-part series, Imperva's Tomer Bitton presents an under the hood analysis of Android malware. This malicious mobile application is distributed via the Android’s application shop market. What does it do? The application captures incoming SMS messages before any other system application. It then posts their contents to a drop server.
Due to this interception behavior, security researchers have been calling it ZitMo – Zeus in the Mobile. But is this in fact the mobile equivalent of the notorious banking Trojan, ZeuS? As the analysis will show, we cannot guarantee the validity of the ZitMo claim due to the following reasons:
- The code is not sophisticated
- There is no configuration file
- There are no encryption methods
That being said, also the first PC-based ZeuS versions were not too sophisticated, behaving as generic keyloggers. Time will tell.
In the first part of this series, we presented some trends in mobile malware. In this entry, we decompile the application. Part 3 will analyze the application’s code. Finally, part 4 will provide the victim’s view once this malicious application is installed.
Trojan Introduction
The Trojan comes as an Android Application Package Package (.apk) file. The .apk file contains all of the application’s code, resources, assets, and manifest file (click to BIGGIFY):
Those familiar with the apk file format know that an .apk file can be opened and inspected using common archive tools (e.g. 7zip application).
Extracting the .apk file presents us with the list of the following files (click to BIGGIFY):
The interesting file for dissection is the classes.dex file. This is the file which contains the compiled code.
Decompiling the .dex file
In the last mobile malware analysis post, the Smali tool was used to disassemble the dex file. However, in this analysis we use a different method which requires the use of a different set of tools.
As dalvik is based on design of java, it is also susceptible to decompilation. As a first step, we will use the tool dex2jar which converts dex files to jar files. In the second step, a java decompiler, JD, will be used to allow us to view the abstracted code.
Step 1 – Using dex2jar:
Step 2 - JD tool:
What do these classes do? In part III of this series we’ll take a deep-dive into those classes.
In the last entry we demonstrated how to decompile the Trojan’s .dex file – the compiled Android application code file. Here, we show how the Trojan intercepts the messages and sends them to the drop point. In particular, we take a deep dive into these three decompiled classes:
- The Activation Class – Responsible for the UI window
- The Server Session Class – Responsible for sending the intercepted text messages to the drop box.
- The Main Class – Runs the application where the Trojan intercepts the incoming text messages.
Click here for the full report.
In part IV we will show how the infection looks like from the victim’s point of view
Please find below, the final posting in the series on mobile malware brought to you by Tomer Bitton, Independent Reverse Engineer at Imperva.
Please find below, the final posting in the series on mobile malware brought to you by Tomer Bitton, Independent Reverse Engineer at Imperva.
Part III shows the code which intercepts the SMS messages and sends them to the drop point.
As we have previously mentioned, the malware is distributed through the Android’s application market. It remains to address the following question: how does an infection look like from the point of view of the victim?
Dynamic Infection:
Rather than installing the Trojan on an Android, we had decided to install it on an Android SDK on an Ubuntu machine.
Click on the link below for some screenshots which emulate what the victim sees on their handset.