Eleonore Exploits Pack's Unescape Cipher

In this blog post, we will cover Eleonore Exploits Pack's obfuscation, which is meant to conceal the true intent of the source code that the exploit page serves up.  Obfuscation is one of a few ways that attack kits try to protect themselves and their malicious intent.  The obfuscation of their code discourages analysis because it looks too difficult to handle.  With a little bit of patience and time, we can learn to deobfuscate the content and fully understand the intent of the attack code.  The kit also protects itself by only serving the exploit page once per visitor, identifying visitors by IP address.  This may seem counterintuitive, since it does limit the exposure of the attack, but it also protects the kit from analysis because researchers only have one shot at obtaining the payload.  

Despite the obfuscation we are about to cover, Websense customers are protected from the Eleonore Exploit Pack by the real-time analytics in ACE, our Advanced Classification Engine.  Because of ACE, we can block sites hosting Eleonore Exploit Pack the first and only time that customers are exposed to it. 

Here is a screenshot of the Eleonore Exploit Pack's login page:

Behind this login page are all sorts of stats for the attacker, such as what operating systems, browsers, and countries have visited the attack site.  It also shows which Web sites referred visitors to the kit, and allows attackers to upload the malware they want loaded onto victim computers.  I digress, though. These descriptions are meant for another time and another campfire story.  Below, we can see the attack code served by Eleonore.  All we know is that this code is meant to exploit visitors. From looking at it, we can't tell how visitors are being attacked.  In order to understand the how, we need to deobfuscate the code to make it human-readable.

This is a screenshot of the Eleonore Exploit Pack's attack code served to visitors:

First off, I'll tell you that I cleaned up this code a bit. The attack code is longer than 31 lines, but I removed most of the encoded or obfuscated attack code to make the rest of the source code easier to see.  

Hint:  The variable oRxBt5K8aKg9Ig is the shortened obfuscated code. This will be primarily what we try to deobfuscate. 

Looking at the code on this page, we can see that it's fragmented, meaning that not everything needed to deobfuscate the code can be found on this page.  At the top of the page, there is a JavaScript file that we'll need to fetch in order to fully deobfuscate this code.  Why is the attack page fragmented in this way? I would venture that it's another protection mechanism, because some tools can't handle code that is separated by files. For example, I can't parse the script out of this page and expect malzilla to deobfuscate it for me.

Screenshot of 432.js:

Looking at the first variable that is declared after the long, obfuscated variable, we can see a function call to jklsdjfk(). This function can be found in the 432.js file fetched at the top of the attack page.  Looking further into 432.js, we can see that the function basically concatenates a few strings together to return "unescape".  After setting var dsl = unescape, there is another variable declared which is set to the character "%". Anybody who has handled deobfuscating scripts by hand can probably already figure out what's going on here.  This page is simply using a cipher for the % in that encoded variable to get our attack code.  If you look closely at the encoded variable, you can see there is a repeating pattern "kljf hdfk sdf"followed by two hex digits.  This obfuscation simply is a cipher of kljf hdfk sdf for % and unescaping the variable to get the attack code. 

To make this pattern easier to see, here is a screenshot of the encoded variable from above:

Now we can take this variable, replace the cipher, and unescape it a couple of times because it's actually double escaped and viola we can see the true intent of this obfuscated page.  Looking at the clear code text that we now have, it's obvious that this page is up to no good by trying to invoke a number of exploits.  There is even a reference to an executable on the page called updates.exe! 

Who would have thought 51 lines of code could cause this much damage?

Here is a screenshot of the clear attack code: