Android for Work: Demystified

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

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

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.

Our Android Malware Summary for the Year 2013

February 21st, 2014

In 2013 our Mobile-Sandbox analyzed over 150,000 Android applications that were submitted by mostly anonymous users, Anti-Virus-Companies and by our own. Within this huge amount of data our system detected a bunch of malicious and unwanted applications belonging to 44 different and newly discovered malware families.

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

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

More than 60% 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 more than 10% as compared to 2012.

Last year´s second most common threat -- sending premium rated SMS messages -- has lost nearly half of its share within newly discovered malware families. 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.

The most dangerous malicious samples are those that come with their own root exploit. If this exploit works properly, the attacker can do nearly everything with the infected device without the knowledge of the smartphone user. This kind of malicious behavior was found in more than 9 % of the 44 new malware families (which is also half as common as compared to 2012).

Within 2012 a huge amount of banks switched from the common TAN procedure to the mobile TAN (mTAN) for additional security. This trend can also be seen when looking at the malware families. In 2012 we detected 4 different families (3,5 %) that try to intercept and modify this mTAN messages. In 2013 it went up to 6,8 % of newly analyzed malware families. This kind of malicious Android apps are extremely dangerous: If the computer and the smartphone of an online banking user are infected with this kind of malware, the attacker can modify each transaction without the knowledge of the infected user.

There were two newly discovered kinds of malware in 2013: Commercial trojans/spy-kits (which are -- more or less -- legally sold on the Internet) and trojans that are able to infect a connected Windows PC. Both kinds of malware were distributed very seldomly with only 2 - 5 %.

With Android.Chuli we have also seen the first publicly known targeted attack where Android smartphones were involved as main entity in the attack.

ADEL goes open-source

March 2nd, 2013


Our forensic framework for smartphones running the Android OS is now open-source and available on GitHub.

The documentation and some other useful information regarding ADEL is available here.