Analysis of a Blackhole Exploit page

The Blackhole Exploit kit is still a very popular attack on the web. They are many variants of the threat. Here is a detailed analysis of one Exploit kit page and the obfuscation technique leveraged by the attack.

In this example, the exploit is heavily obfuscated. The exploit has been encoded and stored as HTML and JavaScript is used to decode the payload and run it.

Blackhole Exploit encoded ans stored in HTML

JavaScript decoding loop

To decode the exploit, I used Malzilla, a popular JavaScript deobfuscation tool. Malzilla cannot manipulate the DOM like a real web browser, so I needed to copy and past the HTML-encoded data into a JavaScript variable. I then changed the JavaScript loop slightly, to extract the data from the variable instead of the HTML. Instead of doing an eval() of the code, I replaced the last line with document.write(c) to output the result.

The code below was delivered by Malzilla following the aforementioned adjustments (I've cut out the encoding data):

Modified code to run in Malzilla

I can now execute the script. The obfuscation requires many passes to fully decode the data andit takes quite a while to complete.

Script executed by Malzilla

Now, let's examine the output from Malzilla. The first part addresses a "Please wait page is loading..." message, very typical of the Blackhole Exploit kit so that the victim remains patient while the exploit code executes.

Then, the JavaScript figures out which browser is visiting the page, what plugins are installed and with which version. This is subsequently to decide which exploit payloads to deliver.

Browser fingerprinting

Depending on what browser information was obtained, different exploits can be delivered. It could for example be a malicious Java applet:

Launch a malicious Java applet

... or a remote code execution targeting a known Internet Explorer vulnerability:

MDAC exploit for Internet Explorer

.. or a malicious PDF file:

Malicious external PDF file

... or a malicious Flash file:

Malicious Flash file

Separating the exploit into an encoded payload and a decoding loop made it easier for the exploit kit creators to create an infinite array of different pages in order to evade detection. The Exploit kit is also more sophisticated than many other exploits as it is able to use the right exploit for each visitor.

Analysis of multiple exploits

The most common type of malware seen in Blackhat spam SEO is the fake antivirus. But I also see other types of exploits from time to time. This week, the same malicious page came up on different domains: 4rukel.cz.cc, 4lofs.tk, 1polidsf.co.cc, 1barede.co.cc, 3timesto.tk, 4greaix.cz.cc, 4krudi.cz.cc, etc.

This page is interesting because it uses exploits rather than social engineering to install the malicious code. Below are the details of the exploits / malicious code.


Heavy obfuscation

The JavaScript code is heavily obfuscated. It cannot be de-obfuscated by a simple copy-paste of the code into Malzilla, some of the decoding has to be done by hand.

Original malicious code

One common technique, used in this page, to break the JavaScript de-obfuscation tool is to make references to the DOM. On this page, part of the JavaScript code is included in a textarea HTML tag. It is retrieved and executed later with code like this:

eval(document.getElementByTagName('textarea')[0].value);

While executing the obfuscated JavaScript code, new HTML elements are added to the page, and used to store values or JavaScript code retrieved again later in the JavaScript code.

First de-obfuscation pass generated new obfuscated JavaScript code!

Fortunately, all the JavaScript code is inline. There is no external file, which always make the de-obfuscation harder.


Multiple exploits

Like many malicious pages, several exploits are included on this page:

1. 2 malicious Java applets, using different techniques for Internet Explorer and Firefox
2. PDF exploit
3. Quicktime '_Marshaled_pUnk' Remote Code Execution Vulnerability
4. Heap spray attack
5. Internet Explorer MDAC exploit
6. Internet Explorer "iepeers.dll" exploit
7. 3 Flash exploits

Part of the code for the Java exploit

I believe these exploits come from different sources because the coding style of the various functions varies greatly.


This malicious page tries the different exploits until one is successful. Users need to make sure they keep both their browser and their plugins up to date.

-- Julien

Infected Javascript file

When legitimate sites are hacked, attackers usually modify the existing HTML pages to add their own code (obfuscated Javascript or invisible IFRAMEs), or add new fake pages to the site. The additional code is commonly found after the </html> tag, before the <html> tag, or just after the <body> tag. Since most sites do not use Javascript obfuscation, these hijacking attempts are often not too hard to spot. Even if a site use Javascript obfuscation to hide e-mail addresses, these harmless pieces of code are much smaller than your typical malicious code, and often use just one escape statement.

We also occasionally see instances where static Javascript files are hijacked. These are often much harder to detect. We recently found the following malicious code appended to a static Javascript file on an Indian Telecom website:

Obfuscated Javascript appended to legitimate code

With the help of Malzilla, I've analyzed the Javascript code. It attempts to download another Javascript file from gumblar.cn, a known malicious site.

Deofuscation of one malicious function

Hijacking a static file is much harder than modifying a dynamic page. Many content management systems (Joomla, Drupal, etc.) and blogs (Wordpress, etc.) are hacked through an SQL injection, or through a privilege escalation, which gives attackers access to the templates or the SQL database used to generate the dynamic pages, but does not provide access to static files. An attacker must have greater access to the infected host, as given by a remote PHP file inclusion for example, or the ability to access any sensitive file in order to successfully perform this type of attack.

-- Julien

More and more obfuscation being used in the malicious scripts

As we saw in a previous blog post, malicious, obfuscated JavaScript is being injected into legitimate webpages. Attackers not only use simple obfuscation techniques, but also leverage rather complex approaches to hide their malicious code. In another recent blog, we saw how attackers have used publicly available Base64 encoding techniques to hide their malicious code. This is often done to evade Antivirus detection. Recently, we discovered yet another heavy obfuscation technique. Automated deobfuscation tools/services such as Webpawet and Malzilla were challenged by this particular sample. Here is the malicious code prior to being deobfuscated.

As can be seen, Malzilla was unable to manually analyze the code.