Analyzing "Obad.a" a.k.a. "The most sophisticated Android Trojan"

Recently we came accross this blogpost from Kaspersky that introduces its readers to a new Android Backdoor Trojan as "The most sophisticated Android Trojan" with the name "Obad.a", so we got curious to see whether or not Joe Sandbox Mobile 1.0 would be able to handle the APK (MD5: E1064BFD836E4C895B569B2DE4700284). Besides obfuscated class/method names, heavy string encryption and heavy java reflection usage, the APK actually uses two relatively new exploits to make static and dynamic analysis more difficult for sandbox systems and human analysts.

A brief test has shown that no public sandbox system can handle the APK correctly. Errors range from "No threat detected", over "no malicious activity detected" to "No executable file". The reason probably being that none of the systems actually managed to run the APK in the first place. To be fair, our analysis system wasn't able to handle the APK without an engine update either.

The first exploit: Incomplete/corrupt AndroidManifest.xml

The AndroidManifest.xml provided by the APK is actually incomplete, but it uses some weaknesses in the Android OS manifest checking code that installs and runs an APK even if certain key attribute names are missing, although it should be rejected. Of course, this is a major hurdle for sandboxing systems that rely on extracting key information from the manifest (e.g. the activity name, etc.). Here is a small excerpt of the original, incomplete AndroidManifest.xml:

As we can see, some important attribute namespaces and names are missing, such as "android:name" for the uses-permission tag or the "minSdkVersion" field in the manifest tag. So, in order to be able to run the APK in our system we updated our engine to fixup the AndroidManifest.xml with a best-effort approach. This is an excerpt of the same manifest after fixup:

Using the fixup our engine was able to properly extract static information and install the APK at the correct target device API level.

The second exploit: Inserting data into the instruction stream

The next problem we had was decoding and recompiling the classes.dex file (a necessary step as part of API call instrumentation), as the APK was modified in such a way that a packed data switch was inserted into the instruction stream. This in turn caused the DalvikVM verifier to reject our APK upon loading a specific sample class. A typical error of this type is:

VFY: encountered data table in instruction stream
VFY: rejecting opcode 0x00 at 0x002a
VFY: rejected Lcom/android/system/admin/oCIlCll;.oCIlCll ([B)[B
Verifier rejected class Lcom/android/system/admin/oCIlCll;

This is a pretty neat exploit, as it uses a weakness in existing dedexer tools and thereby hinders repacking APKs for automatic analysis. In order to solve the problem, we had to update our preprocessor to move the packed data switch back to its proper location before recompiling the classes.dex file.

Dynamically analysing the APK

Before running the APK, we created two signatures that match on these two special APK characteristics (corrupt manifest and packed data switch exploit). After quickly implementing the signatures, we ran the APK with Joe Sandbox Mobile 1.0 and here are some of the results:

Corrupt Manifest Signature

Exploit Signature

Obfuscated Method Name Detection Signature (New!)

In no time flat we were able to find some interesting code locations with dynamic data and reproduce results found in the Kaspersky blogpost linked at the top. Check out some of our results:

Here we see the "decryptString" function call (instrumented by function signature generically) returning "su -c 'id'" and passing the string to Runtime.exec in an attempt to create a superuser shell. This really outlines the power of "Hybrid Code Analysis" (HCA) engine that we use in Joe Sandbox Mobile 1.0, which combines dynamic data with static code analysis (in this case, the disassembly of the function).

Checking internet connection:

"calling home" to androfox.com:

Building a JSON command with device specific data:

Internal DB structure used to save user data (the last 5 datasets are displayed by default).

Querying for device admin privileges:

All of the above information was extracted and discovered within minutes.

Conclusion

All in all, it is amazing to see how quickly we were able to find key behavior and code locations of the sample and got a very deep look into the samples functionality using the disassembly listings. The generic instrumentation engine decrypted a ton of strings and the reflective invoke translation made the real behavior quite visible. Of course, it is quite amazing to see how advanced and sophisticated malware is becoming on Android (like on Windows) and in our opinion this sample really shows that it requires specialists and advanced technology to tackle threats at this level. That all sandboxing systems on the market failed shows how advanced this sample really is using two relatively new exploits directly targeting automatic analysis systems. On the other hand though, it was great to see how powerful our engine is and that we were able to react very quickly to this new threat and update our engine. Using our new generic signatures we will be able to detect any variant of this malware in the future and will be looking out for the next generation.

• Obad.a, Joe Sandbox Mobile 1.0 Report