Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Blacole's obfuscated JavaScript

Published: 2012-04-25
Last Updated: 2012-04-25 11:44:21 UTC
by Daniel Wesemann (Version: 1)
1 comment(s)


Looking back on how we used to analyze malicious JavaScript five years ago, it is quite amazing to see the "evolution" of code obfuscation that the bad guys went through.

Most of the current obfuscation methods make heavy use of objects and functions that are only present in the web browser or Adobe reader. Since it is unlikely that a JavaScript analysis engine on, for example, a web proxy anti-virus solution can duplicate the entire object model of Internet Explorer, the bad guys are hoping that automated analysis will fail, and their JavaScript will make it past the virus defenses to the user's browser, where it will run just fine.

Often, this actually works. The current wave of Blackhole (Blacole) exploit kits are a good example - it took Anti-Virus a looong time to catch on to these infected web sites. Even today, the raw malicious JavaScript block full of exploit attempts comes back with only 14/41 on Virustotal
 

Here's what the Blacole obfuscated Javascript looks like:

Unlike "older" obfuscation methods, this "Blacole" encoding is almost human readable again. But automated analysis still has a tough time with it, because the code is heavy on browser objects and function prototypes:

 

None of this will run in command line JavaScript interpreters like "SpiderMonkey". Analysis environments like Cuckoo and Wepawet are doing a pretty good job at this, but often also trip up.

If all else fails, while manual analysis of the code is tedious, it usually leads to the desired result. A bit further down in the JavaScript block, we find

This looks like a loop over the code block that replaces/transposes characters based on their ASCII code. If the ASCII Code is >25 and <52, 26 gets added to it. If it is >=52 and <78, 26 gets subtracted. Otherwise, the ASCII code remains unchanged. This is like a "poor man's Caesar Cipher", swapping out one letter against another.

Something we can readily reproduce in a couple lines of Perl :)

$cat decode.pl
#!/usr/bin/perl -w
while (<>) {
  for ($i=0; $i<length($_); $i++) {
    $c=substr($_,$i,1);
    $o=ord($c);
    if (($o>25) && ($o<52)) {
      $k=$o+26;
    } elsif (($o>=52) && ($o<78)) {
      $k=$o-26;
    } else { $k=$o };
    print chr($k);
  }
}

And, lo and behold:

$cat malscript.js | ./decode.pl


The decoding is not yet complete (there are a couple more steps in this obfuscation), but the name and location of one of the EXEs is already apparent.

 
Thanks to ISC reader Jan for the sample.

 

1 comment(s)
Diary Archives