Preview on "Joe Sandbox Mobile"

Welcome to the Mobile Malware blogpost from Joe Security LLC. Here we will be posting some interesting discoveries regarding mobile malware threats with a focus on the Android operating system, as it is the most widespread mobile system for smartphones, mobile phones, netbook or tablets. More than 500 million devices running Android were registered last year in September with more than one million devices registering every day. That being said, it is evident that the number of threats through malware is on the rise as the market grows.

As some of you know, we are developing a new engine Joe Sandbox Mobile that will be able to execute malware and seamlessly integrate into the existing Joe Sandbox infrastructure. We are planning to release an initial version soon. To give you a brief idea of the engine's functionality, here is a list of key features:

• Dynamic and static analysis combined
• Interact with the running APK
• Cookbooks to interact with specific malware in a custom manner
• Additional backward compatibility to run APKs that are broken/incomplete (e.g. an APK trying to load a non-existant resource will not always crash in our environment)
• Anti-Tampering Detection features (certificate verification checks); more on that further down
• Anti-Emulator Detection features
• Highly configurable instrumentation engine
• Customizable python signatures

Before coming to the big picture, I'd like to drop a few lines about some cool features.

Joe Sandbox Mobile Anti-Tampering Detection

If one wants to analyze API calls during runtime, instrumentation is necessary. In the best case, the operating system remains untouched, as it will allow running malware even on native phones that do not need to be rooted to install a patched OS. The way dynamic analysis of APK files in Android works typically, is that the APK files are decompiled, analyzed statically and then repacked, ending up with a modified classes.dex file that will provide some activity logging data for further analysis at a later point. Of course, malware authors have realized that this is happening and implement checks to see if their APK has been tampered. Some of these techniques include checking the APKs file size, last modified date, checking the file signatures and more tricks. As we were interested in checking our own performance at hiding the instrumented APK, we digged into androids cracking world and checked out "anti-drm" techniques (check out AntiLVL here).

This is the result of Joe Sandbox Mobile (the Trivial Check1/2 are actually "using free/pay version" checks and not interesting for our anti-tampering detection, unlike the Package Manager checks listed at the top of the APK output screen):

These are the results of two well known sandboxing systems:

As we can see, our Anti-Tampering Detection is doing quite well.


Spoofing IMSI and Catching "FileNotFound" Exceptions in an Intelligent Manner

Checking out some random malware sample (MD5: f3497516eab17c642c5ede5ad1e55a15), which reads your IMSI and tries to keep track of your location. Normally, the APK would crash over a "FileNotFoundException", as the "home address" is unavailable. But, as our instrumentation engine can catch and react to thrown exceptions, we were able to not only suppress the failing "getInputStream" call, but return an input stream with random valid data. Thus, allowing the malware to execute even more payload than it would have otherwise. Again, the principle of triggering as much payload as possible applies, as live data will always give the analyst a better idea of the malware's behavior than pure static analysis. That's obviously a big difference compared to pure static analysis and an important tool for any forensic analysis.

Here's some sample log output to demonstrate what's happening "under the hood" (we even see the spoofed IMSI in the accessed URL):

<Package: cooshare.zeno.tinygame.lovetrap, Minimum SDK: 7, Target SDK: 7, Permissions: [android.permission.INTERNET, android.permission.ACCESS_NETWORK_STATE, android.permission.RECEIVE_SMS, android.permission.SEND_SMS, android.permission.READ_PHONE_STATE, android.permission.RECEIVE_BOOT_COMPLETED]><Main Activity: .welcome>
<f3497516eab17c642c5ede5ad1e55a15 is a valid APK file!>
<Converting APK f3497516eab17c642c5ede5ad1e55a15 to smali files ...>
<Parsing APK "f3497516eab17c642c5ede5ad1e55a15" (API Level = 7)>
<Instrumented 48 APIs successfully, skipped 0 APIs due to incompatibility.>
<Instrumentation took 26 milliseconds>
<Injecting handler code ...>
<Saving patched files ...>
<Generating new dex file ...>
<Creating new apk archive ...>
<Signing APK file "f3497516eab17c642c5ede5ad1e55a15.apk" ...>
<Zip-Aligning APK file "f3497516eab17c642c5ede5ad1e55a15.apk" ...>
<Verifying APK file "f3497516eab17c642c5ede5ad1e55a15.apk" ...>
<Successfully instrumented new APK file!>
<Installing APK file "f3497516eab17c642c5ede5ad1e55a15" on device "emulator-5554">
<Installation successful!>
<Logging activity for 30 seconds ...>
<Starting main activity "cooshare.zeno.tinygame.lovetrap/.welcome" on device "emulator-5554">
Spoofing IMSI: 310260000000000=000600000000100
Spoofing a fake inputStream
java.lang.reflect.InvocationTargetException
    at org.apache.(...)HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:1162)
    at cooshare.zeno.tinygame.lovetrap.welcome$3.run(welcome.java:137)
Caused by: java.io.FileNotFoundException: http://www.cooshare.com/careu/positionrecorder.asmx/getS3?imsi=000600000000100&appid=LOVT

And finally here is a little collage that we put together from our latest sample testing round to show you how colorful malware can be: