The Websense® ThreatSeeker® Network has detected that a FOREX trading website was injected with a malicious Java applet, which could install malware on the affected systems of the site's users. FOREX is the foreign exchange market where international currencies are traded, and nowadays, it's used by millions of people around the world.

The targeted website is a popular FOREX website called "Trading Forex," located at hxxp://tradingforex.com. One of the questions that is raised when encountering such a compromise is whether some cybercriminal shift their focus from mainstream online money management systems of banks and stock exchanges to "easier wins" with online systems and services that are likely to be less mature from a security perspective. Another interesting fact is that the dropped backdoor at Trading Forex is written in Visual Basic.Net and requires the Microsoft's .NET framework to be successfully installed and operational on the victim's computer.

Websense customers are protected from these and other threats by  Websense ACE (Advanced Classification Engine).

At Websense Security Labs™ we are used to seeing this kind of injection, based on malicious Java applets trying to exploit  Java vulnerabilities, and we have blogged about them several times. In this case, however, investigating the malicious JAR file brought up some interesting details. The malicious code has been injected in the bottom of the page, as shown better here:

At this time the website hxxp://libertyresarve.info seems to be active,  however in the latest days we seen that sometimes was turned off although was still possible retrieve the content through the Google cache. We can also be sure that it has been used for typosquatting activities against the real Libertyreserve (the virtual currency organization) website as shown below:

The message in red which has appeared on that Web page is a clear attempt to convince users to load the malicious Java applet in some way. Below is the real content of Libertyreserve.com:

 At first glance, the JAR file seems to be written not to exploit Java vulnerabilities, but just to load a binary file hosted at "hxxp://www.libertyresarve.info":

Basically the Java code is just another Java loader which requires user interaction to successfully load the binary file "123.exe". One interesting point in the screenshot above is that we can also see in the MANIFEST-INF that the Java applet has been signed with a certificate. Trying to evaluate the certificate validity with the tool "jarsigner" (included in the Java SDK) shows that the certificate expired on 5 October 2011, but the applet was signed on 7 July 2011:

Due to the expiration of the certificate, it is possible to get the reasons why this JAR file has been considered as suspicious from the details of the usual Java warning message: 

By clicking on the details offered by the Java plugin alert, it is possible, as shown, to retrieve the issues related to this untrusted Java applet. This is a mitigation for the success of the attack, but is also true that due to the kind of users on this website, maybe that they are inclined to accept this malicious JAR due to a potentially  false sense of security and trustability.  Another interesting viewpoint has been found in the associated binary file.  The detection of this file still seems low, as reported here:

https://www.virustotal.com/file/66fdad1bc63eca7d8124d16c83322a6ca3b45546a70ddb0a9e122be6e9aaebfb/analysis/1353429475/

However, we tried submitting the executable file "123.exe"  to Websense ThreatScope™ with the following result:

From the full analysis reported here, it has been detected that the C&C called by the malware  is "hxxp://firestormm6t.no-ip.info" and seems to be associated with the IP address 46.166.129.110:

The file "123.exe" seems to be a ".NET" file probably written using C#. From deep analysis of the network traffic, it is possible to retrieve the exchanged packets between an infected system and the C2 (reported above) . It is easy to see that at least for the network activity detected, all the information is encoded using a plain BASE64 encoding. For example, the following screenshot reports the first request from the infected system to the C&C:

The screenshot above shows the exchange of data between the infected system (in blue) and the C&C (in red). In this case, decoding one of the BASE64 strings enables us to understand that all the BASE64 strings above are the strings reported in the open windows on the desktop of the infected systems. So for example:

Once decoded it became:

That is the caption of the Wireshark windows we used to get the traffic. We also detected other functions, such as the screenshots of the desktop taken by the malware. Below, it is possible to recognize the JPEG marker ("JFIF") and the keyword  "CAP" which is without doubt the short form for "CAPTURE:"

The binary file, as mentioned above, seems to be written using the .NET Framework using Visual Basic .NET . By opening  the the .NET disassembler "ILSpy" (an open source .NET disassembler powerful and robust enough to obtain not only the .net opcode but also the high-level language behind the .NET applications), it has been possible to detect the main functions with the list of the commands used to exchange information and data between the C&C and the impacted systems.  For example, the function "Init" is the first function called to collect the basic information from the systems on which the executable file is run:

The char "l" and the char "v" are the command init sent by the malware at the first execution, as discovered by the captured network traffic. It is also possible to detect other commands such as the check of the Service Pack (command "SP"):

Or for example the function which is able to detect the keys pressed by the user after pressing Enter (command "[ENTER]"):

There are also other features such as the detection of the CPU architecture (32 or 64 bit), functions to locate files by dates, and more. At first glance this malware seems very well written, and it uses an interesting obfuscation mechanism to retrieve and store the data required.

The Websense® ThreatSeeker® Network has detected that two Nepalese government websites, the National Information Technology Center (NITC) and the Office of the Prime Minister and Council Minister (nitc.gov.np and opmcm.gov.np respectively), have been compromised and injected with malicious code that tries to exploit the Java vulnerability CVE-2012-0507. The aim of this injection is to install, through successfully exploiting that Java weakness, a backdoor that is also dubbed "Zegost" on the systems of visitors to these websites.

This vulnerability (CVE-2012-0507) was also used in the Amnesty International UK website compromise and in the INSS website compromise that we reported a few months back. It's interesting to note that all those compromises had injected code that was taken from the Metasploit framework, served in clear form, and not obfuscated. Although the use of code from the Metasploit framework doesn't necessarily indicate a link between all the compromises, we found further common characteristics between the compromises of the Amnesty UK website and the Nepalese government website by analyzing the backdoor C&C points when we noticed that they connected to the same domain in China. 

The backdoor variant in this attack is known to have been used in other targeted attacks that were aimed at Uyghurs, Tibetans, and others in that area.

Websense customers are protected from these threats by ACE, our Advanced Classification Engine.

Technical Analysis

According to Cyberwarnews, in early 2012, the websites of Nepalese institutions, such as the police, suffered two other types of attacks mainly in the form of defacements and data leakage. But it's not just Nepal that has been affected. This region has recently seen a sequence of targeted attacks and APTs.

Below is the content of the Nepalese National Information Technology Center (NITC) Web page along with the injected code marked in red: 

The main page was injected with a Java JAR file loader which once rendered by the Web browser is executed and attempts to exploit the CVE-2012-0507 vulnerability. The name used for the Java class name ("msf.x.Exploit.class") and the content of the file confirmed that the code was taken from the Metasploit framework. If the exploit code in the JAR file has been successfully executed, the exploit shellcode downloads and runs the executable file named "tools.exe" on the impacted system (MD5: 3c7b7124f84cc4d29aa067eca6110e2f).

The ThreatSeeker Network was able to connect that same executable file dropped from nitc.gov.np (National Information Technology Center) to another Nepalese government website, opmcm.gov.np (Office of the Prime Minister and Council Minister website), as shown below:

The red, boxed URL is the website of the Office of the Prime Minister and Council Minister. We found out that this particular website was compromised this year, at least from May 9-15, to serve this same backdoor executable (MD5: 3c7b7124f84cc4d29aa067eca6110e2f):

The content that was injected between these dates at the website of the Office of the Prime Minister and Council Minister was identical to the code injected at the National Information Technology Center website, confirming that the same attack vector was used for both:

We detected that the dropped backdoor "tools.exe" (MD5: 3c7b7124f84cc4d29aa067eca6110e2f) is a variant "AD" of the backdoor Zegost. This backdoor toolkit or remote administration tool (RAT) has also been involved in other targeted attacks in Asia, according to an analysis by AlienVault in their research blog.

Thanks to the Websense ThreatScope® sandbox service, the C&C address was detected at "who.xhhow4.com," as shown in the picture below (for the complete sandbox report, click here). 

The domain "hhow4.com" was also used as a C&C point for the dropped backdoor served at the compromised Amnesty  UK website, where that variant specifically connected to the address at "shell.xhhow4.com" (for the complete sandbox report, click here).

Both C&Cs are hosted at IP address 184.22.171.216:

The domain "xhhow4.com" is hosted in China by a Web hosting company known as Hichina Zhicheng Technology Co., Ltd. The next image shows a Robtex DNS names graph analysis for that domain:

Once the backdoor is installed on the impacted system, it initiates connections from local TCP port 1320. The destination address is to the C&C  at "who.xhhow4.com" and uses remote TCP port 53  (usually the port reserved for the DNS Zone transfer). However, it's important to note that the traffic wasn't DNS traffic but the proprietary protocol used by the backdoor for remote communications. Below is the first connection sequence between the backdoor and the C&C:

By decoding the TCP stream, it is possible to recognize that custom encryption was used to exchange information with the C&C. The network traffic starts also with a keyword, "URATU," as shown below: 

Once executed, the binary creates a Mutex named "microsoft.com" reported below:

The backdoor also uses common features like other common backdoors, such as keylogging, and supports the ability to accept and run commands remotely. As in other cases, we can see that this backdoor isn't highly complex at all, but it's certainly no less effective than other complex malware once executed on the target systems. Another interesting aspect of this backdoor file is that it's signed with what appears to be an invalid\fake certificate issued to 360.cn (a Chinese ISP) by VeriSign, as shown in the properties box:

The certificate contains the following details:

Having malicious code signed with certificates is a trend that we’ve seen in other targeted attacks that can reduce the effectiveness of human and automatic countermeasures. 

In this blog, we covered the compromise of Nepalese government websites in what appears to be a chain of targeted attacks. We managed to connect those attacks to a previously reported attack that took place in a different country: the compromise of the Amnesty International UK website. This shows that cyber warfare is trending and kicking and that there's certainly an effort by international players to stay dominant and persistent in that realm.

Security Researchers: Gianluca Giuliani, Elad Sharf.

The Websense® ThreatSeeker® Network discovered on June 27, 2012, that one of the most popular travel websites in India, cleartrip.com, was compromised and served malicious code. The website was informed of this breach and no longer serves malicious code.

In this blog, we'd like to share our insights about this attack and focus on the tactics that we observed being used. We managed to spot this attack iteration before it became fully active, before malicious files were uploaded to the exploit kits that cleartrip.com was redirected to, and before all the malicious redirection nodes that cleartrip.com led to were active. 

The tactics that the cyber criminals used show what goes into making a legitimate website's infection less obvious and more difficult for security products to detect. These tactics included the following:  

• Targeting a website's local ad system and masquerading as legitimate ads 
• Manually intervening on a compromised website and preparing multiple domains to ensure redundancy  
• Obfuscating available malicious toolkit redirectors to circumvent detection
• Using advanced traffic direction system components and masquerading as a legitimate website to remain covert 
• Using exploit kits that serve Java-based exploits only

The next image summarizes the infection redirection chain leading to the exploit website as it started from cleartrip: 

In this section, we'll take a closer look at the tactics we listed above: 

Tactic 1: Targeting the local ad system and masquerading as part of the legitimate ad chain

The attackers seemed to focus on cleartrip.com's local ad system. Having that specific component compromised allowed them to serve malicious code through ads maintained by the website itself. The ad system on cleartrip is a third-party component plugin developed by Openx. Targeting third-party plugins is a very common tactic used to compromise legitimate websites. In this instance, it looks like the attackers gained control of the website's ad system since malicious code was restricted and served from that area only. Other cases of abuse of Openx components through exploitation and serving malicious content are documented throughout the Web. 

"Malvertizing" is another form of loading malicious code with advertisements. This is when third-party advertisers have their ads or their infrastructure compromised and then having their ads injected and loaded with malicious code. However, in the cleartrip attack, the local ads were served by cleartrip.com itself and not by a third party. By gaining unauthorized access to the Openx advertising component on the website, the attackers succeeded in sabotaging and injecting ads with malicious code. Malicious code loaded by ads is harder to detect because loaded ads usually reside at deeper path levels of the website and the malicious code blends well with the rest of the ad content. In contrast, most compromises we see in the labs tend to have injected code on the main page of a website or through pages that are loaded by the main page of a website.  

When we checked the IP address of the website of one of the malicious redirectors in this attack, euro-cool.in, we saw that it was hosted on IP address 85.17.122.245. A host report on that IP revealed more websites that have the same purpose and that are part of the attackers' malicious infrastructure (image 2). Some of the websites' names contain "openx," which leads us to surmise that the individual or group behind this attack is purposefully targeting websites that have the Openx plugin.

It's evident that the attackers were trying to blend in with legitimate ad traffic and appear to be a legitimate part of the ad chain. If you look at the detailed redirection flow in the set of images below and specifically at steps number 3 and 4, you'll clearly see keywords like "advertisement" and URL patterns that are used by legitimate ad providers, such as this on the malicious redirection stage: /banners.cgi?advert_id=1&banner_id=1&chid=341aa8fca26bcff7830499c1c5f8e359 

Tactic 1 summary: By targeting a local website's ad serving component and injecting code into legitimate ads served locally by a website, attackers can more easily evade detection and remain undiscovered.

Image 1: The Openx advertising plugin login page 

Image 2: Websites hosted on  85.17.122.245 (euro-cool.in)

Image 3: Detailed redirection flow of the attack

Tactic 2: Manually intervening on a compromised website and preparing multiple malicious domains to ensure redundancy  

The redirection chain we illustrated above led to an active exploit website, however the malware binaries that were downloaded after the successful exploitation were just stubs and didn't do anything malicious at all. It appears that the attackers didn't get a chance to upload their desired malicious files to the exploit website. In addition, the redirection chain illustrated above didn't use the illustrated websites exclusively. For example, in other locations on cleartrip.com, infected ads led to the malicious redirector euro-mary.in, which had the same purpose of euro-cool.in and was served in the same structure as euro-cool.in. But euro-mary.in was a "dead" redirect and didn't redirect to an exploit website.

hxxp://euro-mary.in/banners.cgi?advert_id=1&banner_id=1&chid=341aa8fca26bcff7830499c1c5f8e359

Admin Name:Roman Inozemtsev
Admin Organization:N/A
Admin Street1:R-N TBILISSKIY, UL. TRUDOVAYa D.18
Admin Street2:
Admin Street3:
Admin City:Tbilisskaya
Admin State/Province:Tbilisskiy r-n
Admin Postal Code:352361
Admin Country:RU
Admin Phone:+7.9060585279
Admin Phone Ext.:
Admin FAX:
Admin FAX Ext.:
Admin Email: rework11@mail.ru

From the tactics that we have observed so far, we believe that the attackers were intervening and setting up an infrastructure necessary for exploitation manually, and that it's being done with redundancy in mind. The attacker, in this case, was a bit careless and had one of the malicious redirectors, euro-cool.in, on its way to carrying out the exploitation. However, as we mentioned, although the exploits were active, the downloaded malware was a stub and not malicious. The image below reveals how the malware stubs were downloaded to the Windows temporary files folder after the exploit succeeded (image 4). 

Tactic 2 summary:  Manually intervening on a compromised website and preparing multiple domains to ensure redundancy are ways to prolong the duration of an attack by serving several exploitation chains.

Image 4: Dropped stub files by the exploit kit

Tactic 3: Obfuscating available malicious tool-kit redirectors to circumvent detection

The code that the attackers injected into legitimate ads on cleartrip.com was obfuscated (marked as 1 and marked in red on the exploitation chain image). Once the code was de-obfuscated, it unveiled a known redirector tool-kit code that is used and available in the underground for the same purposes of acting as a redirection point to exploit websites. The de-obfuscated code shows "decision-making" code, which means it includes code that detects the browser's version of the browsing user. In this case, if the user's browser is Internet Explorer or Firefox, only then will the user be sent to the next level of the exploitation chain. The code also assigns a cookie to the user's browser, so it can be identified at the next redirection levels. 

Obfuscating code is a very common tactic to hide injected malicious code on legitimate websites. It can effectively hinder efforts to detect malicious code since it applies the same concept as compressing and encrypting code for malicious files with packers and crypters in order to evade known malicious code detection. Scanning the obfuscated code of the redirector toolkit yields a lower number of results from antivirus vendors than scanning the clear text code of the redirector toolkit.

Tactic 3 summary: Another way to avoid detection is obfuscating available malicious tool-kit redirectors, such as by using reliable underground tool-kits that are reliable and proven to work while hiding their activity with layers of obfuscation.

Tactic 4: Using advanced Traffic Direction System (TDS) components and masquerading as legitimate websites to remain covert

The redirector on stage 2 of the attack (euro-cool.in and euro-mary.in) does not redirect directly to the exploit website, but to a Traffic Direction System on sciencedailyreview.com (marked as 3 in the exploitation chain). This system picks and chooses whether to exploit the computer. The purpose of a TDS is to scrutinize all the possible details that can be derived from the visiting user's IP address and the visiting user's browser. For example, this method is a handy way to avoid known IP ranges of security companies and IP ranges that reside in certain geographic locations that might not be of interest for the attacker to infect.

In this case, the TDS system resides on sciencedailyreview.com. This website mimics and contains some code from the legitimate website, www.sciencedaily.com, a website about science. The malicious TDS in our case has two faces: if the visiting browser fulfills certain conditions, then it will be redirected to the exploit website, but if it doesn't, then it will be redirected to a false and copied representation of a legitimate website with content taken from the legitimate website www.sciencedaily.com. This fake, malicious website is even indexed through Google and serves legitimate content if visited through Google searches and has more than 34,000 cached pages by Google (see Image 5). 

The malicious side of sciencedailyreview.com redirects to the exploit website, but first, it checks exactly what Java version is installed on the user's machine (marked as 3 in the exploitation chain). The Java version information is essential because then a decision can be made about whether the user's installed Java version is vulnerable and based on that decision, redirects to the exploit website and serves the right Java exploit to the user's machine.

 sciencedailyreview.com was registered on 2012-05-03, and its registration details are anonymous.

Tactic 4 summary:  Using advanced Traffic Direction System (TDS) components and masquerading as legitimate websites to remain covert help evade detection and prolong the lifespan of malicious websites.

Image 5: sciencedailyreview.com masquerades as a legitimate website and is cached by Google search engine

Tactic 5: Using exploit kits that serve Java-based exploits only

The exploit website (marked as 5 in the exploitation chain) serves Java-based exploits only. Java has been one of the most popular exploited components on user machines in the past year. In general, exploit kits target several components by holding several exploits for local installed components like the local browser, Adobe Acrobat Reader, Adobe Flash Player, Java, and more. Using several exploits can prove "noisy" and can result in detection of the exploit site. Tactically targeting one component for exploitation is more effective than targeting a few components since doing so is a more focused, and hence "quieter" approach that reduces the chances of the kit being discovered. Java is a good choice since usually exploits for that platform are reliable and can serve several platforms (e.g., the Java framework is also installed on Mac computers). In addition, Java is an interpreted programming language, which means, with relatively little effort, attackers can use it to obfuscate malicious code with cheap obfuscator kits that can be bought in the Black Hat underground market. 

In our case, the exploit kit on the exploit server appeared to be the "Neosploit" exploit pack, and the exploit that was served targeted the Java vulnerability described in CVE-2012-0507. This infamous exploit was used in the Flashback mass attacks and also used in the compromise of Amnesty International UK and the compromise of the Institute for National Security Studies (Israel).

Tactic 5 summary: Using exploit kits that serve Java-based exploits is an effective way to evade detection

Image 6: Neosploit exploit kit - this version serves only Java based exploits

In this blog, we took a look at several tactics that cyber criminals employ when they compromise a legitimate website for malicious purposes. Please let us know if you have any additional insights regarding this specific incident and also, please drop us a line if you'd like to share some insights about similar compromises that you have encountered.

Between May 8 and 9, 2012, the Websense® ThreatSeeker® Network detected that the Amnesty International United Kingdom website was compromised. The website was apparently injected with malicious code for these 2 days. During that time, website users risked having sensitive data stolen and perhaps infecting other users in their network. However, the website owners rectified this issue after we advised them about the injection. In early 2009, we discovered this same site was compromised, and in 2010, we reported another injection of an Amnesty International website, this time the Hong Kong site.

In the most recent case, we noticed that the exploit vector used was the same Java exploit (detailed in CVE-2012-0507) that has been used worldwide, and which has become somewhat infamous as the cause of the recent massive Mac OS X infection with Flashback. 

Websense customers are protected from these threats by ACE, our Advanced Classification Engine.

The following is a screen shot of the detected code injection:

a

                                                                  (click on the picture to enlarge)

In the screen shot, we can see the similarities between this injection and the INSS injection we reported last week. This clearly shows the use of the Metasploit framework and the precise name of the Java class used. In addition, the associated JAR file is a well-known vector exploit for the CVE-2012-0507, as shown below:

                                                                 (click on the picture to enlarge)

Once the exploit is successful, a file download is initiated for an executable from this URL: "hxxxp://www.48groupclub.org/images/uploads/image/sethc.exe" - MD5 : 3EC4DE9EF2E158473208842F4631236A

Further analysis shows that when the "sethc.exe" file is executed on the compromised system, it creates a new binary file in the Windows system directory: C:\Program Files\...... 

The ruse appears credible because the executable file has been signed by a "valid" certificate authority (CA), as shown below:

Through further research we learn that this certificate has been in use for a while and does not appear to have been revoked at the time of this latest exploit activity.

Analyzing this low AV detected binary file, we recognize that this is a variant of the well-known Remote Administration Tool Gh0st RAT, which is used mainly in targeted attacks to gain complete control of infected systems. With this control, the remote administrator has access to a user's files, email, passwords, and other sensitive personal information. Following is the initial network capture with Wireshark between a compromised system and the remote administration center, which reveals the header information of the traffic (pay particular attention to the starting keyword "gh0st"), confirming the use of Gh0st RAT:

                                                     (clieck on the picture to enlarge)

The Remote Administration Center commands to the compromised system originate from this address: shell.xhhow4.com. At the time of this writing, the address is still active.

[Update]

Websense® ThreatSeeker® Network detected that the Amnesty International Hong Kong sister website was also compromised to serve Gh0st RAT over the weekend, and the malicious codes are still live and active. Below are some of the pages infected redirecting to the exploits. Websense Security Labs will continue to monitor and update any new changes to this attack.

The Websense® ThreatSeeker® Network has detected that the Institute for National Security Studies (INSS) website in Israel was injected with malicious code. INSS is described in its website as an independent academic institute that studies key issues relating to Israel's national security and Middle East affairs.

While we can't determine that the infection of this website with exploit code is part of a targeted attack, one could deduce that visitors to this type of site are likely to have an interest in national security or are occupied in this field. The website appears to be injected with malicious code for over a week now. (Websense' ACE provided protection against the type of injected malicious code since early 2009)

One of the interesting facts about this infection is that it uses the same Java exploit vector (CVE-2012-0507) that managed to infect around 600,000 Mac users in a massive scatter attack dubbed Flashback a few weeks ago.

It's also worth noting that in the last few months, Israeli websites have been under continuous cyber-based threats and attacks. We don't think that this latest infection is part of an organized mass infection campaign but is probably just part of that trend. We continue to look for additional websites leading to the exploit website.

We have contacted the Webmaster of the website and notified them on the issue and the location of the injected code on the website, so far, we haven't heard back from them.

Websense customers are protected proactively from these threats by ACE, our Advanced Classification Engine.

Here's how this exploit works: if users visit the home page of the INSS website, the injected malicious Javascript code loads a Java exploiter. The injected code shown below consists of a "document.write" function call that uses decimal-encoded string characters to hide the exploit URL. Once decoded, the destination page may be retrieved. This means that users are silently redirected to the exploit page while their browser loads the website's home page:

The obfuscated injected content on the INSS home page looks like this:

Here's the decoded content:

And the content of the out.htm web page:

By merely looking at the code snippet above, we can see that the applet class's name suggests its intentions: "msf.x.Exploit.class." After further investigation, we detected that "test.jar" holds the exploit of the well-known Java vulnerability CVE-2012-0507. The inner workings of the "test.jar" file reveal that it contains a rather large compressed text file called "abc.txt" that is filled with a huge number of "a" characters. Once decompressed, the file size is about 104 MB. We think that this is a technique that attempts to evade automated malware analysis technologies, since some of those systems typically avoid downloading the contents of big files, because malware tends to be small in size.

From analyzing the contents of the Jar file, it was evident that it was generated by the Metasploit toolkit, which, as we mentioned, holds the vulnerability CVE-2012-0507:

The binary associated with the exploit, "svchost.exe" (MD5: 52aa791a524b61b129344f10b4712f52), is automatically installed on the victim's computer if followed by a successful Java exploiting attempt. "svchost.exe" is a variant of Poison Ivy, a remote administration tool (RAT) that can be used, as its name suggests, to control a computer remotely. The tool is robust and mature and may be used for legitimate purposes, but is also widely used for malicious purposes. Once Poison Ivy installs on the system it connects to a Dynamic DNS command and control address at: ids.ns01.us

The recent advent of flashback malware that includes exploit code for CVE-2012-0507 has been creating waves and quickly adopted by various other attackers as Websense® Security Labs™ has shown. This blog post detail some of the aspects of CVE-2012-0507 and how this exploit has been used in the wild.

The Java code first starts with the excerpt below:

The string "sobj" contains a stream of characters that trigger the vulnerability and force Java to render something which it usually wouldn't be allowed to. The string "8BCA ..." is obfuscated with an XOR key of 0x27 shown below:

After this string is de-obfuscated, it looks something like the image below:

We compared the exploit code used in the flashback campaign (above) with another instance in the wild that surfaced recently. Apparently, the attacker is using the exploit code provided by the metasploit framework.

The only difference between the flashback exploit code and the one used by metasploit is the bytecode array, where one is a signed byte array while the other is unsigned, as revealed below:

In our flashback sample, the string that triggers the vulnerability is "XOR-ed" with 0x27, while the string seen in the metasploit sample uses a signed byte array.

Lastly, the payload used by the flashback malware is a dropped Mach-O binary executable, while the metasploit exploit opens a listening TCP port shell pipe depending on what operating system the victim is on (This highlights the beauty of a design flaw as opposed to a vulnerability that corrupts memory). The code excerpt is shown below:

 Websense security solutions protect users from these kinds of exploits.