Using textareas for evil

Recently I've gotten a new job and have been doing significantly more interesting things with my time. Woo hoo!

Web exploit kits are always evolving and using new techniques to complicate automated analysis. I've been looking at one group in particular that is using blackhat SEO for google image search in order to redirect a user to a malicious site. Basically, someone performs an image search for something innocuous and clicks an image result that contains an iframe to the blackhat SEO domain. If the iframe code is executed, the person is 302'd to an intermediary domain. The intermediary has some basic server-side defenses that check the referrer string, IP address, and whether either has been seen before and how long since they have been seen. If so, the site redirects to google. If not, you reach the exploit domain.

The HTML on the exploit site has two textarea tags at the top of the page:


Notice the code after the textarea sections is a giant obfuscated <script>. Running it through the usual suspects (wepawet, jsunpack, spidermonkey, malzilla) doesn't yield good results. The reason? The textarea tags -- they aren't used until the end of the page:


Not only do they contain a couple syntax errors, but the typical tools don't seem to handle the textarea calls very well. Wepawet partially decrypted the page, but ultimately categorized it as benign. Not good.

So what's actually happening? The first textarea tag contains the function to deobfuscate everything in the script tag. When you run the function through spidermonkey, you see a document.write that writes out <p>[some integer]</p>. This integer is used in a for loop to deobfuscate the script. Substitute the integer value where it needs to go in the function, clean up the code a bit, and use the Didier Stevens spidermonkey package and the web-obj.js script from REMnux, and the eval'd <script> code gets piped out to file:


The deobfuscated page hits you with a variety of exploits, dating back to 2006.