Analyzing "Android-Trojan/FakeInst": Plug & Play premium SMS fraud

    Introduction

    As may be known by now, Joe Security offers free services to analyze APKs and other files. We often check submitted files to see if we come across anything special. Today, we found an interesting sample (MD5 0123078fac53446ab5d9527b6da1ab14) that is a typical SMS fraud APK that sends premium SMS to a specific number. The software is labelled by AV as "Android-Trojan/FakeInst" (and similar), albeit it actually does implement a working installing mechanism and has some kind of "License Agreement" term that outlines the SMS costs. Nevertheless, what is interesting about it is the way it works, as it seems to implement a "Plug & Play" mechanism that makes it very easy for anyone really to take affect of the dubious functionality and "turn over" the APK to implement their own premium SMS "registration service". ;-) What we will learn in this blogpost is how easy it is to understand the sample in only a couple of minutes using the comprehensive Joe Sandbox report. Let us take a look at what information we can extract using the report alone and then get down to the configuration mechanisms.

    Getting an overview

    The first thing we always do when we look at a sample is take a look at the signatures and static information to get a quick idea of what the APK might be up to. Here is the matched signatures and permissions overview at the top of the report:


    As we can see in the signature overview, the APK does a couple of suspicious things. Most APKs that combine these behavior signatures are usually malicious:

    • Connects to the internet (posts data, downloads data)
    • Executes code after phone reboot
    • Sends SMS
    • Obfuscated method names/uses reflection
    Often malware comes with a lot more "bad stuff", in this case it is bad enough and looking at the signatures alone gives us a good idea of what this might be doing (e.g. potentially leaking sensitive data, sending premium SMS, trying to hide behavior). Taking a look at the static information overview:


    As highlighted, we have some typical patterns: the APK is "play store compatible", that means it is meant to be spread as much as possible, it is signed by a valid certificate from Russia (suits the cyrillic) and it requires some unusual permissions (like the "MOCK_LOCATION" permission).

    Next, we take a look at the network traffic, if there is anything generated. Here we go:


    Taking a look at the dependency graph and the first HTTP packets, we quickly understand that it tried to download something from "trashbox.ru", a legitimate russian file host/news site actually. On a side-note: we took a look at the downloaded APK and it is the "play store" app certificate-signed by Google actually. Obviously noone wants to pay money for something that you can have for free and that is pre-installed on Android to begin with (maybe that is where the "Fake Installer" name comes from). ;-)

    Getting into the nitty-gritty

    Everything we got to learn about the APK so far we might have been able to extract from competing sandbox systems, but let's take a deeper look now. Before we dive into the disassembly, let us see what our "automatic button interaction" engine clicked and check out some more screenshots.


    As we see at the top, Joe Sandbox Mobile did quite a few clicks on the buttons and managed to forward the "installation process" of the APK that way. Also, we can see that the APK created a "lasttime" file in a ".pay" directory on our SD card (which is downloadable as part of the full report in Joe Sandbox Mobile). That the "button clicking" did actually work we can see on the following screenshots:


    After clicking the "далее" (Continue) button (see first screenshot in the Introduction section).


    The final screen of the analysis. Google translates it as "Thank you for using our services. Now you will receive a SMS-message with a password to the private site. By clicking on the link you will be able to download the file.". The two buttons скачать and выход read "Download" and "Output". As we will see, the paid app was already downloaded and it is the playstore APK. Possibly an SMS really is received later on in the process, but unfortunately our analysis system does not really send SMS (or receive SMS) over a mobile carrier, so we could not follow this pathway. Nevertheless, a costly SMS was sent already.

    Now let us take a look at some interesting functions that outline the configuration.


    The above function reads the ".dat" files (you can find them in the APK under the "assets" folder), which basically resemble a variety of "configuration files" that determine the way the installer behaves. The most important asset files are:

    • link.dat: Contains the URL in cleartext of which the APK is downloaded, in this case hxxp://trashbox.ru/files2/74704_96f1f8/googleplaymarket_3.8.17.apk
    • data.res: Contains the "parameter data" for the "pay process". It is UTF-8 Base64 encoded.
    • command.dat, title.dat, etc.: Contain "Label Texts" that are printed on the buttons.
     

    Here we see the "data.res" file contents being "decoded" into the parameter data "SMSNum-1: 2011SMSText-1: PM04333000276". Essentially, it is a "framework" that can be used to generate premium SMS apps for different countries in slightly different fashions. Of course, the download APK could also be malware and does not need to be something legitimate as in this case.

    Now let us take a look at how the configuration is loaded and executed:


    As we can see at the top, a "JSON"-String is actually used to execute functions with parameters as defined in data.res. In this case the "pay process" is obfuscated as the following JSON command:

    {\"c0\":\"android.telephony.SmsManager\",\"m0\":\"getDefault\",\"m1\":\"sendTextMessage\",\"p0\":\"java.lang.String\",\"p1\":\"android.app.PendingIntent\"}

    Obviously, an entire program code could be encapsulated in this format. The cX variables indicate class lookup instructions, the mX variables indicate associated method lookup instructions and the pX variables indicate the parameter types for the lookups. The lookup happens purely using java reflection API. Luckily for us, we resolve reflective invokes automatically with Joe Sandbox Mobile, so that we can follow this tricky process quite easily.


    In the screenshot above we see the call to "getDefault" of "android.telephony.SmsManager", which returns a SmsManager object that is later used to send the text message (as indicated by the JSON command). A few lines further down we see what we were looking for:


    As we can see, an alleged premium SMS "PM04333000276" is sent to the phone number "2011". Finally, a "lasttime" file with the device timestamp is created under /mnt/sdcard/.pay/lasttime, which we again see quite nicely in the enriched disassembly listing.

    Conclusion

    What we basically learned in this blogpost is the Hybrid Code Analysis (HCA) technology implemented in Joe Sandbox Mobile that combines dynamic and static analysis is a fundamental key to understanding any kind of software and its mechanisms. Today, it is by far not enough to analyze malware purely statically (see the previous blogposts dealing with heavy obfuscation), nor is it enough to analyze malware purely dynamically. We can only understand targeted threats and malicious behavior if we get down into the "nitty gritty" and take a deep look at the inner workings. Of course, we do not want to spend a huge amount of time to analyze anything "by hand", which is why we need comprehensive reports and a fully automated system that takes care of the tedious work. As shown in this blogpost, we were able to fully understand the sample in just 15 minutes. Also, we learned that it is possible to dynamically execute code using the java reflection API. Understanding these threats requires a fine-grained instrumentation as implemented by Joe Sandbox Mobile.