Posts Tagged ‘Android Malware’

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

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

USBAutorun:

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.

fig-7

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

Conclusion:

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.

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 🙂

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.

AndroidManifest_permissions

AndroidManifest_permissions

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 🙂

 

Android/ADRD trojan analysis

February 17, 2011

It seems the Android trojan created some noise last week. So decided to have a quick look at it.Here is a very preliminary analysis of this sample.

This malware is not backward compatible. It is not installling in Android 2.0 platform. While I tried to install it in an emulator that runs on 2.0, it simply refused to install

Compatibility test

Compatibility test

A quick look at the manifest file shows the receivers and the intent filters

Receivers and intent filters

Receivers and intent filters

You can see that the sample runs in background silently.

Remote command output

Remote command output

Also, a quick look at the app-state dump shows all the receivers in action. Also, the another variant was using a custom implementation of Base64 encoding to obfuscate the URLS.

Decoding the obfuscated URLS

Decoding the obfuscated URLS

Creating a simple script to reuse the decoding function used by the malware reveals the obfuscated urls:

instrumented output of the decoded URLs

instrumented output of the decoded URLs

Looks like the the mobile platform is becoming a hot target for the malware community. We could only see the trend going upwards in the forthcoming months.

cheers 🙂