I recently had to analyze a compromised web site that was serving malware. The web site included an iframe (of course) that pointed to a script exploiting various vulnerabilities.

As you can probably already guess, the script was obfuscated, but this time I saw something relatively new (nothing ground breaking, but an interesting move).

The web page with the exploit was split into two parts: a VBScript part and a JavaScript part, as you can see below:

Now, the interesting thing about this script is that the JavaScript part needs the VBScript part to finish the deobfuscation properly. If you look carefully at the screen shot above you can see the following parts:

• The page starts with a VBScript. It defines some variables (mcvk, ybjfo, da) and then calls unescape() on a reversed string with certain characters replaced.
• The result of the unescape() function is placed in a variable called togn. Now the VBScript part finishes and the JavaScript part starts.
• This part again defines some empty variables (hq, bi) and then calls eval() on the togn variable.

The togn variable that was the result of the VBScript code actually contains JavaScript code that is needed for proper deobfuscation. The eval() call evaluates a string and executes it as if it was script code.

So, in order to deobfuscate this page we need to first process the VBScript part, paste the output into the togn variable and then execute the JavaScript part. Alternatively, we can use a debugger that works with both languages which means we have to use Internet Explorer on Windows.

If you've been reading our diaries you should already know how to deal with simple VBScript and JavaScript obfuscation (if not see http://isc.sans.org/diary.html?storyid=3351 and http://isc.sans.org/diary.html?storyid=2358 or you can check the SEC610 (http://www.zeltser.com/reverse-malware/) course Lenny teaches at SANS Institute, where I wrote the advanced web malware deobfuscation part).

Once the first part is deobfuscated, the togn variable will contain the following code:

function lid() {return "%u313d%u3030%u2634%u3d69%u3131%ucccc";} function   goqod(jyr) {  var   wbn,y="Fj2H9{NnzU*1CuP}-MEt!~bh.wBTI=6k3x[gyZG+$ld\"8#s@&mKaf7ev'54J;i(0:VOArc|^q)`]_o ,p",sgb='',de,ylg,nm='',u;   for(wbn=0;wbn<jyr.length;wbn++)  {  de=jyr.charAt(wbn);  ylg=y.indexOf(de);  if(ylg>-1)  {  u= ((ylg+1)%81-1);  if(u<=0)  {   u+=81  }  nm+=y.charAt(u-1)   }  else  {  nm+=de  }  }  sgb+=nm;       document.write(sgb);  }

The function goqod() gets called from the JavaScript code and is the one that handles the final deobfuscation (at the end the document.write call executes various exploits).

As this was relatively easy to deobfuscate, you might wonder why did the bad guys go that far and made things more complicated by using both VBScript and JavaScript. While I don't know the answer to this, my guess is that they are trying to prevent researchers from using automated honeypot/crawler machines based on JavaScript parsers (such as SpiderMonkey) from detecting the exploit. Executing these functions on a system that doesn't support VBScript will not return anything (the JavaScript code will fail due to a call to an inexistent function).

Besides making things more difficult for researchers, this "advanced" obfuscation also helps in evading AV detection. While the test on VT is not a real indicator (some AV programs have abilities to detect exploits better in browsers), when a scan of a file returns 2/32 as the result, that doesn't sound encouraging.

--

Bojan