Posts Tagged ‘Android’

Our Android Malware Summary for the Year 2014

Monday, May 18th, 2015

In 2014 our Mobile-Sandbox analyzed over 100,000 Android applications that were submitted by mostly anonymous users, Anti-Virus-Companies and by our own. In the same time we updated our system several times with new features and we modified the backend and the analyzing extensions. These updates unfortunately resulted in some downtimes and a clean database and we are still working to get all the data back in the system and to get everything running again.

Most of these malicious applications had been downloaded from Third-Party markets, but we also found some malware families with samples that had originally been downloaded from Google-Play. When looking at the malicious and unwanted applications and the corresponding families, one can see the following distribution of malicious behavior:

Characteristics Share in 2014 Difference to 2013
Families that steal personal information 63,1 % + 2,7 %
Families with characteristics of a Botnet 27,3 % + 2,3 %
Families that steal location related data 11,1 % + 2,0 %
Online-Banking Trojans 10,0 % + 3,2 %
Families downloaded from the Google-Play Market 9,0 % - 0,1 %
Families that contain Root-Exploits 8,9 % -0,2 %
Families that send premium rated SMS messages 8,0 % - 10,2 %
Potentially unwanted applications 8,0 % - 1,1 %
Commercial Trojans or Spy-Kits 7,5 % + 5,2 %
Families that install additional applications 5,0 % -6,4 %
Families which are able to infect a connected Windows PC 0 % - 4,5 %

More than 63% of all malware families try to steal personal information from the smartphone like IMSI, IMEI and contact entries. Even if this action doesn't harm the smartphone user directly the information can be sold on the underground market or used for targeted Spam campaigns. This kind of threat has increased by nearly 3% as compared to 2013 and by more than 13% as compared to 2012. So it seems, that this kind of exfiltrated information is still very valuable.

2012 second most common threat -- sending premium rated SMS messages -- has lost nearly half of its share within newly discovered malware families in 2013 and was still shrinking in 2014. We assume that it has to do with the security features of Android 4.x as well as the awareness of telephony and service providers. But we have seen the first samples that are able to circumvent the security features of Android and are able to send premium rated SMS messages without notifying the user.

In 2013 some malware families appeared on the market that tried to infect a connected Windows PC through Windows exploits that had been bundled with the Android apk file. This hasn't been seen by us in 2014.

There was one newly discovered kind of malware in 2014: Ransomware. This kind of malware - also known as cryptolocker - is encrypting large amount of data on the device and then displaying a message telling the victim to pay a given amount to the attacker (often combined with some FBI warning) to get the encryption key. This kind of threat is well known to PC users and now also available on mobile phones.

In 2013 we have seen the first publicly known targeted attack where Android smartphones were involved as main entity in the attack, this was something we have seen in 2014 more often. It seems that attackers move to mobile phones as a first step of the targeted attack with increasing frequency.

Lazy Sunday Updates

Sunday, May 17th, 2015

After nealry a year I found some time today to update the mobile malware overviews for iOS and Android. I hope that I catched everything that came up in the meantime, if not, please let me know which malware family is missing in the overviews.

Here you can found the updated lists:

Android for Work: Demystified

Wednesday, March 11th, 2015

Android for Work has been announced by Google only some days ago and Google promises a secure but also usable way to combine sensitive company data and private data on a single device without increasing the risk of unintended leakage of company data.

"... Android for Work on supported Lollipop devices offers a dedicated Work Profile with security, management and application support built-in. ... Android for Work creates a secure Work Profile to isolate and protect data and manage the flow of work information. ..." (Android for Work website)

Today, we took a brief look at Android for Work to see how secure it really is and if it is a real alternative to the container solutions of AirWatch, MobileIron, Good, etc.

So we started setting up the whole solution within the Google Admin Console, which is much more work then it seems when you are reading the press releases. The following screenshot shows the requirements for a fully working Android for Work including apps that are able to process company data.

Android for Work Requirements

To fulfill these requirements we used a Google Nexus 5 with Android 5.0.2 and the Google Apps Device Policy app installed.

Setting up the policy for all your company devices is straight forward and in most cases self-explaining. You can even set expiry dates for device passwords and number of old passwords that are not allowed for reuse (similar to what companies often do with domain credentials). Furthermore, you can block Google Now and other services you don't want that your employees are using. You can even block compromised (rooted or infected) devices from syncing with your EMM. When looking to the rest of this post, maybe blocking itself is not enough and Google should also add something like "wipe device if compromised" or similar. In the following screenshots you can see some of the applied settings and the Google Apps Device Policy app.

Google Apps Device Policy app

Lets get to the positiv aspects of Android for Work before deep diving: The policy settings are reliable enforced and the UI is really separated if you configured it that way. Even the clipboard isn't shared and no transfer of "work data" to the "private part" of the smartphone is possible. So from a user perspective this is really looking nice and usable, but ...


As already mentioned blocking of compromised devices isn't enough if you have synced sensitive or even confidential documents (emails, Word or Excel files, etc.) to the device and want to protect these files from unauthorized access. To test this scenario we need such documents on the device. So we installed an office suite (WPS Office) and some other useful apps to the work environment of the Nexus 5 and created some documents as well as inserted contact data into the "contacts for work" app (as can be seen in the following screenshots).

work documents

After saving these documents we first tried to find them on the local storage by using a file manager app. But as mentioned before, the policy is working like it should and we couldn't find the documents or even the directories where these files should be located according to the work apps.

Afterwards, we tried to achieve the leakage of the "work files" from the managed device through the following attack:

  • flashing a custom recovery image,
  • using the same approach as formerly used by FROST to circumvent the FDE (by reading the key from memory), and
  • accessing the decrypted partitions with the help of adb.

This approach looks really promising, as the Android OS is not running and the EMM doesn't notice that we are attacking the device. After successfully connecting to the device we tried to access the directories where the sensitive documents should be located (at least according to the work apps): /storage/emulated/10/documents and /storage/emulated/10/Downloads

What we have seen so far was that /storage/emulated/0/... is the virtual sdcard, but we haven't seen an emulated/10 before....and we didn't find that location now. It seems that, although we now have root access, these files are still hidden. Due to the fact that we know how the files are named we used find to search for these files and checked if they are really hidden or just mounted to some other directory (the mount command doesn't show anything suspicious).

This approach showed us where to find the work documents: data/media/10/


When looking for the work contacts and the planned meetings we noticed that they aren't stored in the same directory. All databases and application folders of work apps can be found at: data/user/10/


At this point many thanks to Dave Smith who was giving us the hint, that the numbers here are the ids of the device users and that it therefore not has to be the id 10 for the work profile.

What puzzled us most, was that these files are neither encrypted nor protected by any other techniques than normal user-access-rights. Meaning that as soon as you are root, there is no protection or isolation of the work apps and its highly sensitive data.

For our attack you need physical access to the device, the bootloader has to be unlocked (not default on Nexus phones) and the device has to be running or at least the screenlock has to be a short PIN (for a fast attack on the FDE). But as soon as there is another exploit like towelroot that can be used without unlocking the bootloader or even bundled with an app, the same attack can be done by a remote attacker that tricks the user into installing a manipulated application.

MobileSandbox @ Springer IJIS

Sunday, August 3rd, 2014

Our MobileSandbox paper from SAC2013 got an update. It has been accepted as an journal article for the upcoming edition of the International Journal of Information Security.

Here is the abstract:

Mobile-Sandbox: combining static and dynamic analysis with machine-learning techniques

Smartphones in general and Android in particular are increasingly shifting into the focus of cyber criminals. For understanding the threat to security and privacy, it is important for security researchers to analyze malicious software written for these systems. The exploding number of Android malware calls for automation in the analysis. In this paper, we present Mobile-Sandbox, a system designed to automatically analyze Android applications in novel ways: First, it combines static and dynamic analysis, i.e., results of static analysis are used to guide dynamic analysis and extend coverage of executed code. Additionally, it uses specific techniques to log calls to native (i.e., “non-Java”) APIs, and last but not least it combines these results with machine-learning techniques to cluster the analyzed samples into benign and malicious ones. We evaluated the system on more than 69,000 applications from Asian third-party mobile markets and found that about 21 % of them actually use native calls in their code.

The whole paper can be found here.

Android RAM Analysis @ IMF2014

Saturday, May 17th, 2014

Our paper Post-Mortem Memory Analysis of Cold-Booted Android Devices has been accepted at IMF’14 and was presented there last week.

Here is the abstract:

As recently shown in 2013, Android-driven smartphones and tablet PCs are vulnerable to so-called cold boot attacks. With physical access to an Android device, forensic memory dumps can be acquired with tools like FROST that exploit the remanence effect of DRAM to read out what is left in memory after a short reboot. While FROST can in some configurations be deployed to break full disk encryption, encrypted user partitions are usually wiped during a cold boot attack, such that a post-mortem analysis of main memory remains the only source of digital evidence. Therefore, we provide an in-depth analysis of Android’s memory structures for system and application level memory. To leverage FROST in the digital investigation process of Android cases, we provide open-source Volatility plugins to support an automated analysis and extraction of selected Dalvik VM memory structures.

The full paper can be read here.