Archive for March, 2012

Detailed Analysis of Android.FakeToken

Friday, March 16th, 2012

Intro: What is Android.FakeToken?

This new malware-family emerged some days ago within a spanish Spam-campain and spreads through email and SMS messages. This new Android malware tries to forward mTAN SMS messages to a remote user and thus has the typical man-in-the-middle functionality, we have already seen in malware families like Zeus and SpyEye, but it also can be controlled remotely and doesn't need to infect the user’s PC.

Analysis of the Application and Its Structure

When installing the app it requests the following permissions:

  • android.permission.READ_PHONE_STATE
  • android.permission.ACCESS_NETWORK_STATE
  • android.permission.SEND_SMS
  • android.permission.RECEIVE_SMS
  • android.permission.INTERNET
  • android.permission.WRITE_EXTERNAL_STORAGE
  • android.permission.INSTALL_PACKAGES
  • android.permission.DELETE_PACKAGES
  • android.permission.READ_CONTACTS
  • android.permission.RECEIVE_BOOT_COMPLETED

After the application has been installed successfully, the icon of the app shows up in the dashboard and the application registers some receivers which will trigger when a specific system event occurs (for example: BOOT_COMPLETED, USER_PRESENT, PHONE_STATE or SMS_RECEIVED). When the user executes the app, it shows a WebView component that displays an html-page which looks like a Token-Generator and it appears to be from the targeted bank (in our case it should look like the Santander Consumer Bank):

To get the fake token (just a random number), the user must enter the first factor of authentication. As soon as this step is done, the application sends a SMS message to the author and starts a background service afterwards:

This background service is listening to commands from the remote server (e.g. update of configuration) and starts periodically. When the smartphone of the victim receives a SMS message, the broadcast will be aborted and the message will be forwarded to a given phone number or remote server.

The application sends IMEI, IMSI, phone type, version, sid, phone number and the SMS body within a HTTP Post to one of the corresponding remote servers. These servers and all necessary information are stored in a xml configuration (/data/data/token.generator/files/settings):

This file can be updated remotely (via SMS and HTTP GET) if the phone number or server address of the malware author changes. The malware also has the ability to install further apk-files and sends the phone numbers of all entries in the address book of the victim to a remote server. The last step happens probably for further distribution of the malware.

Sample Information:



Mobile-Sandbox Report

Is Data Retention Still Necessary in the Age of Smartphones?

Thursday, March 15th, 2012

It is well known that smartphone operating systems persistently store location information in their local storage for various reasons. However, less well known is probably the fact that also various applications do this, too. In this article we will give you some hints where you can find this data on Android smartphones as well as we will present a system with which all this information can be extracted and visualized at the same time. We will also provide you with a comparison of the quality and quantity of location data gathered through data retention in contrast to the data gathered by forensic acquisition.

Our whole article can be read here.

Detailed Analysis of Android.Moghava

Friday, March 2nd, 2012

Intro: What is Android.Moghava?

This new malware-family emerged some days ago in third-party Iranian Android-Markets. It is one of the very few samples out there that is not intended to make money. Instead, the app represents another sample from the side of politically-motivated hacking (hacktivism) which modifies images that are stored on the device.

Even if this malicious app doesn't cause any financial loss to the user of the smartphone, all the pictures on the smartphone are compromised.

Unfortunately, the sample which was submitted to our mobile-sandbox is not signed, so we couldn't run it in our emulator and the rest of this analysis is made by looking directly in the decompiled code of the application.

Analysis of the Application and Its Structure

When installing the app it is requests the following permissions:

  • android.permission.WRITE_EXTERNAL_STORAGE
  • android.permission.RECEIVE_BOOT_COMPLETED

The application consist of two packages:

  • the benign part of the app: ir.sharif.iranianfoods
  • and the malicious part: com.Moghava

As it is very obvious that this is another repackaged app, we concentrated our analysis on the second package which has two classes, we will look at in the next sections.


This class is called when the smartphone receives a "boot completed" and calls the second class of the malicious package (see the code snippet below).


This class is responsible for the malicious action of the application. First it tries to receive a list with every picture of your phone. This action runs in the background in regular intervals.

The application is only checking the /sdcard/DCIM/Camera/ folder, so on newer smartphones like the Samsung Galaxy S2 it isn't getting all of your photos. On these smartphones the photos are often stored in /sdcard/external_sd/DCIM/Camera/.

After the application has received the list with all pictures inside this directory, it tries to modify them by merging the picture with a picture of Ayatollah Khomeini. Since the app isn't checking if the picture is already compromised it does this action over and over again till the storage becomes full.

Sample Information:



Mobile-Sandbox Report