Waledac Gets Cozy with Virut

Recently, we blogged about the file-infector virus known as W32.Virut and the botnet’s return to distributing new payloads. In the blog, we estimated that the Virut botnet currently consists of 308,000 unique Virut clients active in a single day. It was also noted that Virut had been observed distributing payloads with the functionality to send out email spam for advertisements and fraud as well as other malicious purposes.

During our further analysis of recent Virut samples, we observed the virus downloading a botnet variant named Waledac (also know Kelihos), which Symantec detects as W32.Waledac.D. The Waledac family is a threat that has been monitored by Symantec for many years and was featured in numerous blogs as well as a white paper. In the past, the Waledac botnet has also been subject to takedown efforts from the security community to curtail its operations.  On each occasion the miscreants behind the botnet were able to recover from these disruptions and continue their operations, distributing spam and performing other malicious functions.

Symantec telemetry data for the past month (Figure 1) shows that we have seen the number of computers infected with W32.Waledac.D continue to increase, with the United States currently having the largest concentration of infections.

Figure 1. Waledac.D global detections, based on recent telemetry

Once the computer has been compromised, it sends spam emails through servers from a list that it receives from the command servers. During our analysis in a controlled environment, we observed a compromised computer sending approximately 2,000 emails per hour. Conservatively, if a quarter of the estimated 308,000 computers infected with W32.Virut download W32.Waledac.D, then potentially billions of spam emails can be sent from these computers. The following table contains some basic calculations on the estimated volume of emails from this campaign with totals ranging from 1.2 billion to 3.6 billion spam emails per day.

Table 1. Estimated volume of emails sent from this campaign

The emails generated consisted of one of sixteen unique subject lines and one of thirteen unique email message bodies.

The following image (Figure 2) contains some sample screenshots generated from the spam emails in this campaign. Some of the emails lead to a Canadian online pharmacy spam and others lead to fake performance-enhancing drugs.

Figure 2. Screenshots of spam emails from the W32.Waledac.D campaign

The coexistence of Virut and Waledac on a single computer is further example of malware groups using affiliate programs to spread their threats, and that threats can be linked and coexist on an already compromised computer.

From our recent analysis of one particular compromised computer, the volume of spam that can be sent from each bot is quite significant and the combination of multiple compromised computers could potentially lead to billions of spam messages being sent out by W32.Waledac.D per day. Symantec Security Response will continue to monitor these threats and to update and add detections as we encounter new variants. To aid in protection against botnet infection, Symantec recommends that you employ the latest Symantec technologies.

Java Zero-Day Vulnerability Pushes Out Crimeware

This blog was updated on January 14. See the end of the file.

A new Java zero-day vulnerability is spreading malicious files to infect unprotected users. The threat is dangerous: Just browsing a malicious page or clicking a malicious link in spam is enough to cause an infection when combined with a vulnerable Java version.

Because most browsers enable Java by default, this vulnerability can be used by attackers to easily spread malwares using various exploit kits available in the market.

Exploit Analysis

The vulnerability is triggered by abusing restricted package permissions, which makes it possible for untrusted code to get access to classes that are part of restricted packages. Hence this can allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system.

This vulnerability in Java is very similar in characteristics to Exploit CVE2012-4681, though not completely similar to it.

Generally, the Java Virtual Machine first checks the privilege/permission of the class file or object before allowing it to execute in the Java applet sandbox environment. Any applet that does not have the required credentials will not execute. The goal of attackers is to exploit this vulnerability in order to escalate privileges, which enable the Java applet code to run outside the sandbox.

Figure 1: A typical vulnerability flow for this Java zero-day attack.

As shown in the preceding image, the victim first visits a compromised website link, which in turn loads the malicious Java applet in the vulnerable Java environment and executes the downloaded malicious payload on the compromised user system.


Figure 2: The main exploit code.

The preceding image shows how the attack works. It exploits the vulnerability using “MBeanInstantiator,” which allows the loading of a restricted class by exploiting the “findClass” method of the “com.sun.jmx.mbeanserver.MBeanInstantiator” class. By doing this, we can retrieve the class references of any package.

Steps in exploiting the vulnerability:

  1. First the call to the vulnerable “com.sun.jmx.mbeanserver.MBeanInstantiator.findClass” is made
  2. This will then call the “LoadClass” and “Class.forName,” which allow us to load any package in any classes available
  3. However, the “MBeanInstantiator” constructor is a private member. First, it has to get a reference to an instance of this object so that it can be used to load a class to be used later.
  4. This is achieved by calling a public static method, which in turn returns the “com.sun.jmx.mbeanserver.JmxMBeanServer” instance.
  5. The “JmxMBeanServer” class has a public method called “getMBeanInstantiator” [Figure 3], which returns the “MBeanInstantiator” instance. Using this we can find any class that we require using the “findClass” method.
  6. Then, the attack uses the new reflection API to obtain and call MethodHandle objects [Figure 4].
  7. This MethodHandle point to methods and constructors of restricted classes that were retrieved earlier, as mentioned above. This is achieved by the “invokeWithArguments” method call of java.lang.invoke.

Figure 3: A JmxMBeanServer code snippet.

Figure 4:  The attack uses the new reflection API.

Affected Java Versions

This exploit targets the vulnerability in Java Version 7 Update 10 and earlier.

An initial threat vector may be hosted on a compromised website in the form of an applet that contains code to exploit this vulnerability. The intent of the exploit is to surreptitiously download and execute additional malware on the infected system. An indication of this may be the presence of unusual traffic to unknown domains.

Exploit Kit Seizes the Opportunity

In our analysis, we have seen this vulnerability use various exploit kits, including Blackhole, Red Kit, Cool, Nuclear, and Sakura. These exploit kits appear to push out PWS-Zbot, ransomware, and ZeroAccess as payloads.

McAfee products detect this malware in our latest DATs as Exploit CVE2013-0422.


Because this is a zero-day attack there is no patch yet for the vulnerability. Hence our recommendation is to completely disable Java until the patch for this vulnerability is released.

If you cannot disable Java, you can take any of the following steps:

  • In the Java Control panel under the Security tab, set the security level to “Very High.” By doing this, unsigned (sandboxed) apps and local applets will not run.
  • Keep your McAfee antimalware definitions updated. We detect this attack as Exploit CVE2013-0422 as well as the payloads it downloads.

Meanwhile, we will continue to monitor this threat closely for new malware payloads and update that information here.

Update, January 14

Oracle has released patch for this vulnerability that is available here. Java users should update their software immediately.

CERT Releases Oracle Java 7 Security Advisory

The CERT Program has released Vulnerability Note VU#625617 to address a vulnerability in Oracle Java Runtime Environment (JRE) 7 and earlier that is currently being exploited in the wild. This vulnerability may allow an attacker to execute arbitrary code on vulnerable systems.

US-CERT encourages users and administrators to review CERT Vulnerability Note VU#625617 and US-CERT Alert TA13-010A. Due to the number and severity of this and prior Java vulnerabilities, it is recommended that Java be disabled temporarily in web browsers as described in the "Solution" section of the US-CERT Alert and in the Oracle Technical Note "Setting the Security Level of the Java Client."

This product is provided subject to this Notification and this Privacy & Use policy.