Hangout’s SMS integration – applying breaks on the SMS stealers

December 31, 2013

Not long ago, Google has updated the Hangout android app to provide ability to handle incoming and outgoing SMS, providing SMS integration.

While, it is seen as an additional usability feature, I could see it also serves as an additional road block for the android malware (financial) and spyware which are interested in either intercepting or interrupting incoming SMS (recall AndroidOS/Zitmo, AndroidOS/Spitmo, etc.,)

Typical workflow of malicious SMS interceptor/interrupter which is used to defeat the two factor authentication (One Time Password)


It could be seen from the above schematic diagram that the Android malware running in the mobile completely depends on its ability to intercept and interrupt the incoming SMS and forward that to the malicious third party. This is typically done by registering a listener for SMS Broadcast Receiver and calling abortBroadcast() to ensure that the OTP is not delivered to the victim’s inbox.

This is where the recent update to hangout’s SMS integration proves handy. Hangout registers an incoming SMS receiver with highest possible priority and ensures that all the incoming messages are tapped by it. This creates a significant roadblock to the typical operation principle of such Malware that needs the ability to tap the incoming SMS.

On a different pitch, the normal OTP (One Time Password) can be further enhanced and better placed in the multi factor authentication scheme to bolster the overall security. We will see that more on the subsequent posts.

Hope you have enjoyed reading this post. Let me know your thoughts!


Analysis of recent android malware discovered in the app store

February 12, 2013

Earlier last week, a new piece of malware was discovered by the Kaspersky lab researchers in the official Android market. This malware was named as “AndroidOS.Ssucl.A”. This new family of the mobile malware employs a new attack vector through which it can not only infect the smart phones but also spread a malicious backdoor Trojan to the Windows workstations that the infected smart phone gets connected through a USB cable.
In this blog post, I will discuss on how this Malware accomplishes its tasks

What does it do?

The malware uses the time-proven strategy of social engineering as the vector to sneak into the victim device. It claims itself as a handy utility application which is supposed to improve the performance of the Android smart phones by “clean-up” of the device.

If an unsuspecting user chooses to download and install this malware, it prompts for a series of permissions to be authorized by the user during its installation. Once the “app” successfully installs, it registers a background service that will be started every time the device boots up.

The malicious service is responsible for opening a backdoor with the Command & Control server. Through this backdoor channel, the attacker can issue 20 commands which are currently supported by this piece of malware among those most of the commands will result in significant issues for the victim. We will discuss more about the functionalities of these commands in the next section.

How does it do?

The malware app registers a broadcast receiver to get notified every time the device boots up. Fig.1 shows the snippet of the manifest where the receiver is registered.


Fig.1: The BroadcastReceiver

This receiver is responsible for starting the malicious background service every time the device boots up.

Starting the malicious service

Starting the malicious service

The malicious service opens a backdoor and handshakes with the Command & Control server’s port number 9999 and starts a worker thread that waits for the attack commands from the attacker. Fig-3 illustrates the infinite loop and determines what command to execute based on the communication received from Command&Control server.

Code snippet interpreting the commands from the attacker

Code snippet interpreting the commands from the attacker

Currently, the malware supports 20 commands as shown in the fig.4.

List of 20 commands supported by the malware

List of 20 commands supported by the malware

The definition of what each command is supposed to do is implemented in the “Tools” component. If the attacker sends a message “SMS <destination_number> <message>”, the sample will send SMS to the destination_number specified with the <message>. Similarly GET_PICS command will traverse the pictures in the victim device  and upload them to the remote website.

Fig.5 shows the code snippet of the implementation of the attack commands.

command implementation

command implementation


One of those 20 commands called “USB Autorun_attack” introduce a new attack vector to the mobile malware that provides the capability to infect the windows workstation when connected through a USB cable and used in “mass-storage” mode. Even though the attack vector is less sophisticated and old, it got the lime-light because its first of its kind for an Android malware to be equipped with this.

Fig-6. Shows the snippet of the command implementation code of how this command “USB Autorun_attack” will be interpreted by the malware.

USB autorun

USB autorun

Common design aspects across the variants:

Among the few variants found in this family, it is noticed that the UI Patterns are common across all of them along with the common functionalities.


It employs “List Menu” as its primary navigation pattern ( a variant of Springboard pattern) across the variants.


Google has controlled the malware activity in the official store consistently over the period of time. However once in a while such incidents happen. It is general advise for the users to only use official market for staying safe. However in this case, the users must also get awareness about such incidents and should do a careful review of other aspects of the applications such as the developer profile, review comments, etc., Even though this would be a tough ask for a normal user, with the increased monetization associated with online fraud, it is important for the user to get good infosec awareness along with having a solid security suite to protect their device.

An architect’s day out with Reverse Code Engineering

January 3, 2013

Technically speaking; RCE, Malware analysis and architecting are orthogonal processes.

However over a period of time, I somehow started to see a lot of areas of Malware analysis where an Architect can contribute significantly towards improving the reverse engineering process. After all, reverse engineering is the process of reversing what an architect does. Isn’t it?

Let me take few scenarios. First one is a compelling case-study of Mobile Malware analysis and application of architects’ design principle investigation.


In this scenario, let’s talk about Mobile reverse engineering process. In the recent times, malware targeting mobile platform have gained significant media glare for the sensitivity associated with it. As it is the case with desktop threats, Mobile security researchers also have lots of frameworks/tools/scripts to process the bulk samples and similar variants of the same family.

Along with these existing tools and their metrics, what would also be a significant addition is the design principles employed in the mobile “app” under investigation.

Let’s consider adding a classification metric to the traditional classification with classification data extracted by analyzing the design patterns used in these mobile “apps”. For example a specific variant of the mobile malware family is designed with

  • 1st time through” Invitational design pattern &

  • Springboard” as its primary navigation pattern &

  • Expanding list” as its secondary navigation pattern &

  • Multi-step” pattern for data entry

Now, it can be easily observed on a huge data set that all the variants of this family has the same design patterns applied to them!


We all know that malware coded in Java is not new and there are millions (if not billion) of malware found in the wild which are written in Java and the number keeps growing. Security researchers have common automation utilities and frameworks to identify the similarities among the variants of same malware family, understanding relationships between different code constructs, decompiling the samples, etc.,

Along with the similarity metrics and identified binary patterns among these samples, there can be one more useful data point which would be common in most of the variants. And to see that metric, we need to put on our architect’s glasses and see through it.

Let us start with one of the several architectural viewpoints which can be used to create such metrics.

How about tracking these variants based on the relationship of their components (classes)! This needs processing a considerable set of malware samples and create a table of data and plot them based on the “is-a”, “has-a” and “uses-a” relationship and see how useful that would be.

Example: Sample A has three components where Component-1 “is-a” Applet and it “has-a” instance of Component-2 which “uses-a” instance of Component-3 which “is-a” serializable implementation.

Since, the exact names of these components are generally polymorphic; it may not be worth to plot these data using the names instead by numbered Components. The components number can be maintained with reference of other code metrics such as Cyclomatic complexity, member counts, etc.,

Hope, I have written this post in a manner such that the concept is made clear. Feel free to comment/share your views on this!

Happy reading!

An analyst perspective of the latest defense against the SMS Trojans in Android 4.2

November 18, 2012

I have updated this blog with the insights gained after walking through the source code of how this feature has been implemented.

The latest version of Google’s Android comes with many flashy features. Among them, the feature that has yielded immediate attention was “alert on SMS to premium numbers”.

This is really a very impressive move by the Big-G.  Let us first see, how this new feature can be a very good second line defense against typical Sms Trojans.

Well, the bottomline of this new feature is simple. Even though an application has sought permission from the user  to send SMS during its installation, if it tries to send a SMS to a premium number (to a short code), the user will be prompted with an alert that the appliction is trying to send sms to a premium number and whether the user would like to allow it.

See this behavior in action in fig.1

Alert prompt on SMS to premium numbers

fig.1:Alert prompt on SMS to premium numbers

This is indeed a very good way of handling the existing problem. However, the logic of prompting this alert needs more analysis.

The prompt gets triggered based on a regular expression based pattern matcher. The pattern matcher varies based on the country in which the SIM card is registered. For example, if the victim device has a sim card registered in US, this functionality will only  get enforced if  the destination mobile shortcode number’s length is five digits and compliant with the regular expression designed to identify the US short codes.  This is really a great approach as it strikes perfect balance between usability and security.

Currently, there are only few country specific pattern matchers implemented, especially for those regions where most number of mobile threat incidents reported.

Second, this feature is available in the recent version where as most of the active devices will not get this luxury  unless they choose to get it through a third party app.


Revamping mobile security blog activity

November 18, 2012

Fellow researchers and sec enthusiasts,

After a short self-imposed exile from blogging, I would be blogging from now onwards on this personal blogroll as an independent mobile security researcher.

Hope I continue to write interesting, technically intensive blogs useful for mobile community!

Happy reading!

With Regards,
Dinesh Venkatesan

Analyzing Process hollowing with a look into Thread Context structure

May 19, 2011

In the previous blog, We have seen how we can use Procexplorer to analyze hollow processes.

In this blog, we shall extend the analysis and see how the Thread context registers actually gets manipulated before resuming the thread.

1. The first step, the victim process gets created in “Suspended mode”. Please note the flag CREATE_SUSPENDED.

Create Process with Suspended mode

Create Process with Suspended mode

In this case, the victim is C:\windows\system32\notepad.exe.
Once, the process is started in suspended mode, a call ZwUnmapviewsection is made to make the memory available.

The snapshot shows the hollowed out memory.

Hollowed out process memory

Hollowed out process memory

Then the hollowed process memory is written with the PE header and the PE sections of the replacement process.

After call to "WriteProcessMemory"

After call to "WriteProcessMemory"

Then a call to GetThreadContext returns the Thread CONTEXT data structure. The snapshot below shows the ThreadContext structure dump before manipulation. You can see that it’s EAX register contains the Entrypoint of notepad.exe



Now, the EAX register value in the Context register is manipulated to contain the Entrypoint of the winmine.exe (replacement process)



Once, it is done, the suspended thread is resumed with a call to Resume Thread.

Hope you have enjoyed the read. Cheers 🙂

Analyzing hollow process using Sysinternals Process explorer

May 18, 2011

Before moving to the analysis, thanks to Michael and his team for their great work and codereversing blog admin for posting a follow up blog on process hollowing.

In this blog, I am going to discuss how I used sysinternals process explorer to analyze the process hollowing trick.

First the sample is started with two arguments (1) the victim process (2) the process that will replace the victim

Hollowing the notepad.exe and replacing with winmine.exe

Hollowing the notepad.exe and replacing with winmine.exe

Since, the PEB is not touched, the process explorer still shows the path and name of the process as C:\windows\system32\ and notepad.exe

Now, to confirm we can use sysinternals strings tab and check the strings at image and at memory. The following snaps illustrate it.

Strings from Memory image

Strings from Memory image

strings from disk image

Now that shows the obvious difference. To be more precise, here is the diff.

snapshot of diff between strings

snapshot of diff between strings

Hope you have enjoyed the read. Cheers 🙂

Android Zsone malware analysis

May 15, 2011

Earlier lastweek, it is found that a pack of malicious applications were taken down shortly after being identified for maliciousness. In this blogpost, I am presenting a quick analysis and payload of the sample.

There is nothing fancy about the payload. It is a typical SMSer Trojan. However the interesting point is the Trojan is very cautious in not alerting the user with a flood of SMS. It creates a bookkeeping information file (a XML file) to keep track of the subscriptions.

Tracing the sample’s SMS sender module:

SMS sender module

SMS sender module

A look at the memory footprint:

memory footprint

memory footprint

As mentioned, the Trojan checks that the user is not already victimised before sending the SMS. It does it by maintaining the state information in an XML file.

You can see that the iBookT.xml is the file that has the information about the victim. Here is the snapshot of the content of the XML file.

The value “Y” stands for already infected. This value is checked before sending the SMS. The next snapshot shows the code that does this logical checking.

The code snippet that implements the logic:

Hope you have enjoyed the read. Cheers 🙂

Android SMS Flooder app analysis

April 21, 2011

I just received a sample from a friend of mine to have a quick look at it. This sample is being detected by few AV vendors.

What does it do?

The sample is a very transparent application. It does not have any hidden agenda.It clearly mentions what it does. It floods a destination with a given message by sending ‘N’ number of message to the same number.

Installed in emulator

Installed in emulator

Invoking the application, provides a friendly interface to flood the messages.

Interface to flood SMS

Interface to flood SMS

As mentioned, it is very transparent and it gives a clear Warning message before startring the SMS flooding.

Warning message

Warning message

Cheers 🙂

Reverse engineering AndroidOS/Walkinwat Trojan

April 5, 2011

Earlier last week, Symantec has discovered a Trojan targetting Android platform that was supposedly designed to tackle pirated app users a hard lesson. The dynamic analysis of this Trojan is not very much interesting as we have seen many Trojans that sends SMS. This article focuses on highlighting code level details of the payload of the Trojan.

A look at the Manifest file:

The manifest file looks very familiar. Two interesting point to lookout is the permission to send SMS and permission to read Contacts at line no: 22 and 23 respectively.



Fig.1: Manifest file highlighting the permission to send SMS and read contacts.

The LicenseCheck activity:

This class is responsible for reading the contacts stored in the device and sending them the SMS without user consent with a defamatory message about the owner of the device. This class is also responsible for doing HTTP Post of the data collected from the device. However the owner of the website has publicly claimed that their website has no intention of collecting these data and this is solely done to create a negative publcity about them.

The Walkinwat Trojan is using multithreading to send the SMS to the contacts.

Fig.2 shows the code snippet of LicenseCheck class. At line no:36, the URI is assigned the value of Contacts.Phones.CONTENT_URI and it is subsequently used by a ContentResolver object to get a cursor of contacts stored in the mobile device.

At line no:54 and 55 a Thread is created in each iteration (every iteration processes a contact number) and the thread object is fed with the current contact number and the thread is started.

The class named “C” which is part of the Walkinwat extends the Thread class to provide support for Multithreading.

Code snippet that reads contacts and starts threads

Code snippet that reads contacts and starts threads

Fig.2: code snippet of the activity that is responsible for reading the contacts and starting threads

A closer look at the Thread procedure:

A quick background info, in Java a Thread can be created either by subclassing the java.lang.Thread or by implementing java.lang.Runnable interface. In this case a class named “C” is designed as a subclass of Thread. The code that needs to be executed by the thread is defined in the callback method public void run().

Thread definition

Thread definition

Fig.3: code snippet of the callback method run(). The thread procedure

As discussed earlier, in the every iteration of processing the contacts the LicenseCheck class creates a new thread and passes the value of the current contact and starts the thread. Once the thread is started, the run() method gets triggered whenever the thread gets scheduled. In the run method at line no:44, you can see that a Text message is sent to the contact with the text that mocks the user of pirated applications.

Cheers 🙂