Expanding Black Holes
The big malware story for me over the last month is probably the surge in exploit kit sites hosting the “Blackhole” kit. (BTW, nice write-up last month on the kit on Imperva’s blog.) Bad Guys like exploit kits because they are a convenient way to leverage the work of multiple specialists — it’s nice to let somebody else do the challenging technical work of figuring out the discovery and “weaponization” of multiple vulnerabilities, and to be able to attack multiple vulnerabilities at once. Good Guys, on the other hand, also like exploit kits — it’s a lot easier to recognize attacks that are being used by multiple sources, and multiple attacks from one site mean multiple chances to identify an exkit host…
Initially, we auto-blocked a lot of Blackhole sites that were being used by one of the large malnets we track, but there were also plenty of smaller operations using Blackhole as well. They were popping up in small waves as new servers came on line, at a fairly steady rate. The pace kept up through the end of December, followed by a bit of a lull around the weekend of New Year’s Day — I guess even the Bad Guys take some time off now and then — before the activity picked up again this week. In fact, keeping an eye on our logs for new Blackhole sites and networks gave me something to do in spare moments during the holidays. (It’s what I do instead of video games these days.)
Here are some examples and notes I collected during the on-going campaign…
Some of the attacks used spam e-mails to entice victims to the Blackhole sites. Here are a couple of examples from my honeypots back in December.
Example #1 — fake Facebook e-mail:
Example #2 — fake-photo e-mail:
The links in the spams typically led to small pages on hacked sites, or other temporary locations, which contained an iFrame linking to the exkit site. Here’s a sample of what the mini-pages’ HTML looked like:
Note that both the Title (“You are redirecting…”) and the visible page content (“Wait please…!”) were attempts to get the victim to wait patiently while the attack site (cgredret.ru in this example, cfredret.ru in the first one) ran its script.
The main script is a large, complex routine that seeks to build a version-inventory of the OS, the browser, and common add-ons like Acrobat, Flash, and Java — and then serves exploit attacks against them. It undergoes regular modification to its obfuscation, as well as occasional upgrades to its functionality. Here’s an example of an obfuscation technique from a recent sample I grabbed this week:
Note that the first and third highlights show how the script breaks up the critical “fromCharCode” function name, in the variable “g”, so that script-checkers looking for “fromCharCode()” calls won’t see it.
The second and fourth highlights show a simpler attempt at camouflage, for the “eval” function.
The actual attack script is contained in the long string assigned to variable “a”. It’s over 90K long, and actually concludes (off-screen) with a call to the “split” function, using the “&” char as the separator. This breaks the string into an array of values for fromCharCode() to use in reconstructing the payload — into variable “c” — which is then fed to the disguised eval() call in the last step.
This particular example of the script includes an interesting defensive tactic: a section of HTML that it displays as a second layer of camouflage. This is what the victim sees:
Again, the point being to give you something to look at while the script is busy probing your system for unpatched vulnerabilities it can exploit to infect you.
This example came from alvaroheinous.com, which was one of a cluster of domains (ospreyshurtful.com, timberslowest.com, foundeditalian.com, trevorlegacy.com) on just one of the exploit kit servers. The exkits were generally hosted on oddly-named subdomains (e.g., “es1pnox.”).
Well, that’s enough for now. Time to head back for another sweep through the logs to see if any more have come on line!
Leave a reply