June 29, 2011

Blackhat SEO poisoning leads to Blackhole Exploit Kit


Instead of blogging about another case of Blackhat SEO poisoning (yes, Blackhat SEO poisoning does happen every day), I'm going to focus more on what happens after clicking on the poisoned search result. Although in the majority of cases unpatched users are exploited, I want to show how sometimes researching these cases can lead to a dead end. 

This morning I saw a case that led a user from a Google search result to a Blackhole exploit kit, one of the most widely used exploit kits in the wild.  

Like most exploit scenarios, attackers always have a lure to attract the user to click on a link and start them on the path of exploitation or installation of malware. This can be done in numerous ways: Phishing emails, Facebook social networking viral scams, Google search engine poisoning, etc. In this case, attackers have poisoned search engine results of the keywords "shia labeouf", which is #10 on Google's hot trends: 

(Figure 1: Google Hot Searches. "shia labeouf" is #10)


If a user was to search for "shia labeouf", search result #45 leads to  hxxp://shiantology[dot]com/: 

(Figure 2:  hxxp://shiantology[dot]com/ screen shot)


This site has been compromised, and has an iframe injection that leads to a Blackhole exploit kit:


The iframe injected in the code silently makes a connection to the above IP address:

(Figure 3:  hxxp://shiantology[dot]com/ redirection chain)


65 [dot] 75 [dot] 129 [dot] 9 responds with the following payload (obfuscated HTML code + a JavaScript deobfuscation algorithm): 

(Figure 4: Obfuscated text within HTML div tags)


(Figure 5: JavaScript deobfuscation algorithm)


The code above causes the browser to make a connection to /games/A.class.

hxxp:// 65 . 75 . 128 . 9/Home/index.php makes a connection hxxp:// 65 . 75 . 128 . 9/Home/games/A.class 

Normally, we'd be able to see this by looking at the final resulting DOM of the browser (after all the JavaScript has run and the document.ready event has been triggered):

(Figure 6: 65 [dot] 75 [dot] 129 [dot] 9 final DOM)

One thing to notice is that looking at the above DOM code, there is no object or applet tags that are shown and require an A.class. Good thing we were watching the network connections and JavaScript hooked events. This is a reminder that a Web page with the use of dynamic client-scripting like JavaScript can continually change.The finalized DOM does not always represent the DOM at all stages of the document, changing due to JavaScript functions being called. 

What happened is that during the deobfuscation phase, the algorithm above created a series of document nodes. One of them was most certainly an object or applet which required A.class. It then did some other checks, for example browser type, and function existence all for the purpose of verifying which browser was actually running (this is an alternative to checking the user agent string) and then redirecting the browser based on the result to another redirector:

Status: 302
Location : hxxp:// 109 . 236 . 81 . 40/
Content-Type : text/html; charset=iso-8859-1

hxxp:// 109 . 236 . 81 . 40/ is a redirector that redirects the browser to google.com

Status: 302
Location : http://google.com
Content-Type : text/html

In this particular case our research has led us to a dead end. Many times the obfuscated code and checks will only trigger if ALL conditions are correct. If they are, the code redirects the browser to exploit files. If they are NOT then the redirector redirects the browser somewhere else. In this case the browser was redirected to hxxp://google[dot]com, but we could have just as well been redirected to Bing or Yahoo! or another major search engine as means of leading you off track. In many cases your browser will also be redirected to hxxp://searchportal.information[dot]com 

Websense Labs has a group of researchers specifically focused on exploit kits. Websense customers are protected from the Blackhole exploit kit as well as other exploit kits by ACE, our Advanced Classification Engine.


If you have any comments on this blog or questions about engine poisoning or exploit kits please ask them below: we always look forward to hearing from our readers and hopefully helping them understand how to protect themselves from the ever-changing threat landscape.



Stephan Chenette - Principal Security Researcher
Contributions by Elad Sharf - Security Researcher 


Forcepoint-authored blog posts are based on discussions with customers and additional research by our content teams.

Read more articles by Forcepoint

About Forcepoint

Forcepoint is the leading user and data protection cybersecurity company, entrusted to safeguard organizations while driving digital transformation and growth. Our solutions adapt in real-time to how people interact with data, providing secure access while enabling employees to create value.