Analysis of a Web Attack

Consumers are increasingly being warned of web-based malicious attacks and the increased threat they pose to everyday surfing. In this blog entry I intend to illustrate one such attack. Aside from being (hopefully) interesting, I hope it also illustrates the organisation and sheer aggression of the malware authors.

The ultimate goal of the typical web attack is in the installation of some malware on the victim machine. The malicious sites and web pages used to achieve that goal are often referred to as drive-by-download. Various kits are available (and sold) making it pretty easy for the bad guys to set up and create a series of malicious pages designed to install their malware. So, with the code created, all that remains is finding a suitable host for the content…

Many web attacks are hosted on custom domains registered and set up specifically for the job. Such attacks move regularly to new domains, in an attempt to thwart URL filtering protection. More recently, SophosLabs have reported a significant increase in the use of compromised sites (for both malicious attacks and phishing attacks). From the hackers point of view, hosting the content on compromised, legitimate sites can present several benefits. Most importantly, the site may already have a large readership, thus providing a huge pool of potential victims.

Once the content is hosted on a site, the hacker has to generate traffic to that site. There are many ways to do this including:

• enticing content (sex sells)
• redirect from another page
• load the content silently from another page (most probably compromised)
• link to content in spam messages (entice user to click on link)

Once the victim browses the page, the goal is for silent installation of the payload malware. Browser vulnerabilities provide a convenient mechanism to achieve this. Specific details concerning a recent attack (seen on various domains) are described below.

The start point of the infection chain in this case is a single page containing embedded iframe tags. Using embedded iframes is a useful technique to silently load additional web content when browsing a page (useful both legitimately and maliciously). As is typical with malicious attacks, the size of the embedded frame is set to either zero or very small (<10 pixels). The observant may notice the ‘dots’ in the web page hosting these tiny iframes:

These embedded iframes silently load additional content. In the case of this attack, five additional pages are loaded. Four contain malicious, heavily obfuscated Javascript (Mal/ObfJS-A, Mal/ObfJS-C), the fifth is a Win32 executable. Two of the malicious Javascripts themselves write further embedded iframes to the page, loading seven other files!

These seven files are the malicious scripts that contain exploits attempting to target browser vulnerabilities in order to deliver the final payload (the Win32 executable). The exploits used include:

1. MS07-017 (malicious ANI files)
2. MS06-014 (ADO stream)
3. MS03-011 (malicious Java applet)
4. MS05-009 (malicious PNG files)

The following diagram provides an illustration of the infection mechanism. The detection names of the various components (pro-actively detected) are included:

Though not used in this specific series of attacks, other vulnerabilities that are very frequently targeted include MS06-057 (‘SetSlice’), MS06-067 (‘KeyFrame’), MS06-001 (‘Windows MetaFile’) and MS06-055 (‘VML’).

The infection mechanisms used in Web attacks are often very complex, with a myriad of files involved, loaded from several domains in many cases. Full analysis of the attack can be very time consuming, with lots of files to investigate (and in many cases decrypt).

And the payload? In this case the Win32 executable that is the payload (the “purpose” of the whole attack if you like) is pro-actively detected as Mal/Behav-112. If the attack is successful and the executable is run, it performs the following actions:

• drops a DLL to the system folder (comi.dll)
• registers that DLL as a browser helper object (BHO)

The dropped DLL is also pro-actively detected (Mal/Packer). A brief look shows this to be a banking Trojan, with the following characteristics:

• harvest username/password data from victim machine
• log keystrokes
• monitor browser sessions

So, financially motivated – no surprise. If you are going to go the trouble of a setting up a Web attack across various compromised domains, the ultimate goal has to be ‘worth it’, and unfortunately, crime pays.