Android malware goes Mono (.NET) and Lua!

In December I attended a (really great!) Botconf 2014 conference. During that conferece I gave a lightning talk about an interesting Android malware sample that (presumably) used Lua and Mono (hence, .NET) as a way of obfuscation. Very recently @tbiehn Tweeted to me a solution for a problem that I run into during the analysis. So now, below, you can find details about the weird Lua/.NET/Java Android sample.

It says "Please wait, loading data"

Quick overview

It starts fairly innocent, with an app called Metrics.Me and it has a pretty standard malware permissions, as can be seen on a screenshot below. It uses a VKontakte icon, probably to pose as a kind of social media app. The main and only screen of this app is shown above.

Let's start with the usual place: the SMSReceiver. And now things get a little complicated. There are a lot of references to the "monodroid". It turns out that this is actually a Mono (.NET) implementation in Android. So, presumably, this is written in Mono. There are also some references to the Runtime.register native functions (shown below). How does it all work?

The register function accepts three parameters: first one is the string defining the DLL and .NET class which will be used to load the native functions. In this example Metrics is the DLL name and Z.Core.SMSReceiver is the class. Second parameter is the class to which this functions will be applied, in this case it's the same class, namely SMSReceiver. Last parameter is a string which defines a mapping between a .NET function and the native function declaration in the class.

And if you look at the sample, all of the classes in z.core package use this .NET class loading methods.

Mono and the mkbundle

So, first you need to register a method using the native-implemented Runtime class, which is a part of the Monodroid native library. In this way you can almost transparently use the .NET code in your Android app. However, if a DLL file on Android is still a little too transparent for you, you can go a little further with the obfuscation. Just use the mkbundle tool! It's a tool that combines all of the DLL files to a native .so library, e.g. for ARM processor. This is usually called libmonodroid_bundle_app.so and contains gziped DLLs (all of them) with their appropriate file names. You can see it by disoplaying the exports of the .so file, as pictured below.

As you can see there is a mono_mkbundle_init export and a couple of exports called assembly_data_ which are just gziped DLLs. So, you probably want to extract them. You don't have to do it manually now! You can use my script to extract all of the files, as I did. So now we have files and we can look at them and see what this malware does.

.NET code & Lua

For the .NET code I used a free dotPeek decompiler, which I cannot recommend enough. You can see the onReceive method below and experience the weird cognitive dissonance by reading a .NET code using Android libraries.

And when you dig a little deeper, you can find a very interesting sets of functions. Like for example the GetScriptFromServer function which does the following.

• Crafts a specific HTTP POST body content, which contains, among others, a token and MD5 checksum.
• Sends the request to hxxp://109.73.170.147/news/news.php (PHP - now we have even more programming languages!). Although the https is not used, the request body is encrypted using AES.
• Depending on the response code it either downloads or uploads a Lua (yes, Lua) script.
• The script above is then executed on the Lua interpreter implemented in the Mono environment on the Android platform. Just let it sink for a while.

Function is presented on the screenshot below. AES key and IV mentioned above are actually generated randomly and exchange on the first contact with the C&C server. This registration process goes like this:

• Bot sends a device ID included in it's registration packet to the server.
• C&C responds with the confirmation and includes a XOR key.
• Bot generates (randomly) AES key and IV and sends them (XORed) to the C&C server.
• C&C server acknowledges the key and IV. This parameters will be used in any future communication.

But the anti-reversing techniques go even deeper. Actually, the Broadcast Receiver source code was delivered by the server so there is no way to actually get to know the code once the server is down. Hence, I cannot really say what was done once the SMS was received. The same goes for the boot Receiver.

But wait, there's more. Have you ever heard about the Virtual File System? Of course you have! However, this VFS is just a simple interface that makes directories more available. Nothing really fancy there. However, it looks like it was just a placeholder and may be evolving in the next versions of this malware.

Summary

This app is one of the more sophisticated Android malicious apps on the market. Author went to great lengths to obfuscate the code and even used some anti-forensic measures. It has some unique capabilities (like the fact the the Broadcast Receiver code is actually kept on the server... in Lua). And you have to admit that running Lua on top of Mono on Android is pretty impressive.

After I typed this post I discovered a framework called Xamarin which lets developers write apps in C# for the three most common mobile platforms: Windows, Android and iOS. There are some artifacts named "Xamarin" in the sample, but the C# code looks like it was created for Android platform (the use of native Android functions and concepts, mix of the Java and C# code). If anyone is more familiar with Xamarin please have a look yourself to see if this is indeed a Xamarin app. Although I think this is highly unlikely. But if that turns out to be true maybe you can find a Windows or iOS version of this malware? Cross-platform would make it even more interesting.

And if you managed to read this post to the end, I have a little easter egg for you. Below is one of the package names in the sample.

Thanks, Obama