BlackHole Landing Page Obfuscation Example

This posting is going to look at the initial obfuscation (outer layer) of a Blackhole v2 Landing Page.  A landing page is the site that malicious iframes and phishing links point towards.  The landing page contains the exploits that will do the attack.  References in the landing page refer to malicious objects, such as JAR files and malicious PDFs, and to malicious executables that are often remote administration tools (RATs) or in layman terms viruses.

JavaScript is a powerful language.  It has features that allow variables to be assigned to functions (like C pointers), the ability to execute data (like LISP and Snowball) and the ability to catch errors (like Ada). Some of its features are a common place in modern languages, yet JavaScript’s is extremely flexibly in its implementation especially when considering the looseness of its type casting and its ability to integrate into any environment.  The flexibility and how it interfaces with a local environmental make obfuscation in JavaScript optimal.

Many network tools attempt to run JavaScript outside the host system, and therefore many of the defenses in obfuscated JavaScript are to hinder the analysis of JavaScript outside the user’s browser.  This includes noise reduction (prevention of running exploit if the system appears unaffected), environment checks (making sure the environment matches that of a browser), and triggers (looking for human action).

In this post I am going to go through the code in a line by line fashion pointing out common obfuscation techniques.  Most techniques are in place to prevent analysis outside the browser.  You will see by the end of this posting, that a person can simplify the code and easily get to the obfuscated code beneath.  A copy of this code is on my samples page on github zipped with the password of “infected”.

Main Obfuscation Code on Blackhole Landing Page

Main Obfuscation Code on Blackhole Landing Page

The Script is divided into multiple scripts

This is done to reduce the ability to see the whole script when ripping it out.  Note that when the attacker owns the page, the script can be distributed in multiple files.  JavaScript does not care about order when it comes to functions.

line 2: if (window.document) csq = function () {

This is a test to ensure that the JavaScript sees the window.document.  This test is done in order to ensure that the script is not being run outside the browser environment.  Now, analysts might say that they can use the Chrome developer to run the script, but this is not a scalable answer for network analysis looking to run scripts to find attacks, and that is what the attacker is trying to avoid.

The block of code associated with the if statement is placed in a function.  This allows the code to appear early and be called later.  Doing so hinders scanners that use regular expressions to find patterns in commands.  A good example of regex scanners are Snort rules.  It also makes the error of the undefined function occur away from the code that defines it.

The order of this function’s definition versus its use is purposely done to prevent single pass analysis.   Function z()  used inside the function is not be assigned till near the end of the script.  z() itself points to e() which points to eval().  These declarations are out of order and placed in different script sections.

lines 12-16: try {} catch {}

This is one of the more common avoidance techniques in malicious JavaScript.  Normally the try will fail and the catch is activated.  Here, this is not the case.  The try will work and variable ‘xc’ is never set, leaving it undefined.  The remaining code is a Red Herring, as xc is undefined, or false (this occurs in strict mode), the value rrr is never set.

Why?  The reason appears to be that if the attacker is still defending against the “rip and run” technique used by network analysis.  If you were to make this one long script, combining all code in the script tags, the script will die on line 18.  The error will be that sc is undefined. And so the remaining part of the code will not run.  Placing error code near the end of a script segment is a good means to prevent tools that concatenate code into a single JavaScript file.

line 25: The setting of the ‘c’ variable.

Note that the declaration is not the standard c = …  This is done as a single implied declaration.  More importantly, the script does not use the common decimal or hex formats.  Each number is proceeded by a zero (0).  This is an octal representation.  It is done to avoid regular expression pattern matching.  This variable is large, and the contents skipped in the presentation.  As expected, this is the message that when evaluated becomes the code of the landing page.

line 40: z = e;

This line is one that we, the analyst, will change to z=console.log;

This will put the output onto the screen.  We could just examine the result in the interpeter, but that will place escapes into the output, and create work for we will need to clean it up.

Cleanup Version of Snippet

Cleanup Version of Snippet

At this point we can run the script to get the underlying JavaScript.  I will save analysis of the resulting code for a later date, though I have gone through parts of this before.  Here is the beginning of the output.  It is included in the post on github.

snippetDone

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: