Websense Security Labs Blog

Websense Security Labs discovers, investigates and reports on advanced Internet threats that traditional security
research methods miss.

Phoenix Exploit Kit's Random Access Obfuscation

View all posts > 

Phoenix Exploit Kit's Random Access Obfuscation

Posted: 31 Aug 2010 09:53 PM | Chris Astacio | no comments


In this post I'll cover an interesting piece of obfuscation that we recently came across while handling a blended threat.  This threat began as several malicious emails containing a link that redirected to the site below.  The obfuscation was found in part of an attack site using the Phoenix Exploit Kit. 

 

Here is a screen shot of the Phoenix Exploit's Kit login at the site we are going to analyze:

 

Once decoded, like many attack kits, this attack site attempts to exploit a visiting computer using a number of known vulnerabilities.  The vulnerabilities focused on Java, Flash, and PDF.  What made this obfuscation particularly interesting was the way in which the decoding was done.  The algorithm used to deobfuscate the sample I reviewed was a type of random access file. 

 

Here is a screen shot of the HTML payload:

 

That alone looks like a big headache and may make your eyes cross at first glance!  We can see that there is a Java applet in the HTML code, but there is also a large script which we will focus on deobfuscating so we can understand the threat a little better.  Let's parse out the script and beautify it a bit so we know where we can start. 

 

Here is a beautified version of the script:

 

This is much easier to review but obviously still obfuscated.  At least we can now see a structure to the obfuscated JavaScript and we can see a few key areas.  First there is a huge variable declaration, cut off in the screen shot, which is probably what the algorithm is going to work on decoding.  Then there is a function definition, a <p> tag being written to the page, a nested for loop, and finally an eval. 

The first thing that caught my eye in this obfuscation was the document.write('<p>3360</p>') code.  My first thought was "Why would a malicious script write a paragraph tag containing a single number to the page?"  Then, on the next line, we can see that the above number is loaded into a variable.  This is somewhat hidden in a simple obfuscated document.getElementsByTagName call.

 

Here is a screen shot of the above referenced code:

 

The for loop is the next interesting part and, as with most deobfuscation routines, is the main part of the algorithm.  If we step through the for loop a number of times, we see that it's working to access that huge variable using the number from the above paragraph tag as a byte offset.  The inner loop is where the random access actually happens.  It runs through the long variable, starting at index 0, and uses the number in the <p> tag written to the document from the above code as the byte offset from the index until it comes to the end of the variable string.  Once the end of the variable string is reached, the outer loop forces the inner loop to pass through starting at an index of 1 and so on.  Stepping through this algorithm 15 times, you will get a bit of an obfuscated document.write( call.  Each of the characters at the index + byte offset is concatenated into another variable which, when these loops complete, turn out to be the deobfuscated attack script.

 

Screen shot of the nested loop code:

 

From this point, there are a few simple search and replace actions done via a function call and an eval to execute the JavaScript code that holds the exploits.  Reviewing the code, we were able to see that there are a hefty number of exploit attempts on different versions of Adobe Reader, Java, Flash, and other Windows components.

 

This is a snippet of the attack code after it's been deobfuscated:

 

Another thing that this site has done that is getting to be more common with attack sites, is allow only one visit to the attack page.  This seems counter intuitive as it would also limit the attack exposure for these sites.  However, this technique is meant as a protection mechanism for attackers to prevent researchers, such as ourselves, from analyzing the attacks occurring on the site.  This also makes things harder when figuring out whether to publish attacks to block databases.  Our ACE analytics allow us to capture these sites and protect our customers in a real time fashion, not relying on URL database production.  This means that from the first time our customers visit these attack sites, they are protected.


Filed under: , ,

Leave a Comment

(required)  

Email address: (required)