Observations on the recent Java 0-day exploits in the wild

Recently the Internet has been abuzz with news of an unpatched (0-day) exploit for the latest version of Java. The vulnerability is critical because it can exploit a fully patched version of Windows, Linux or Mac OS X. Also, it can do all this without users knowledge or consent. All that is needed is have Java 7 installed and a visit to a website that contains a malicious Java applet. A patch from Oracle that addresses this vulnerability may not be released until the 16th of October.

In the past week, Fox-IT detected attempts to exploit the Java vulnerability on a large scale. The perpetrators did not use the code that everyone is concentrating on. In this case some malicious JavaScript was first used to load the Java archive into the clients Java virtual machine. Subsequently, it was checked if the client was running Java 7, which is the version of Java that is vulnerable. If the system is vulnerable, it was attacked with custom exploit code. Once the jar is executed, a malicious exe is downloaded and then the computer is compromised. It is reassuring to know that even if someone attempts to compromise systems in a new way and uses a known methodology to do so, it can still be detected; as was the case here.

The executables that were dropped by the exploit code consisted of a new sample of the Hermes Trojan, and various versions of ZeuS including Citadel, Ice-IX, Gameover-ZeuS and other customized versions. Analysis of the Hermes sample, as well as the command and control servers that it was configured to connect to, has shown that the perpetrator of this attack was previously responsible for the large scale infections by Dorifel using a Citadel botnet, as described previously on our blog.

Interestingly enough, the exploit code that was used to exploit unsuspecting visitors appears to have been compiled on August 17th, which predates most known exploits for this vulnerability, even the one referenced in other blog posts related to a targeted attack using an exploit kit from East-Asian origin. The timeline makes it interesting, as it is even closer to the date that the VulnDisco Java 0-day was announced on the 10th of August. It could very well be that the vulnerability was circulating in the underground and some people picked it up along the line, or even that someone ripped it from VulnDisco.

The variety of malware that was distributed suggests this exploit kit is used as a service, which was recently discovered when large amounts of traffic were sent to it originating from compromised OpenX servers that are used for advertorial purposes. One of the compromised OpenX servers was amongst others used by OmroepWest.nl. Much more effort was put into this exploit to make sure that it would not be detected by Anti Virus products when compared to the other exploits in the wild. Additionally, the domains that were used by the exploit kit were changed frequently to avoid blacklisting and the IP addresses were often rotated as well. The domains were sub-domains of the popular DynDNS service: dyndns-at-home.com, dyndns-ip.com, dyndns.biz, dyndns.info, dyndns.org and dyndns.tv. The type and variety of malware that was distributed to various countries, suggests that it was likely that it was actively offered in the Russian-speaking underground community in the past weeks.

The unpatched Java vulnerability poses a severe security risk, as the software is widely used on systems in corporate, consumer and governmental environments. The vulnerability can be exploited to compromise Windows, Mac OS X and Linux systems. Given the amount of systems that can be affected, the readily available exploit code and the expectation that the vulnerability will not be patched for a significant amount of time, it is only a matter of time before this vulnerability will be exploited in even greater numbers. Also with the 0-day exploit having been added to the most popular exploit kit out there, Blackhole, we expect that the exposure of systems will become even higher as will the success rate of exploitation.

To protect oneself it is recommended to uninstall Java, unless it is used for tasks that are essential. In those cases, it is recommended to disable Java in the web browsers that are installed on the system. References to guides how to disable Java in some of the most used browsers: ChromeFirefoxSafari.

Update 31-8: Oracle has issued an update to Java 7 which addresses the vulnerability. More details here.

Update 3-9:  The earlier mentioned compilation date of the 17th of August was not related to the actual 0day exploit directly, we shared the samples with the industry and Moshe Basanchig from Trustwave responded that the earlier files found, only appeared to exploit CVE-2012-1723, and not CVE-2012-4681. All Jar files were exploiting CVE-2012-1723 and used the same obfuscator and had similarities due to the CVE-2012-1723 exploit and referenced ProtectionDomain, hence my confusion. Only the files from the 27th of August and onward exploited CVE-2012-4681 for 1.7 versions of Java and CVE-2012-1723 for other versions. Thanks to the excellent practical analysis of Immunity’s Esteban Guillardoy  it was easy to verify. Sorry for any confusion this might have caused.

It is interesting as the exploit kit appeared to gain traction on the 22nd of August and has distributed a large variety of malware which we expected to be related to the java 0day exploit, but it is not. While this exploit kit is definitely of a managed variant it also has some different properties. For example, another centrally managed exploit kit commonly referred to as Redkit, allows one to upload an executable and send traffic (visitors) to the exploit kit. The individual customers are differentiated using a numbered file which corresponds to the customer account and after successful exploitation the relevant customer malware is installed. Also the Bomba exploit kit (2010) and Incognito exploit kit (2011) are references of this type of service.

In this case however there is no distinguishing of customers to the exploit kit, all traffic has an identical landing page, and the only difference being made is the geo-location and relevant malware offered for that country is installed. This type of service is called a loads service where a customer pays for an X amount of infections for a certain country or list of countries. Another example of such a loads service was the Bredolab related loads service in 2010, which had huge volumes of traffic being converted into infected systems.

Still I am surprised by the amount of different malware that has been distributed by this service using dyndns domains, since it was only recently started, so it remains a mystery to me why it is suddenly so popular. The seemingly randomly generated domains which lead to this exploit kit are generated by a javascript domain generator which used a set of keywords and selects 4 keywords based on input parameters which are Hour, Day, Month and Year. The domain generator which was in use, is no longer used at this moment as the domains are not active.

The keywords used:
fox v junk five n r man out yes u qw solve but ea x im low zero go one too seven zeta do four key dry nine wide park hi a echo six two code

Generated domains:
date: 0:00 28-8-2012
domain: hxxp://foxwidecodea .dyndns-at-home .com
date: 1:00 28-8-2012
domain: hxxp://vparkfoxecho .dyndns-at-home .com
date: 2:00 28-8-2012
domain: hxxp://junkhivsix .dyndns-at-home .com
date: 3:00 28-8-2012
domain: hxxp://fiveajunktwo .dyndns-at-home .com
date: 4:00 28-8-2012
domain: hxxp://nechofivecode .dyndns-at-home .com
date: 5:00 28-8-2012
domain: hxxp://rsixnfox .dyndns-at-home .com
date: 6:00 28-8-2012
domain: hxxp://mantworv .dyndns-at-home .com
date: 7:00 28-8-2012
domain: hxxp://outcodemanjunk .dyndns-at-home .com
date: 8:00 28-8-2012
domain: hxxp://yesfoxoutfive .dyndns-at-home .com
date: 9:00 28-8-2012
domain: hxxp://uvyesn .dyndns-at-home .com …

The last domain in the list can be seen in the wireshark traffic log as seen in the blog, with a matching timestamp.

Barry Weymes, Michael Sandee et al.

XDocCrypt/Dorifel – Document encrypting and network spreading virus

Another day, another malware, and today it was an unknown Delphi application which encrypts your office documents on your non-root and non-CD/DVD drives and prepends it with a copy of itself, turning a document into an executable. Great, everybody loves these kinds of things as your entire IT dependant organization will grind to a complete halt if it hits your organization. So, how did people get infected by this? Well as it seems it was not a drive-by exploit on a large news site or some compromised advertisement server which caused this malware to run, but instead an already existing ZeuS variant named Citadel which downloaded and executed “a.exe”.

Should you worry about all those encrypted document files on your network…, what you should really worry about, is that there apparently was/is a trojan (ZeuS/Citadel) on your network that was doing active C&C communications and has been leaking all kinds of information from your organization for days, weeks or perhaps even months. And apparently none of your IT security defenses has removed it, has blocked it and neither has signaled you that there was something wrong on that system. If you were hit, you will likely start asking yourself some questions now… A properly configured IDS would have picked up the attack earlier and you would have been notified of the event.

Communication to the following IP addresses might indicate malicious behavior on your system:

So the big question is, why did it encrypt files… because it is not ransomware as it has no ransom note, the answer is, because they can. Interesting are also the references to the FGint library and RSA crypto, which was probably a failed experiment on behalf of the author. But RSA was not used for the encrypted documents, no it was something much more common in malicious software, actually the most common crypto apart from plain xor… RC4.

So, how would you recover such a file? Well the best method would be to use the RC4 key and use the standard RC4 implementation and decrypt the crypted document. You can find this from the separator “[+++scarface+++]” at offset 0x24a00 or 0x25000 depending on the infector version, and not forgetting to skip the last 7 0-bytes, otherwise Office will likely complain when opening the file. The RC4 key appears to be consistent in all versions: \x0d\x0a\x05\x0f\x59\x7b\x38\x5a\x5b\x36\x31\x69\x7e\x0d\x0d\x09

An alternative method for the less adventurous, or perhaps more adventurous users, if you actually run the file, it will decrypt and save a copy of the document to the same filename with “–.doc” appended to it and open it in the default application for that file type. In case nothing else works, or perhaps in case of modified crypto in newer versions and failing tools, this might be a quick way to recover an important file. Note: we do not advise this, but if you have to do this, please do it in a virtual machine without network connectivity. The actual function in the executable used for this is:

You can see in the function the separator of the file scarface, but encrypted with another common encryption function in malicious software, rot13. Other interesting strings are “SayHellotomyLittleFriend” a quote from the movie Scarface and “BreakingBad” a TV series.

The big question is of course, what is the purpose of this Trojan, one might suspect it is ransomware, but without a ransom note I guess that would be a no go. The fact that it infects shares means that it will spread to other systems that open the infected ‘documents’ on a share. Additionally HTTP based connection functionality suggests that the Trojan has additional download tasks and likely executes additional payloads on systems that have been infected. Given the Modus Operandi of this operation, it is likely that it downloads the Citadel Trojan and this entire attack was just to increase the size of the botnet through spreading of network shares. Currently however there appears to be no task defined and no additional malware is downloaded.

The interesting thing with this attack is that it appears to target NL pretty badly with over 2200 infections during the night, with the majority of the infections taking place in The Netherlands and only around 100 in Denmark and only few in other countries. The loader panel can be observed below:

All together it is a pretty interesting attack, which is obviously very visible due to the fallout with encrypted documents. And also due to the large amount of public sector organizations which were heavily affected by this attack.

Thanks to SurfRight for infected office document samples and the blog at http://www.damnthoseproblems.com/ for listing a lot of the information during the attack shared with the public.


SurfRight has provided a decryptor.

McAfee extra.dat file:  https://www.medusoft.eu/w32xdoccrypt-a/#.UCNwk03N-Ao

TrendMicro has detections for Dorifel / QUERVAR here.