Last week, an email came into the main VRT email account, entitled "New Malicious Javascript." The note inside was from Mr. Brett C., a Sourcefire customer who'd stumbled across an interesting chunk of heavily obfuscated JavaScript that was the first page in a chain of events leading to a BlackHole exploit kit. While SIDs 21041, 21492, and 21646 alerted him to the presence of the exploit kit, this new chunk of JavaScript was of interest, because it looked nothing like BlackHole redirect pages we'd seen before.
Operating only on a single sample, it was immediately apparent that this new JavaScript was up to no good, based on the level of randomization:

Mr. C. had done an excellent bit of research, and had submitted the de-obfuscated version of the code as well. It was redirecting off to another site, which finally dropped the user off at the live BlackHole kit. Since it didn't look anything like the standard BlackHole redirection stuff we see - or really, like any of the other kits we're tracking that do redirection - even with this excellent pile of intelligence, it was tough to say what exactly we could base a signature on, as it was difficult to tell what parts of the kit would remain static, vs. which ones would be randomized on the next pass through.

Wanting to not leave a customer hanging when he'd provided such an interesting chunk of data, I wrote up a pair of rules around the fact that a pair of JavaScript calls in the page - to setTimeout() and addEventListener() - had mixed ASCII characters and hexadecimal escape sequences. Generally speaking, doing so on a randomized basis is one of the hallmarks of malicious code - if you've got nothing to hide, there's no reason to go to the effort to put some of your characters in randomly as hexadecimal. Sure, there are exceptions - non-US English character sets will contain hexadecimal sequences for special characters, and sometimes paranoid programmers will obfuscate their JavaScript so that you can't steal their work - but those tend to be exceptions to the rule, and obvious to differentiate from evil traffic. Mr. C. volunteered to deploy them on his system and report back to me on false positives vs. real hits, to see if the rules would be useful for general public release.
While the rules quickly produced a pile of false positives - it seems that Google, among others, like the hex-escape quote marks in those calls on a regular basis - some hits on malicious pages popped up as well. In fact, in one such case, SID 21845 - which looks for the TDS Sutra redirection software - triggered after my experimental rules had fired, on the way off to further nefarious content. In the process, Mr. C was able to collect a second sample of the kit in action - which helped me figure out which parts stayed static across multiple runs, and which parts were being obfuscated at runtime.

There appear to be a few artifacts left over by the kit that could probably be used for very speficic detection, and the VRT will be watching for other instances of this kit going forward to see if we can hit those artifacts specifically. In the meantime, however, my initial instinct about obfuscated JavaScript calls proved to be working well - especially if I required to hexadecimal escapes within the first argument to those calls, and required that one be not the first character in (i.e. an escaped quote). Deploying that update to the rule on Mr. C's systems and some of the VRT's other sensing networks, the new revision of the rules proved to have a few false positives left - but still had a high enough signal-to-noise ratio that many administrators would find them worth deploying.

As a result, we've added SIDs 23841 and 23842 to the VRT rule set, in our new INDICATOR-OBFUSCATION category. The rules are off by default in all policies, as they will produce some level of noise on any given network - but administrators who are willing to review events and look for obviously evil JavaScript are encouraged to turn them on and see what they find.

The best part about this entire process, however, came when we sat down to ensure ClamAV coverage for these new malicious files. Since we weren't sure what the kit here was, we ran the samples through VirusTotal, to see what other vendors might be calling it (since the world of antivirus naming is so unstandardized, we try to at least go with the community naming consensus where available). The first sample that was sent in was detected by precisely zero of forty-two antivirus vendors; the second sample, which we received yesterday, was detected by two vendors (Microsoft, as Trojan.JS/IframeRef.G, and ESET, as JS/Agent.NGK).

The newly-minted ClamAV signature which covers both samples is called JS.Obfus-218; however, the kit itself, for now at least, appears to be nameless. That said, if you recognize this kit, or just have a good idea for a cool name (whoever came up with "BlackHole" obviously had a mind for evil marketing genius), let us know - and we'll either start calling it by its proper name, or take advantage of being early enough in the detection game to name what appears to be a brand-new chunk of exploit kit code.