Android malware goes Mono and Lua - part 2 (Ransomware)

In my last post I described an interesting malware family that used Mono and Lua virtual machines to obfuscate its behavior. Lately, it has been packed with new features and upgrades, which are meant as a forensic countermeasure. Let's examine these updates and see why this botnet is different from the other Android botnets.

Retrospective: Lua and .NET

But first, let me remind you how this malware is build. Diagram below shows one of the malware main components - SMS Broadcast Receiver.

How does it work exactly? First, a BroadcastReceiver is registered in the AndroidManifest.xml file. This Broadcast Receiver, in its static initialization block, registers an n_OnReceive function  from a native library,, using a function call presented below.

This call specifies the .NET function call which will be used for n_OnReceive (Z.Core.SMSReceiver), library which will be loaded (Leader.dll) and some other parameters. The Leader.dll is then loaded from, which contains a bunch of gzipped DLLs written for Monodroid VM.

So, essentially Broadcast Receiver code is passed on from Java to Mono. But that's not all! This call is then passed to the Lua Script called "onSMS". This Lua script is run on the KopiLua VM. But this, and many other similar Lua scripts are not bundled with the APK. They are downloaded from the C&C and cached in a structure List<LuaScript>. They are not saved in the phone's file filesystem, instead they are downloaded each time the service (or phone) is restarted. This is different from the previous version which used Virtual File System to store Lua scripts.

You can see the Lua caching and calling mechanism in the screenshot below.

This approach - downloading Lua scripts from C&C - allows for a maximum flexibility and almost instantaneous change in attacker's goals. He can send Premium SMS or steal online banking OTP or do anything really, easier than when using standard RAT or backdoor.

Retrospective: network communication

This malware uses a special protocol over HTTP to communicate with the C&C server. In the Z.Core.Packets package (or whatever it's called in .NET) we can see several classes:

These classes are responsible for creation of the messages that are then sent to the C&C server as a body of POST request. Each packet has an ID (which maps to a command) and then some parameters, if the command requires it. Supported commands are:

  • 1 - registration with IMEI and two countries (both values hardcoded to "111")
  • 2 - bootstrap packet with AES key and IV, bot id
  • 3 - script packet with answer token, script content and md5 checksum
  • 4 - echo packet with token and text
  • 5 -  SMS received packets with message text and phone number
  • 6 - Contacts packet with a number of contacts and list of name and phone number pairs
  • 256 - get task packet with token
  • 12 - task done packet with token
  • 19 - set variable packet with variable name and value, used to set variables in Shared Preferences
  • 28 - version data packet with token and version data
What are tokens? Well, they are used to identify the bot.

What does the typical communication look like? First, you have to register. You do this by sending registration packet (id = 1). In response, you'll get a XOR key. You have to randomly generate AES key and IV and send them to C&C encrypted with this XOR key. Now, all the following communication will be encrypted using this random AES key saved in the Share Preferences like so:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<string name="id">8683</string>
<string name="token">516c9d8a-95f4-4552-b549-abb398ec1a7c</string>
<string name="registered">OKAY</string>
<string name="adm">trux</string>
<string name="aesIV">H2DIQX2WW7qgU0nOyhf/LqN0EZCXtBcr5roevejKSVo=</string>
<string name="aesKey">18f7cyFDKPn3pdxRQCpT61C0U7qK8BnUkc/FaFvW7DI=</string>
<string name="lckd">false</string>

As  you can see we have bot id, token, registration status, Device Administrator status, AES IV and key (base64 encoded) and locked (ransomware) status. This last parameter will be described below.

Attack scenario

Every sample pretended to be some kind of popular app, like Skype or Twitter. Current version, after accepting the Device Admin privileges, uninstalls its shortcut. Then, we are only left with service running in the background. This service displays, after some time, notification shown below.

For those of you, who don't speak Russian, this means "New Licence Agreement". When you click on it, this bogus licence agreement is shown:

If you scroll all the way down and click on "Accept" you are asked to provide your credit card details:

So I was hit with a simple social engineering attack. There are layouts prepared for other types of social engineering attacks designed for banking apps or Chrome browser, but I was unable to invoke them and since this relies heavily on the C&C communication it may be hard to analyze them.

However, as I mentioned before, we can imagine all sorts of attack with such a flexible architecture. What other attacks, you may ask. I'm glad to show them to you.

New features

Newest sample can also lock your phone and demand ransom to be paid by sending funds to a prepaid phone number. This is done by displaying to you the following, rather nice looking, information:

It says that because you viewed child pornography and bestiality you have to pay a fine of 500 rubles (~ 10 USD).

Technicalities are rather similar to other simple lockers: it periodically invokes the activity displaying the lock information and wants to irritate user so much that he will pay the fine. It's all implemented in the Mono code, snippet of which is shown below.

Another new "feature" is the fact that application has disabled logging mechanism, which makes it harder to analyze, but you can still enable this feature. If you can recompile .NET code. On Android.

And finally there is the casino. This malicious app goes to the casino website, presumably only to generate traffic and ad revenue. The code of the Activity that visits the website is shown below.


In conclusion, this is one of the most advanced Android botnets and it's really packed with different features and allows the attackers for the easier control of the phone than most other Android RATs. It also uses interesting code obfuscation techniques, which makes analyzing it a (fun) challenge!


Popular posts from this blog

Using World War II techniques to fight ransomware

KLM's "We'll keep you grounded" Programme