Exploit Kit Roundup: Best of Obfuscation Techniques

The world of exploit kits is an ever-changing one, if you happen to look away even just for one month, you'll come back to find that most everything has changed around you. Because of this, people like us, who work on a secure web gateway product, are continuously immersed in the world of exploit kits. Every once in a while it's a good idea to stop, take a look around us, and review what's changed. We would like to share some of the more interesting obfuscation techniques we're seeing utilized by exploit kits. We'll focus on techniques used to obfuscate exploits for Internet Explorer (since obfuscation methods differ for Java, Flash and other web content.)

Flash Exploits vs. Flash: The New Exploit Delivery Method

Flash exploits reached their peak a few years ago when exploit writers realized that most client machines had Adobe's Flash Player installed and vulnerabilities were still in abundance, but as time progressed Adobe rolled out a few key features such as sandboxing and silent patching, that made writing exploits for Flash Player a bit of a pain (and so exploit writers moved on to Java). This is not to say that Flash exploits have disappeared entirely- we still have the odd exploit such as CVE-2014-0502 and CVE-2014-0497 popping up, not to mention LadyBoyle who's still around. It seems, however, that attackers found a way to use the fact that Adobe Flash Player is installed on pretty much every client machine while avoiding the need to exploit Flash Player itself with all its hurdles: Flash Player is now used as more of a delivery platform to de-obfuscate the shellcode, call JavaScript methods in the original page that are otherwise completely unreferenced in the page itself, issue requests to additional URLs for more data, and other uses that don't involve an actual vulnerability in Flash Player.

Infinity Exploit Kit is a good example of such use of Flash: The Flash file defines a method and exposes it to the external page, then calls a method in the external page that prepares parts of the attack and calls the previously exposed method inside the Flash file, resulting in three transitions, or "hops" between the HTML page and the Flash file. These hops back and forth make it hard to follow the flow of (and thus detect) the attack:

Hop 1 - The HTML page loads the Flash file with "allowScriptAccess" set to "always", which allows the Flash file to, amongst other things, call methods in the HTML page:

Hop 2 - ActionScript code from the aforementioned Flash file. The first marked line shows the Flash file exposing the "wombt" method to the HTML page, and the second method calls a method by the name of "grask2" in the HTML page:

Hop 3 - A quick look at the "grask2" method in the HTML page shows us that this method indeed calls the "wombt" method exposed by the Flash file:

Taunts Us with AJAX

The Neutrino exploit kit took more of a whitehat path to obfuscation and fetches the code, in parts, using AJAX. Not only does it use AJAX requests to pull (and then deobfuscate) some of the shellcode, but it also issues some completely random requests to drown the obfuscated nonsense-looking data in other genuinely nonsensical data. It also uses the (real) JQuery library, as most web developers do:

In the image above you can see that the page issues a request to a page with a seemingly random name. The third argument sent to the get() method is a callback to execute upon success, in our case, the method "z" right below it. This method appends the code to the body of the page, but not before performing additional de-obfuscation with the help of the "i" method, turning the returned data into HTML code which, in turn, loads the exploit that the machine is most likely to be vulnerable to.

In addition to these requests that bring in more code, the page also issues some completely randomized requests in a method called "f_query" that looks like this:

As you can see, the arguments, as well as the HTTP method to use, are all generated with the help of randomization methods and the responses to these requests are never examined; This means that although the page issues multiple GET and POST requests, only the returned data from the request issued in the "query" method is really used to generate further code for the page to execute.

Mixing unnecessary data into legitimate data is a common approach used by many malware developers in an attempt to evade security products and measures.

Anglers Phish (Even When They're Using Exploits)

Angler Exploit Kit indeed lives up to its name, and though an exploit kit works in a drive-by method, where the user should not even be aware that they are receiving any unwanted content (let alone an exploit), various security engines still look at the static source code of a page to help determine whether a website is legitimate or malicious. Angler attempts to cover its track by hiding the malicious code within code stolen from a legitimate website, so as not to raise suspicion.

It doesn't look like much to the human eye, but the source code could easily pass for a legitimate website:

But behind this innocent-looking code hides our not-at-all-innocent exploit kit:

While some of these tricks are more sophisticated than others, they were all put in place because they work against some technology used by security products. Trustwave's Secure Web Gateway is constantly updated and tested against these types of threats to ensure protection to our customers. It's certainly always interesting!

Think we skipped an interesting obfuscation technique? Tell us about it in the comments!

This blog post was co-authored by Daniel Chechik and Anat Davidi.