Hacking the Web: Hijacking search results

In this post, the first of a new series of posts in which I plan to expose some of the more interesting web attacks we encounter, I will describe some recent attacks that we have been following in which the victim’s browser is 0wned, and their search results hijacked.

Attack overview

Infection trigger
There are at least two ways in which users are exposed to this attack: browsing legitimate sites that have been compromised, and through search engine optimisation (SEO).

The compromised sites are injected with malicious JavaScript in order to redirect unsuspecting users to the exploit code used in these attacks. The compromised sites are blocked by Sophos products as Mal/Iframe-Gen. The script injected into their pages is heavily obfuscated as shown below.

When loaded by the browser, this script writes an iframe to the page, to load content from a remote site (domain name registered Jan 20th 2011). This site serves as a middle-man, redirecting the traffic to the exploit site.

Exploit site
The exploit code used in these attacks has been seen on a mixture of compromised sites and freshly registered malicious sites (mixture of .co.cc and .com TLDs).

The landing page (blocked as Troj/ExpJS-BM) on the exploit site consists of several components:

  • applet HTML element pointing to malicious Java content
  • CSS content containing some ‘unusual’ string content (‘eva’ in the code snippet shown below)
  • heavily obfuscated JavaScript which retrieves the above string content
  • this content is then used in the decryption routine, after which the script modifies the DOM in order to load the other exploit content used in the attack

An immediate question is why does the JavaScript retrieve data from the HTML style element in the page? The answer is simple – it is an anti-emulation trick intended to thwart detection and analysis techniques. It is an interesting variation on the getElementById methods that are discussed in detail in this recent technical paper.

If any of the exploits are successful, the user is infected with the payload, which at the time of analysis was a Win32 executable designed to target Mozilla Firefox browsers. The malware adds the following files in order to install an additional malicious Firefox extension (named ‘Firefox Security 2.0’):

%PROGRAM FILES%\Mozilla Firefox\extensions\{9CE11043-9A15-4207-A565-0C94C42D590D}\chrome\content\timer.xul
%PROGRAM FILES%\Mozilla Firefox\extensions\{9CE11043-9A15-4207-A565-0C94C42D590D}\chrome.manifest
%PROGRAM FILES%\Mozilla Firefox\extensions\{9CE11043-9A15-4207-A565-0C94C42D590D}\install.rdf

The timer.xul file contains JavaScript that reveals the purpose of this extension:

  • checks the current URL and if it is Google, Yahoo, Bing or Ask, it adds an additional script element to the page.
  • this script element loads another JavaScript from a remote site, which hijacks all links on the page to redirect the user to a specific site when any of them are clicked.

Additionally, the payload will also open browser windows to the infamous AdultFriendFinder website.

Thankfully, the payload is blocked as Mal/Koobface-G (though do not be misled by the name – it is not Koobface, the malware clearly uses similar packing to Koobface).

So there we go. An awful lot of fuss and effort to install what is a relatively simple piece of malware. And these attacks are not new either. We first started seeing them back in March 2010. The attacks have continued since then, with what seems to be a new push since January 2011, redirecting user clicks to a variety of new, malicious/scammy domains. One thing is clear from this, browser traffic is money nowadays.