Obfuscation is a mechanism to hide attacks from static detection tools, which use signatures to match against a known malicious string. Obfuscation causes the appearance of the malicious string to change therefore evading these detection tools. It is a technique we frequently encounter and something that is supported by the IcePack and MPack tool. With access to the MPack code, we are able to take a deeper look at how obfuscation is applied and whether there are weaknesses in the obfuscation routine.

Attack pages provided by MPack are obfuscated. The decryption routine executes three time before the attack page is in a state in which the browser can execute the contained attack code. A sample of the various obfuscation functions is shown in Figure 9 , which leads to an obfuscated attack page as shown in Figure 10 . It is obvious that a simple string matching algorithm would be unable to match on the attack code if this content changes upon every request.

00: function encrypt2($content)
01: {
02:  $table = "[email protected]";
03:  $xor = 165;
04:  $table = array_keys(count_chars($table, 1));
05:  $i_min = min($table);
06:  $i_max = max($table);
07:  for ($c = count($table); $c > 0; $r = mt_rand(0, $c--))
08:  array_splice($table, $r, $c - $r, array_reverse(array_slice($table, $r, $c - $r)));
09:  $len = strlen($content);
10:  $word = $shift = 0;
11:  for ($i = 0; $i < $len; $i++)
12:  {$ch = $xor ^ ord($content[$i]);
13:   $word |= ($ch << $shift);
14:   $shift = ($shift + 2) % 6;
15:   $enc .= chr($table[$word & 0x3F]);
16:   $word >>= 6;
17:   if (!$shift) { $enc .= chr($table[$word]); $word >>= 6; }}
18:   if ($shift)
19:   $enc .= chr($table[$word]);
20:  $tbl = array_fill($i_min, $i_max - $i_min + 1, 0);
21:  while (list($k,$v) = each($table))
22:  $tbl[$v] = $k;
23:  $tbl = implode(",", $tbl);
24:  $fi = ",p=0,s=0,w=0, t=Array({$tbl} )";
25:  $f = "w|=(t[ x.charCodeAt(p++)-{$i_min}])<<s;";
26:  $f .= "if(s){r+=String.fromCharCode({$xor}^w&255);w>>=8;s-=2}else{s=6}";
27:  $r = "<script language=JavaScript>";
28:  $r.= "function dc(x){";
29:  $r.= "var l=x.length,i,j,r,b=(4096/4){$fi};";
30:  $r.= "for(j= Math.ceil(l/b);j>0;j--){r=''; for(i=Math.min(l,b);i>0;i--,l--{{$f}}document.write(r)}";
31:  $r.= "}dc(\"{$enc}\")";
32:  $r.= "</script>";
33:  $r2 = "document.write( unescape('%3C%73%63%72%69%70%74%3E%20%0D%0A%66%75%6E%63%74%69%6F%6E%20%7A%58%28%73%29%0D
     %70%74%3E')); zX('".encodezTxt($content)."');";
34:  $r2 = "<Script Language='JavaScript'>".$r2."</Script>"; // [\\'\">]
35:  $r2 = "<script language=javascript>document.write(unescape(\"" .escape($r2). "\"))</script>";
36:  return $r2;
37: }

Figure 8 - MPack Obfuscation Routine

However, MPack v0.94 currently contains a major bug in its obfuscation routine: it produces unchanged obfuscated output on the same attack page (the bug is located on line 3 of Figure 9 : instead of 165, it should be a random number). Even if the bug is fixed, there seems to be a finite number of obfuscated pages the current version of MPack could generate, and therefore static matching does fall into the realm of possibility on the attack page. Alternatively, several efforts attempt to decrypt obfuscated JavaScript and statically analyze the code in the clear [15],[16] or the code's behavior within a JavaScript engine [17].

<script language=javascript>document.write(unescape("%3CScript%20Language%3D%27JavaScript%27%3Edocument.write%28



Figure 9 - Obfuscated Attack Page (Snippet)

On top of this obfuscation, however, additional obfuscation is likely to be applied to the front-end page that imports the page from the exploit server. These front-end pages do not merely place a static iframe on the page that imports the exploit. Rather, obfuscated JavaScript snippets append the iframe (via the document.write method) to the page once it is opened. Since this technique is independent of the web exploitation kit, it might even been applied with the earlier web exploitation kits that did not support obfuscation.

In addition, there are other means to determine whether a web exploitation kit is involved in an attack. A successful attack by a particular web exploitation kit seems to cause similar state changes on the client machine (see Appendix A for a complete list of state changes encountered on the URL http://www.keithjarrett.it, which was attacked by an MPack server). As such, simply reviewing the state changes that are caused on the client, one is able to infer what web exploitation kit was used in the attack. For example, reviewing the MPack attack page we observe that a file with the name “sys” plus four random characters and “.exe” is always pushed to C:\. Matching on this behavioral signature of this specific file write event among the state changes yields an identification of MPack attacks. From the 306 malicious URLs we identified in our KYE study, we were able to identify 13 URLs (or 4.24%) that utilized MPack using these behavioral signatures:


Table 3 - MPack URLs

We also discovered a static iframe as part of the attack page in Mpack that attempted to import an additional page “/counter/index.php” from a the remote web server “allhigh.org”. If this was indeed included by the creators of MPack, the purpose of it might be to count the number of times their framework is used or to potentially steal a customer for themselves. The path name indicates that it is used for counting, but because the URL is not live anymore we can not assure any explanation. Either way, if such static iframes are used, identification of a web exploitation kit would be straightforward: simply monitor DNS lookups to the specific host name. If a DNS lookup of allhigh.org is observed, that would be the indicator that a client attack by a web exploitation kit MPack was attempted.