Did You Order HDTV from Amazon? - Yes | No, Phishers Targeting Amazon Brand !

The concept is the same so as the attack. This time attackers are using Amazon brand to spread infections on the Internet. The phishing email is drafted really well and shows that an order of ne product (HDTV) has been processed.  The email looks like as follows:

 

The browser is redirected to the web page showing the notification as follows:

The script looks like as shown below:

The deobfuscation results in the following code.

Again, the iframe loads content from third-party domain hosting Browser Exploit Pack (BEP). The interesting fact is that, we received a number of emails within a span of time. Every new phishing email has a new embedded URL as follows:

hxxp://shuraki.com/wp-admin/hdtvamazon.html [WordPress]

hxxp://swishmedia.ca/clients/amazinhdtv.html [Generic]

hxxp://tainguyenso.com/admincp/amazinhdtv.html [V Bulletin]

These emails look very genuine and authentic. It is highly advised that to be paranoid and think twice before interacting with these emails.

Check previous post about LinkedIn Phishing Attack - http://secniche.blogspot.com/2012/08/linekedin-invitation-phishing-blackhole.htmlhttp://secniche.blogspot.com/2012/08/linekedin-invitation-phishing-blackhole.html

Elsevier's Computer Network Journal - Understanding the Design of SpyEye Botnet

We have contributed a paper on complete details of SpyEye design in Elsevier's Computer Network journal.

Abstract: "Botnet malware is improving with the latest (3rd) generation exemplified by the SpyEye and Zeus botnets. These botnets are important to understand because they target online financial transactions, primarily with banks. In this paper, we analyze the components from multiple generations of the SpyEye botnet in order to understand both how it works and how it is evolving. SpyEye is a sophisticated piece of malware with a modular design that eases the incorporation of improvements. We will discuss in detail the complete framework of SpyEye botnet consisting of the Bot Development Kit (BDK), the plugin architecture, the backend storage server, the bot design and the web-based Command and Control (C&C) management system. In addition, we also examine the techniques used by SpyEye to steal money."

The paper is still in press but can be found at: http://www.sciencedirect.com/science/article/pii/S1389128612002666.

Enjoy!

Insidious Banking Malware and Proxy-auto Config (PAC) - A Step towards Mal-Proxying

Recently, our team came across an interesting sample of banking malware which exploits the proxy-auto-config (PAC) functionality in the browsers. Let's see what we have:-

What is PAC?
PAC is a technique to implement proxy configurations based on the rules provided in the configuration file. The browser chooses the appropriate proxy server for the configured URLs. PAC is implemented in a sandbox and few JavaScript functions are allowed to be used in the PAC files. For more details about PAC, the excellent resource is here - http://findproxyforurl.com/why-pacwpad/ . PAC uses FindProxyForURL() function to implement this functionality. Have a look at one of the example listed here: http://findproxyforurl.com/example-pac-file/.

Why malware uses PAC?
The concept is straightforward. On the infected machine, the malware downloads the obfuscated PAC file from the server. This allows the malware authors to force the rules defined in the PAC file on the active browsers. It means the malware can push the browser to choose a proxy server based on the URL rules configured in the PAC file. In simpler terms, if a user tries to open a banking website, the browser connects to the proxy server and the traffic is routed through it.

Let's look into the PAC file used by the banking malware:

The file contained an array of elements in the hexadecimal format. The next step is to see what is hidden behind this. Removing "\x" and applying hexadecimal to ASCII converter, we get the elements as shown below:

So as expected, we get the domains configured in the PAC file. Whenever, a user opens the domain listed above, the browser connects to the given proxy server and routes the web traffic through it. Interesting !. Let's look at the implementation of FindProxyForURL() function.

The above-referenced code uses shExpMatch - which attempts to match hostname or URL to a specified shell expression, and returns true if matched. More details can be found here: http://findproxyforurl.com/pac-functions/. 

var _0x355ax4=_0x4919[0] : refers to the first element in the array which is the "PROXY 46.23.77.172".

if(shExpMatch(_0x355ax3,_0x355ax6)){return _0x355ax4;}; - you know what it means :) . If the domain is matched then force the browser to connect to the given proxy server. The same process goes for the rest of the provided rules.

This shows that how exactly the malware uses the PAC concept for malicious operations.

Enjoy!.

Malicious Domain Attribution - The Criticality of Timing

In this post, we are going to talk about the importance of time factor in attribution of malicious domain. The  "malicious domain attribution": it means the different set of characteristics that are mapped or analyzed to gain control of the malicious domain. It is very critical from analysis perspective. Yesterday, we had a very interesting case about the malicious domain attribution. There are certain facts that are required to be understood for executing reverse attacks on the malicious domains. We have found that timing plays a crucial role in successfully attributing the malicious domains. What happened exactly ?

Step 1: We received a FedEx Phishing email embedded with some malicious links.
Step 2: The source of the phished email was analyzed and related information was collected.
Step 3: The links were traced to understand the source of the problem.
Step 4: The browser was redirected to malicious domain (First Hop) having obfuscated code in it.
Step 5: The obfuscated code was deobfuscated and we were served with a dynamic iframe code.
Step 6: On tracing the source in malicious iframe, the browser fetched an obfuscated code from      
             the BlackHole - Browser Exploit Pack (BEP) hosted on other domain (Second Hop).
Step 7: The code served by BlackHole BEP was again obfuscated, which on deobfuscation provided
             a plugin detection JavaScript that fingerprinted the versions of various installed plugins.
Step 8: A malicious JAR was framed inline during fingerprinting of the browser plugins.
Step 9: On successful exploitation of a Java vulnerability, an executable file was served.

Actors - BlackHole, Cridex Trojan.
Compromised Domains - Word Press website.

The communication flow is presented below:

Interesting Technique: HTTP Parameter Iteration
It is a simple technique in which HTTP parameters are iterated with different numbers to see if we get a different output or not. For example:- this technique is fruitful when the analyst wants to verify that a malicious link allows different files to be downloaded from the same URL. Sometimes this technique is worth giving a shot. We followed the same process and got same executables with different names as shown below:

We have the executable files, the JAR files and other information. At this point, the complete infection scenario is presented. What else? Do we have to stop here after the analysis? We don't believe so. What should be the target now? Exactly- finding vulnerabilities in the server hosting malicious websites. Fortunately, we found a vulnerability in the server that allow us to access a PHP shell on the server as follows:

We started looking for configuration files as shown below:

After all this point, we had an access to server (First Hop) hosting the initial infection page. But, this process did not came out to be that fruitful as we were expected.  We were in hurry to find the access information or other critical data that provided us with complete control. Unfortunately, this time the attacker was still active on the malicious domain. As a result, within no time, we were getting forbidden messages ( no further access to the server). Ofcourse, the attacker came to know that the server has been compromised.  The attacker removed the content from the server. The result is shown below:

That's the complete information of the case that we encountered recently. Now the questions, thinking points and lessons to be learned are as follows:

1. Time window plays a critical role in these types of cases. 
    Do we have to act stealthy? Should we wait for sometime if we get an access to the malicious
    server?

2. The time gap (window) or reaction time definitely impacts the analysis.
    Is this right to explore the malicious server right away without waiting?

At this point, we believe that it is a problem of choice, a kind of double edged sword.But for sure, we made a choice not to wait further and act in a dormant manner. Our decision was not that fruitful but it helped us to learn the importance of time window in performing attribution of malicious domains.

If you have other views, please share :) We will be more than happy to discuss our experiences.