Archive for the ‘Malware Analysis’ Category

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!

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 šŸ™‚

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 šŸ™‚

 

IDA Pro plugin for parsing Java class files constant pool table

February 20, 2011

I am working on a IDAPython plugin to parse the ConstantPool table of a Java class. Here is the snapshot of the output of the beta grade plugin.

Java Constant Pool parser output

Java Constant Pool parser output

I am just having few plans to enhance this to annotate the IDA Pro’s disassembly of Java Bytecode and to improve the readability.Ā  I am not sure whether it is too simple otherwise thinking to submit it for Plugin contest.

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 šŸ™‚

 

Win32/SpyEye analysis inside IDA Bochs

February 11, 2011

While analyzing aĀ  SpyEye variant inside IDA Pro Bochs, I observed this interesting point. SpyEye, as part of it’s start routine, loads the pieces of the encrypted content in the resource section using “FindResourceA()” and “LoadResource()” APIs. Here is quick snapshot of the data.

Resources of the SpyEye

Resources of the SpyEye

Subsequently after processing the loaded resources, SpyEye injects a thread into Explorer.exe and carries on the payload.

The interesting point here about the analysis is, When I tried to debug the sample using IDA Bochs plugin, the sample immediately terminated during the startup itself. Digging into the reason why it terminates, I just understood that “FindResource()” API is not implemented in the default Bochs config.

Just jumping to the code reveals this:

Code of FindResourceA inside Bochs

Code of FindResourceA inside Bochs

Bochs implementation of FindResourceA

Bochs implementation of FindResourceA

and spyeye specifically checks the loaded resource length to proceed further.

It sometime feels nice to know about whats going on behind the screens.

Cheers šŸ™‚

 

 

Dynamic analysis of a Java malware – OpenConnection

January 11, 2011

The general trend of malware implemented in Java programming language is increasing. Thanks to Java’s platform independent bytecode technology and the wonderful VirtualMachine.

Analysis of Java bytecodes is relatively simple task (unless it is obfuscated). There has been some very nice tools to decompile the bytecode back to source with great accuracy.

For a change, in this blog post, I have chosen to write about the dynamic analysis of a Java Applet. The entire analysis is carried out inside a controlled (simulated) networking environment using Zelster’s Remnux VMImage as the internet server.

Payload of OpenConnection:

  • As the name suggests, the Applet accepts a parameter named “URL”.
  • It opens a URL connection with the URL (typically an executable file).
  • It reads the binary data from the Socket’s input stream and writes it to a File object’s OutputStream (in %temp% folder).
  • Once, the file is successfully downloaded, it spawns the downloaded executable.

Ok, the payload is very familiar one and nothing exciting about it. Lets see the dynamic analysis steps:

Step 1: Decompile the class file. There has been many decompilers available. [I personally use jad or jd-gui]

Step 2: Include some debug statements (some System.out.println statements here and there to print value of the variables )

Step 3: Compile the file to create the class file and pack it as a jar archive.

Step 4: Now, to satisfy the Java security model, an Applet has to be signed to access local file system and do process related activities. We use JDK’s keytool and jarsigner for this step.

Signing the jar file

Signing the jar file

Step 5: now the jar file is signed, we will host this jar file along and a companion html file to the Remnux server.

Step 6: Now start the FakeDNS.exe in the test machine and resolve all the domain queries to the Remnux server.

fakedns in action

fakedns in action

Step 6: To create a perfect ecosystem for the malware to flourish without any obstacle, we need to lower the Java’s default sandboxing security policy. This can be done by JDK’s policytool.exe

Changing default policy to grant all permissions

Changing default policy to grant all permissions

Step 7: With everything set, access the html file hosted in the remnux server that embeds applet into it.

Step 8: The user is presented with a warning about the active content about to be executed and asks your approval to trust the self signed certificate.

Certificate prompt

Certificate prompt

Step 9:Now, the init() method of the applet is called, which inturn invokes the method that opens a connection to an executable (again hosted in remnux server. in this example, i have hosted winmine.exe)

Step 10: The debug messages can be seen in Java Console.

Debug messages in jconsole

Debug messages in jconsole

Step 11: Once the sample is downloaded, it spawns the executable. (in this case winmine.exe). The Parent-child relationship can be seen through process explorer.

Process Explorer to verify the the IE -> Java -> winmine

Process Explorer to verify the the IE -> Java -> winmine

This stresses the importance of paying attention to the security popups even during a casual browsing session.

Cheers šŸ™‚

 

 

Hardware Breakpoint is now supported by VirtualBox (Bug:477)

December 5, 2010

Just a good news for VirtualBox users (especially Reverse Engineers). The earlier versions of virtualbox VMM/RAW module was not supporting hardware execution breakpoint in Ollydebugger. I just gave it a try with 3.2.12 and it has got fixed. Strange that this does not got mentioned in the release notes.

screenshot.

Hardware BP in action

Hardware BP in action

Cheers šŸ™‚

Using Appcall and DPC for analyzing hash resolution

October 17, 2010

Last week I went through a very nice blog of Elias Bachaalany (http://www.hexblog.com/?p=193). It was an extremely nice read to demonstrate the power of Appcall feature of IDA Pro and how it helps to explore the analysis of malware interesting and easy.

In the same time, I was also thinking about the legendary Pedram’s PAIMEI and decided to play with the same malware using PAIMEI and cameron’s Debugee Procedure Call.

Just a short recap of EB’s blog: The incident is about a malware that uses hash of the library code as the key to resolve the API at runtime and the idea is to use DPC to invoke the function of the malware (the function responsible for resolving the APIs through hash) at our will to explore the behavior.

 

DPC in action

DPC in action

 

It worked like charm.

Now, what remains a mystery is why the great pydbg and all of the scripts stresses that it has to be attached to a malware instead of “loading” it from the scratch despite In many cases loading a malware would be ideal.

Cheers šŸ™‚