Content:
During his Black Hat briefing, Jason Jones, the Team Lead for ASI at HP DVLabs, presents a professional extensive analysis of the present-day web exploit kits.
I’m going to be talking about the state of web exploit toolkits, which is a lot of what I’ve been doing on my job. I’m the Lead for Advanced Security Intelligence Team at HP DVLabs. A lot of what my job is – is to deal with malware, analyze it, try to figure out ways to determine reputation. We do a lot of malicious content harvesting. And web exploit toolkits are becoming more popular, more prevalent in the wild – it’s something that popped up on my radar and became a very interesting topic for me to continue researching.
If you’re not familiar with them, web exploit toolkits are pre-packaged software that generally consists of installer; a lot of them are PHP-based and they have database backend, it’s normally MySQL. They include a large number of exploits, and most of these exploits actually target known vulnerabilities that are already patched and are rarely 0-day. There is one instance of a 0-day vulnerability being in these things.
Another interesting and important thing is we can actually get some of these PHP files in raw form, but they are actually using the ionCube PHP Encoder which encrypts a PHP file so that it’s difficult to recover. There are services out there that claim to be able to decrypt this encoding but we never found any that actually really work.
A lot of these also have fancy control panels where you can go through and they’ll show statistics that will be about what countries your visitors are coming from, what browsers they are using, what exploits have been launched and successful. So, you can get quite a bit of information from that. And then also you can configure which exploits you want to use and which payloads you actually want to also launch. So, it ends up being very similar to a normal web application. Where they differ is their whole goal is to install a malicious payload, some piece of malware. They have been used a lot to build up botnets, Trojans, fake AV, ransomware type of stuff. At the end of the day, it’s just a way for any cyber criminal to easily build something up and make money.
A lot of these kits can cost thousands of dollars; some of them are free but some of them are very expensive. You can also do rentals: daily, weekly, monthly type of stuff. And they actually do a similar model of maybe a day costing $100, but for a week it costs $500; so they’ll offer you a discount to try to get you to go up. They also do bullet-proof hosting, which is hosting on their hosting servers where you are not going to get taken down because it’s hosted by cyber criminals, so they are not going to obey law enforcement’s request to remove it.
And a lot of times they’ll contain agreements like EULAs stating that you have permission to do this with their kit, you cannot resell it, you cannot disclose what’s in it – it’s like what you expect to see with normal software. And that’s where it becomes really interesting because the economy is built up like a legitimate software business, but in the underground. It gets really interesting because there’s also marketing and competitiveness between kits, where one kit will say: “We’re better than this kit because we have exploits A, B and C”, and the other kit will say: “Well, they stole those from us”. So it’s just like the whole back and forth between these guys.
The other way that they mimic normal software is they do a lot of bug fixes; they do reliability updates for exploits if people complain; and they also do aesthetic changes when a new version comes out, like “Oh, we added a new spinner into our control panel; we made the statistics look nicer”. So it ends up being very interesting just from that perspective of there being a feedback loop between them and customers.
This (see left-hand graphic) is an image that I borrowed from Kahu Security’s blog who talks a lot about these things and who’s definitely been someone who – if I’m kind of stuck on something and I’m trying to find something new, trying to verify a trend – he is one of the guys who has definitely been of big help. So, he’s talking about a lot of the active kits that are out there. I’m going to talk about BlackHole a lot, also Phoenix; and you also see some of the older kits like Eleonore or Bleedinglife; you also see RedKit which I don’t cover but actually I believe it has some bytecode obfuscation that’s Java exploits, so it’s just some other interesting features that are coming around in these kits.
So, the typical way these kits work (see right-hand image) is – you see here the red exploit kit server – they’ll normally try to go out and find a vulnerable website; they’ll attempt to compromise it and inject malicious JavaScript that ends up redirecting any potential visitor to their site, to this other site; and then they’ll do the typical browser detection, see if they have an exploit for what browser version you are running; so, if you’re running a plugin that they have exploits for, then they’ll attempt to exploit you. Then they’ll end up loading their malware. You can also go to the control panel on this kit and actually see a list of everyone who you’ve compromised and you can also manage them from there.
The first kit I’m really going to delve into is BlackHole. It’s been around for a couple of years. It’s definitely become the most popular kit on the market, and I’m basing a lot of that on what I’ve seen on sites like Malwaredomainlist, urlQuery, also all the samples that we collect from other places. We’re actually seeing lots and lots of instances of this kit versus other kits. I believe the last version was 1.2.3, they may have just recently updated it because they added a few exploits; and a lot of the exploits that they’ve been using have been targeting Java vulnerabilities, and I’ll get into that a little bit more.
Also, there was Microsoft XML vulnerability discovered in June; at the time it was 0-day that was actively exploited. Researchers we able to find copies of this page that were in the wild and actively targeting people. People were posting about this and the kit authors also saw this, and they took these pages and they adapted them and got them into their kit. So they were actually able to get it into BlackHole while it was still unpatched. Thankfully, there is now protection out there for it.
One of the biggest things that BlackHole does is JavaScript obfuscation. They constantly change and tweak it a little bit just to try to stay one step ahead. We’ve actually done a lot of running URLs that we find through our sandbox, and watching the results, watching the behavior of how it makes URL requests, which exploits you loaded. At the end of the day, it doesn’t do anything super-sophisticated, but they do enough sophistication to keep trying to stay one step ahead.
These are news stories from 2011 (see left-hand image). BlackHole was in the news a lot. In mid-May of 2011 they made a version free while they still kept the newer versions paid, so it was like ?”Here’s a sample; if you like this come back to us and buy the full version”. They also were able to compromise the United States Postal Service and redirect a lot of visitors there to versions of their kit. And they also did the same thing with MySQL.com. They are also doing lots of spam campaigns these days, trying to install various versions of SpyEye, ZeuS, Carberp using fake Facebook friend request.
This (see right-hand image) is kind of a timeline of a lot of events that happened in 2011. Some of them I’ve just talked about; earlier in the year there was an ad server network compromised, and that was one of the first big stories we saw about BlackHole. They also did a lot of SEO poisoning. They ended up releasing three different versions of their kit in 2011. There was also the mass WordPress compromise in November, targeting the WordPress plugin called TimThumb. That was a vulnerability where you could actually upload any kind of file and get it executed. There was a patch released for this in August, and a large number of people running WordPress were not updating this plugin, so there was a mass compromise campaign launched by people running BlackHole and they got hundreds of thousands of WordPress blogs compromised and redirecting to BlackHole.
I saw a paper last month from Trend Micro where they delve into the spam campaigns that BlackHole has been using, and I have been collecting quite a bit of information myself. The reason they’re using spam over trying to compromise a site is because it’s a lot easier. It’s easier to get a list of a million people and send out an email to them trying to get them to click on the link than trying to find a popular enough website that has a vulnerability you can exploit – SQL injection, cross-site scripting – to get your stuff in there to redirect them. The amount of spam that they are generating is significantly rising. A lot of these that I’ve seen have been fake delivery notices for UPS and FedEx, and I saw a lot of them around the holidays, so they’re definitely using contextual stuff like that: fake IRS notices around tax time in April for people from the U.S.; also, fake orders from Amazon or other places. So you go there, you see a link saying “Hey, click here to go see more info”, and it’s going to a BlackHole site and you end up getting owned.
This is a screenshot of the control panel that BlackHole uses (see left-hand image). I actually borrowed it from Xylitol’s blog, he also does a lot of work on exploit kits and he’s really awesome. Here on the upper right you see different exploit percentages, you’ll see visitor browsers and the percent of exploit rates. You see countries visiting, you see operating systems and just some general statistics that they show. What you’ll see with this versus Phoenix and some other kits is they definitely have tried to create a much nicer-looking feel than a lot of other kits in their control panel.
In this kit you’ll actually see (right-hand image) that the top vulnerability was Java/CVE-2011-3544 (Java Rhino), and there was a patch released late last year. This was about a month after it was patched. It has 83% success rate in the wild, which is crazy. Also, another interesting thing is that the most exploited operating system at that time was Windows 7. You look through all the others, and there’s 10% for a PDF vulnerability, then 3% – you know, extremely low. And this actually seemed to start the trend where they added another Java exploit in early 2012, about a month after a patch was released. Then they just did the same thing again.
So, I was trying to figure out why people aren’t patching it. Why is it being so successful? You know, I love Reddit; I was browsing the /r/funny/ stuff on Reddit – and, basically, the perfect image popped up (see left-hand pic). “What do we say to the Java update? Not today”. So, it’s just people ignoring, saying “Oh, there’s a Java update in the system tray? No, go away!” And so I saw that, I laughed, and then I facepalmed. I was just something that perfectly exemplified the problem that we see in the wild.
Now I’ll actually get a little bit more into how it works. Running all these things through our sandbox, we’ve looked a lot at URLs that it uses, redirects to where it loads its payloads. We actually found it’s quite predictable, at the moment at least. A lot of times it’s a PHP file; it’s normally showthread.php, main.php. It normally has one URL parameter, and a lot of times it’s actually ‘page=’, and then it’s, like, a 16-character hex string. So it’s something that’s very detectable, but it’s like I can look at a URL and I can say: “I’m pretty sure that’s BlackHole”, but then it’s also close enough to some normal URL, and you kind of get into that spot of “I can’t just stop someone from visiting that because it could be a legitimate page, and I would end up getting yelled at if I did that”. So, once that’s loaded and it ends up redirecting to its malware payload, a lot of times it’s a 1-letter PHP file – w.php is what I’ve observed a lot; t.php is also another common one.
So, it’s very predictable but it can easily block a lot of legitimate traffic. It’s like – you have ‘f’ and ‘e’ as URL parameters, the values are all within very small ranges – I can tell what you’re doing, but it ends up becoming very hard to only block that.
The JavaScript that BlackHole uses – there are obfuscation techniques (see left-hand image), they tweak them just a little bit, so every time you’re going through the obfuscation, it’s like I can catch everything you’re doing now, and then they tweak it just a little bit to where now you don’t catch it. They’ll use character separators; they’ll have a text blob in HTML element or parameter, sometimes they’ll actually just have a giant URL or integers. So they go through that, they pull this out, they’ll actually do a split to turn their text blob into an array of integers, if it’s not already, and they’ll run it through deobfuscation routine. It normally includes many other common obfuscation techniques like doing string from CharCodes, using square bracket in quoted value to execute a function, like ‘window[ “eval”]’, or sometimes they’ll break it up to e+v+al, or they’ll actually even assign one variable to half of it and then another to that plus the other half of it.
So it’s very common stuff that we see a lot, so then the deobfuscation routine, once it actually gets to the point where it’s handling this giant text blob, splits it and it’ll do a string from CharCode, and then it’ll add or subtract an integer and end up building up a giant string that is normally reassigned ‘eval’ in JavaScript. And that actually ends up being a malicious iFrame that redirects to their site, and so you end up getting browser and plugin detection, and launching and loading malware.
Here’s an actual sample (see right-hand image). On the left you see deobfuscated JavaScript, on the right you see the obfuscated JavaScript. You see in the left-hand part where it says: “Please wait page is loading” – that’s usually one of the indicators in deobfuscated JavaScript. It’s like you just visit a site that’s been affected by BlackHole, and you should probably get your computer scanned. In the bottom right-hand part, you actually see the text blob I was talking about, and this one is a little bit different, where they use ‘;.’ as the separator between their values. And up there you see a string from CharCode, they’re actually doing some math, so you’ll see a ‘floor’ value – they do a ‘floor’, they do a lot of other tricks. It’s like you can open up a web page and look at this and you can say: “That’s definitely malicious, but how do I stop that before it gets to what’s on the left where it’s transformed in the browser?” So you stay on your toes, keep on top of everything, and it ends up being a very difficult problem.
They also do a lot of PDF exploits (see right-hand image) but they use different obfuscation than they use in JavaScript. They do ASCII character replacement in PDFs and turn something like a into an ‘a’. But they still use either giant text blobs or arrays of @s. And then they’ll also have multiple character separators like ‘@@@’ sign, but they’ll actually do an ASCII character replaced for the first @ sign, leave the middle @ sign in there, and then do another ASCII character replaced on the last @ sign. So it ends up being very recognizable, but trying to figure out a way to efficiently detect it in an automated fashion becomes a difficult part. Once this gets through the deobfuscation routine, it ends up following very similar patterns that the HTML JavaScript does, it ends up having the same purpose.
All of their JavaScript shellcode (see left-hand image), once you deobfuscate it, you can easily find. They don’t make an attempt to hide it. But also, a lot of it exhibits the same behavior, it’s very easily detectable, you see in their ‘JMP / CALL’ patterns you see in shellcode. They try to do a little bit of obfuscation where you load it up and you don’t see anything that looks decent, like you can run strings on it and you won’t see any URLs. But they actually do a simple XOR at the beginning of their shellcode, and then you end up with a good assembly code that you can find a lot of strings in, you can find URLs, you can actually follow it, follow the path of execution – how it gains execution. The image at the bottom is actually one of the URLs we found after we deobfuscated this. You run the shellcode through something like Libmu, and it’s easily detected, so they’re definitely not on the forefront of evading anything like that.
Here (see right-hand image) is an example. The left side is deobfuscated and the right side is the obfuscated shellcode. In the right-hand part you can see it’s actually subtracting a negative number to get the number of bytes that it wants to patch, and that number of bytes ends up being positive. Right there it’s doing its XOR loop, and then that part on the right side is actually becoming what’s on the left, which ends up being the assembly code where it does a bunch of jumps before it starts executing.
And recently they implemented pseudo-random DNS generation algorithm (see left-hand image), and this makes it harder than something like recent examples of Flashback, but actually everything with Flashback uses the same DNS generation algorithm, connects to the same servers, whereas every instance of BlackHole has slightly different generation algorithms, it changes every twelve hours, and this makes it a lot more difficult to catch every kit. Before, it was like “Hey, I know. So, if you bulletproof-host this DNS name – I can block it”. Now it changes every twelve hours for thousands of installs. At the bottom you’ll actually see there’s a call to make frame, which then ends up generating a pseudo-random string. And this one is using DNSstuff.com which is free dynamic DNS service.
Then it does a random number generator based on the time, and if it’s less than 12 then it’s 0 otherwise it’s 1, so that’s actually where it’s using two cycles of the DNS name per day. Also, it gets a color out of the string, uses its pseudo-random number generator to grab tinker so that it ends up being a color-(10-number character).dnsstuff.com domain name at the end of it. They just recently added this, so they are definitely trying to add more things and keep their position as the most popular kit.
Phoenix Exploit Kit
The next kit I’m going to talk about is Phoenix. It’s been around since 2007, it’s pretty old, it’s up to version 3. They do mini and full versions. The difference between mini and full isn’t that they offer you more exploits, it’s more of just you can do multiple affiliates; they do things that I’ve seen other kits do: they track if you visited the page once, and if you visited the page one time – then they don’t actually launch the exploit again. When I was first playing around with these kits I ran into a problem where I visited a page for an exploit and then I tried to hit it again and wasn’t able to get the exploit, so I was like: what happened? It’s because: “Oh, we might have exploited you once already, so we don’t want to try to exploit you again; or we don’t want to serve the page up to you more than once to keep you from getting more information.” Also, because Phoenix is so old, it actually has quite a few exploits but they are fairly old exploits.
So, here you’ll see some of the statistics that Phoenix uses (see left-hand image). This is their advanced statistics page where they give you a lot of information about browsers and operating systems. On other pages you can see some exploits statistics and some more browser statistics. So, it’s not nearly as interesting or as nice to look at as BlackHole is.
But the way Phoenix does JavaScript obfuscation is they tend to use multiple ‘script’ tags followed by ‘textarea’ tag, followed by another ‘script’ tag. And in their ‘textarea’ tag they actually have a couple of variable initializations that they pull out and execute in one of the other ‘script’ tags. Even after you deobfuscate this code, it’s not that obvious what exactly it’s doing; like with BlackHole I saw a lot of references to things like ‘getShellcode’ or ‘heap spray’ – if you can actually figure out a way to deobfuscate it, you can say: “Oh yeah, that’s definitely malicious.” But Phoenix doesn’t quite follow the same patterns.
So, this is what some of their obfuscated JavaScript looks like (see left-hand image). At the top you’ll see the two ‘script’ tags together; it actually ends up being much longer and not terribly interesting, but it’s like one of those things where you look at this and you’re like: “That’s probably not going to do anything legitimate,” but with a lot of the minifying of JavaScript it ends up being much more difficult to not detect false positives related to this.
The PDF obfuscations that Phoenix uses (see right-hand image) resemble a lot of BlackHole’s JavaScript obfuscations; and, you know, Phoenix was first, so it’s likely that BlackHole definitely saw what they were doing at the time and decided to take it and improve upon it. So, they do the large array of integers, they run through deobfuscation routine to then launch an exploit. But the way they do deobfuscation is a little bit simpler than BlackHole, they’re not doing any kind of math. You can actually see that they index into an array that’s used to index into another array, and then they just loop over a hard-coded number of bytes. Then they do an ‘eval’ reassignment at the end. So it’s not terribly sophisticated, it’s kind of one of the things like “I can look at this, I can see it’s bad, but how do I block this without blocking other legitimate things?”
Other Exploit Toolkits
Now I’ll move on to some of the other exploit kits that have been coming out. In late 2011 – early 2012, it seems like a lot of people have witnessed how popular these kits are becoming, how successful they’ve been, and there’re lots and lots of new kits coming out. There have actually been quite a few coming out from China, I’m going to talk about one of them and talk about some of the characteristics that it exhibits and other kits from China exhibit. An interesting thing with that is a lot of the kits have been coming out from Eastern Europe and Russia. So, kits coming out from China are just kind of a new wrinkle on the game. They came out with a small number of exploits but they are actually targeting more recent vulnerabilities than the other established kits. We’re also seeing kits pop up and disappear, but overall it’s just there being a very large number of these things to keep up with. It’s kind of like a start-up where everyone has a great idea, a lot of people try to follow it, but then a lot of people fail, so they just go away and you never see them again.
So, Yang Pack (see left-hand image) was actually from China. It appeared in late 2011 – early 2012. It only had three exploits in it, but they’re actually targeting fairly recent vulnerabilities. It also had very low detection rates on VirusTotal. The other interesting thing about that is they’re not using JavaScript obfuscation, they’re not using PHP and MySQL or anything at the backend, it’s just static HTML file with everything hard-coded. And they still weren’t getting detected – the detection rates were less than 10% right after it came out. The author of Kahu Security actually has quite a few more blogs about other kits from China, and I reference those in the whitepaper as well.
The next kit I want to talk about is Sweet Orange (see right-hand image), and this was a kit that I have not yet witnessed in the wild, and I haven’t seen anyone else except for Dancho Danchev talk about it, and one post on Webroot. But I want to talk about it here because they’ve actually managed to keep their kit out of researchers’ hands and very hidden, so it’s kind of a very hard question of whether they are being successful with this kit or it’s just some sort of marketing fluff: “We’re not going to even show a demo of this kit to you at all, if you’re not an established member of the underground we don’t feel like we trust you at all.” They set a high price for buying the exploit kit – $2500, and renting it for $1400. And none of the researchers I’ve talked to have seen this in the wild, but then, again, we may easily have samples of it, we just haven’t been able to tie them to this kit.
So, this is one of the screenshots of the Sweet Orange (see left-hand image), and you see it’s very similar to Phoenix: they just throw out their numbers, they’re not trying to make it look nearly as nice as BlackHole. You see country statistics, browser statistics – you’ll actually see some browser version statistics as well.
The last kit I’m going to talk about is Nuclear Pack (see right-hand image), which is actually one that popped up and disappeared, and it didn’t reappear until this year. It only has 4 exploits with it, but the interesting thing about this one was they added an anti-honeyclient/webcrawling feature into it just to try to prevent people from collecting any information about their page, collecting their exploits. They actually use mouse moving as a sign of a human using the web browser. So, this feature is really to detect you kind of need more interactive things to do it.
This (see left-hand image) is actually their anti-crawling routine here, where they have a ‘document.onmousemove’ function assigned. They use the ‘xyzflag’ for various purposes, and you can also see some ASCII character replacement type stuff. Then, done at the very end, is once you get a mousemove then it will end up creating a JavaScript tag that will append to a ‘head’ HTML element, so their JavaScript gets loaded, the exploit gets launched, and they hope that they compromise you.
In conclusion, the exploit kits are getting more sophisticated in terms of adding newer exploits and more recent exploits and trying to do more evasions and obfuscations. One of the reasons they’re doing this is because it’s their business, and the guys who write these kits are trying to make money and they’re trying to protect their business model. They definitely want to figure out ways to keep making more money.
But they are not sophisticated in the sense of the – unfortunately I have to use this term – APT attacks that are trying to stay under the radar and silently exfiltrate data. These are the guys that are just trying to get past the first level of detection to infect a computer and add it to a botnet and then figure out ways to make money. So, detecting the ways that they are adding techniques and the ways that they are doing stuff takes a lot of work and takes constant work. And there are a lot of recent mitigations that web browsers are trying to add, like blacklisting plugins; and you also see things like Flash adding in, silent update features – Firefox has been looking to adding that in, Chrome does it. So they’re definitely combating these guys and trying to combat them in many ways. And it will be interesting, from my perspective, to see how the exploit authors react to these things, because they’re definitely going to react. But I don’t expect them to react with 0-days – they don’t need to use 0-days because what they are doing works, and it’s going to keep working as long as people won’t patch, or as long as we can’t make people patch.
I just want to give thanks to a lot of people, a couple of people work with – Marc Eisenbarth, Joanna Burkey and the rest of DVLabs people, they’ve definitely been great per support and ideas; and some ex-coworkers – Alen Puzic who actually turned me onto this stuff originally; and a lot of the researcher communities – you see them all up there.
So, thank you!
