Android malware creators throw up a roadblock to thwart the good guys

Emulation testbeds have been considered by security practitioners to be a useful tool to conduct operational security exercises and a variety of research. For almost as long, malware writers have sought to thwart such tools.

SophosLabs has come across some fresh examples of this – specifically, anti-emulation Android malware. The findings are in a Sophos Blog write up by Android specialists Chen Yu, William Lee, Jagadeesh Chandraiah and Ferenc László Nagy.

In it, they explain how Android malware is copying the anti-emulation techniques that have served Windows malware writers so well.

First, let’s look at what an emulator is. Most online definitions describe it as hardware or software that allows one computer (the host) to imitate another computer (the guest). It typically allows the host system to run software or use peripheral devices designed for the guest system. In security, it’s a handy way to test malware behavior or larger security operations readiness.

Anti-emulation techniques are found in many different Android malware families, one being the recent Android Adload adware found in Google Play.

Six techniques

SophosLabs researchers identified many anti-emulator techniques when they looked at such malware. The Sophos Blog post describes six of them in detail. Here’s a summary of each:

1. Checking telephony services information: Emulator detecting is all about spotting the difference between the environment that the emulator and real device provide. First, the deviceID, phone number, IMEI, and IMSI would be different on an emulator than on a real device. The Android.os.TelephonyManager class provides methods to get the information.
2. Checking the build info: Researchers found multiple malware families checking the build information on a system to determine if it’s running on an emulator.
3. Checking system properties: Some system properties on an emulator are different from those on real devices. For example, device brand, hardware and model. 
4. Checking for the presence of emulator-related files: In this case, the malware checks to see if QEMU (Quick Emulator) or other emulator-related files exist.
5. Checking the debugger and installer: This one is not an anti-emulator but its purpose is also to obstruct the dynamic analysis. Like the Skinner adware, it uses Debug.isDebuggerConnected() and Debug.waitingForDebugger() to check if a debugger exists.
6. Time bomb: This is another way many malware/adware families hide themselves from dynamic analysis. After installation, they await a certain time until they start their activities.

Defensive measures

Malicious code with anti-emulation features is just the latest example in what has been a surge in Android malware activity. The average Android user isn’t going to know what techniques the malware used to reach their device’s doorstep, but they can do much to keep it from getting in – especially when it comes to the apps they choose:

• Stick to Google Play. It isn’t perfect, but Google does put plenty of effort into preventing malware arriving in the first place, or purging it from the Play Store if it shows up. In contrast, many alternative markets are little more than a free-for-all where app creators can upload anything they want, and frequently do.
• Consider using an Android anti-virus. By blocking the install of malicious and unwanted apps, even if they come from Google Play, you can spare yourself lots of trouble.
• Avoid apps with a low reputation. If no one knows anything about a new app yet, don’t install it on a work phone, because your IT department won’t thank you if something goes wrong.
• Patch early, patch often. When buying a new phone model, check the vendor’s attitude to updates and the speed that patches arrive. Why not put “faster, more effective patching” on your list of desirable features, alongside or ahead of hardware advances such as “cooler camera” and “funkier screen”?