This week Blackhole has been updated to version 1.2.3 and includes a new exploit for the Java CVE-2012-0507 vulnerability, which ESET calls Java/Exploit.CVE-2012-0507. Earlier this week information was published about the Blackhole update by French malware researcher Xylitol and last week Microsoft shared information about an interesting way of breaching the JRE (Java Runtime Environment) sandbox.

The first information about a working exploit for CVE-2012-0507 was released by the company Immunity with reference to the 7.03.2012 product update of Immunity CANVAS Modules. The first In-the-Wild detections were recognized during the week beginning on March 12, 2012. The CVE-2012-0507 vulnerability was remediated on February 15 as part of a critical patch update advisory. Today a public module for Metasploit Framework was released, working on a range of platforms: Windows, Linux, Solaris and OSX. The Metasploit module for exploitation of CVE-2012-0507 looks the same as the exploit version seen in the updated Blackhole version.

Java exploits are now a more effective way to install malicious programs: we have already published information about this in our recent posts. Exploit kit developers don’t include 0-days in their products, because that’s a really expensive way to proceed. But among 1-day exploits (exploits based on checking patched versions of software to identify what the vulnerabilities that have been patched actually are), Java vulnerabilities are the number one target. This is the most effective way for exploiting end-user systems and is sometimes effective across a variety of platforms.

This week we have tracked many incidents involving the infection of popular and legitimate Russian sites where iFrames redirect victims to the latest version of Blackhole. Here we look at one of these incidents in detail.

The first stage of execution is the construction of malicious iFrames with code to redirect to the exploit kit resource hxxp://

The iFrame is visible at the moment of redirection to the original webpage:

After this step is taken we can see the old processing page from the Blackhole exploit kit:

The malicious domain name and infected webpage look to all intents and purposes the same ( and The same infection method and the same redirection methods are used that we have already seen on the popular news resource In both cases modified versions of the Win32/TrojanDownloader.Carberp family were loaded onto the victim machines.

All the infection stages look like this in the traffic we captured:

You may already remember hearing news of the arrests of Carberp team members. This is a real win, but it’s just one big team using the Carberp bot that was arrested, and other cybercrime groups have evaded arrest so far. The Carberp developers also remain free and are still able to support active cybercrime groups. Carberp kits are not on sale to all and sundry, but are distributed only by trusted cybercrime groups.

To come back to the exploit detection Java/Exploit.CVE-2012-0507, this is a really interesting vulnerability in the AtomicReferenceArray class implementation, which wasn’t checking properly whether the array was of an appropriate Object[] type. A malicious Java applet could use this flaw to bypass Java sandbox restrictions in order to execute malicious code outside of sandbox.

The structure of objects in a Java/Exploit.CVE-2012-0507 sample looks like this:

  • The method init() from the class Ner in a malicious Java applet builds the object AtomicReferenceArray for the execution of malicious Java code outside the sandbox

  Deobfuscated and decompiled code from Java/Exploit.CVE-2012-0507

  • The next step of execution is to call the static method doWork() from the class Hal. By this method code is built of a class which executes outside the sandbox.

Deobfuscated and decompiled code from Java/Exploit.CVE-2012-0507

  • Code for dynamic execution outside the sandbox is encrypted: before building the object for execution there is a need to decrypt the string with Java code. The encryption method in use is a custom encoding algorithm based on simple permutations of bytes. After decryption, the code of the main method “DownloadAndExec” looks like this:

Deobfuscated and decompiled code from Java/Exploit.CVE-2012-0507

This code downloads a malicious executable file to %TEMP%vdsh89gyu<file_number>.exe and executes it: in the case we analysed, it was Win32/TrojanDownloader.Carberp.AH. In order to bypass detections by security software, the attackers changed the encryption algorithm and string obfuscation for the payload class executed outside the sandbox.

Java exploits continue last year’s trend towards finding more effective ways for malware to effect mass infection. Now the process of exploiting the Java platform is more stable and easier for attackers than continuing to exploit products sold by Adobe, whose vulnerability and patching process has become far more effective.

Aleksandr Matrosov
David Harley