Archive for the ‘exploits’ Category

An analysis of Dorkbot’s infection vectors (part 2)

November 21st, 2012 No comments

In part 1 of this series, we talked about Dorkbot and its spreading mechanisms that required user interaction. In this post, we’ll talk about how Dorkbot spreads automatically, via drive-by downloads and Autorun files.

Spreading vectors not requiring user interaction: Drive-by downloads and Autorun files

Dorkbot can also spread automatically, without user interaction. We recently encountered a malicious Java applet that exploits the vulnerability described in CVE-2012-4681 to distribute the Dorkbot worm. We detect the applet as Exploit:Java/CVE-2012-4681.HD. Let’s take a closer look at how this exploit works.

Java applets that are not digitally signed are considered untrusted. They are executed with limited permissions by the Java Runtime Environment. Before it can download and execute arbitrary files, Exploit:Java/CVE-2012-4681.HD has to disable the security manager, which defines the security policy of the applet. The security manager can be disabled with a call to System.setSecurityManager(null), but applets are restricted from calling this method directly.

The exploit relies on vulnerabilities in the implementation of the following two methods:

  • Method com.sun.beans.finder.ClassFinder.findClass(String,ClassLoader)
  • Method com.sun.beans.finder.MethodFinder.findAccessibleMethod(Class,String,Class[])

We decompiled the method ClassFinder.findClass to determine why it was vulnerable. As shown in Figure 8, ClassFinder.findClass calls the method Class.forName in its internal implementation. The method Class.forName in turn only looks at the immediate caller to perform security checks. As you can see, the vulnerability lies in the way Class.forName is used, and not in the method Class.forName itself.

The fix was to perform an additional package access check at the beginning of method ClassFinder.findClass, a check that fails if an applet attempts to access a restricted Java class (Figure 8).

Figure 8: The vulnerability in com.sun.beans.finder.ClassFinder.findClass(String,ClassLoader)

Another issue, this time in the implementation of the method sun.awt.SunToolkit.getField(Class,String), allows one to access private members of Java classes. The method SunToolkit.getField would not be accessible by default to user code, but the exploit calls it with the help of a java.beans.Expression object. java.beans.Expression.execute() is also vulnerable because it relies on the two vulnerable methods described above.

Exploit:Java/CVE-2012-4681.HD calls SunToolkit.getField to modify a private member of a java.beans.Statement object and set the access control context to “all permissions”. The class Statement can be used to invoke methods from arbitrary classes with modified access control context value. The exploit relies on a Statement object with modified access control context to invoke the privileged method System.setSecurityManager. After this, it has the permission to download additional malware (Figure 9).

Figure 9: Execution flow of Exploit:Java/CVE-2012-4681.HD

As is typical for Java exploits nowadays, the code of Exploit:Java/CVE-2012-4681.HD is heavily obfuscated to try to bypass AV detection. Figure 10 shows how the exploit retrieves the private field “acc” of the java.beans.Statement class, a field that defines the access control context.

Figure 10: Obfuscated code in Exploit:Java/CVE-2012-4681.HD

Exploits for CVE-2012-4681 are guaranteed to work if the Java Runtime Environment is vulnerable (unlike exploits for memory corruptions, for instance). They are also platform independent (so they can also infect *nix and Mac users) and target a huge base of Java installations.

Unsurprisingly, as shown in Figure 11, our telemetry indicates that exploits for CVE-2012-4681 have been widely used to distribute malware since the vulnerability was first made public in late August 2012. A security update to resolve it was released around the same time.

Figure 11: Infections attempts with CVE-2012-4681 Java exploits reported from September 15th to October 17th, 2012

To avoid getting infected through drive-by downloads, make sure your software is up to date – for Java specifically, we talked about that in a previous post.

Worm:Win32/Dorkbot can also infect removable drives, by creating an autorun.inf file that points to a copy of the worm. If you have Autorun enabled in your computer, Dorkbot automatically runs whenever the removable drive is accessed. Fortunately, this distribution method is not very effective anymore as explained in a previous blog post. Please keep your Windows up-to-date to deal with this infection vector.


As we previously mentioned, malware these days use a variety of ways to infect computers and Dorkbot is no exception. And its access to a C&C server allows for a certain level of dynamic behavior. Because of this, we advise users to be more vigilant against all the different channels that Dorkbot uses.

And finally, always make sure your definitions are up-to-date for your antivirus solution. If you don’t have one and you’re running Windows XP, Vista, or 7, you can download and install Microsoft Security Essentials for free. If you’re using Windows 8, make sure your antivirus program is enabled and running properly.

The following are the SHA1s of the samples that we’ve analyzed for this blog post:

  • Exploit:Java/CVE-2012-4681.HD – f624121d44b87369ba9ffa975db64fbb7bc395b3
  • Worm:Win32/Dorkbot spreading component – 11a2ddb73af46060802537dec0f8799e2a0dc13f
  • Worm:Win32/Dorkbot.A – 4176f4193b1ef64569bf0ab220113cce6074df4e
  • Worm:Win32/Dorkbot.I – 37c09e044ebe57eb66aa6c72cb039140b3b985f1

Horea Coroiu, MMPC Munich

A technical analysis of Adobe Flash Player CVE-2012-0779 Vulnerability

May 24th, 2012 No comments

Recently, we’ve seen a few attacks in the wild targeting a patched Adobe Flash Player vulnerability. The vulnerability related to this malware was addressed with a recent patch released by Adobe on May 4th. On the Windows platform, Flash Player and earlier is vulnerable. If you’re using vulnerable version, you need to update your Flash Player now to be protected against these attacks. We had a chance to analyze how the malware (sha1: e32d0545f85ef13ca0d8e24b76a447558614716c) works and here are the interesting details we found during the investigation.

The following diagram shows the overview of the attack flow. The attack is initiated by sending a malicious document that contains a SWF download trigger and a malicious binary. The document doesn’t contain any malicious SWF payload at all.

Figure 1 Overview of the attack

Here is the detailed process that describes how the infection occurs when the victim opens the malicious document:

1) When the user opens the malicious document, the SWF download trigger part of the document downloads external content for rendering. This is specifically crafted to download malicious SWF content from malicious server 1. The embedding feature is not malicious itself, but the downloaded SWF is malicious and abuses the vulnerability in the Adobe Flash Player plugin.

2) The malicious SWF content is downloaded to the user’s application and is rendered. The malicious SWF is a wrapper with the actual payload encoded inside it and is loaded dynamically. We call this dynamically loaded content layer 2 SWF. The layer 2 SWF is loaded and spreads heap spraying code on the target application’s memory space.

3) The vulnerability trigger part of the layer 2 SWF contacts the designated malicious server to retrieve malicious data. This data causes the vulnerability to manifest.

4) The heap spray code loaded by layer 2 SWF is executed when the vulnerability is triggered.

5) The shellcode inside this layer 2 SWF decrypts a PE file from the malicious document. First of all, it enumerates all the opened handles to find the original malicious document – if the enumerated file contains an 8 byte marker at a certain offset then it is found. Then it decrypts the PE file from 0x10 bytes after the found marker. Each byte is XORed with a hard coded key while skipping byte zero and the byte with the same value as” key”. After decryption, the PE file (SHA1: 27c8bdacd4023858a810bec917381c6a7512715e) is detected as TrojanDropper:Win32/Glacid.A.

Compared to other attacks in the past, this attack is a little bit more complicated as different elements work together to achieve the whole attack. Each modularized component is designed to be configurable.

For example, when the original malicious SWF is downloaded from malicious server 1, the original malicious document is crafted to pass HTTP request parameters which will be used inside the malicious SWF file. The following packet capture shows one of the example requests we obtained. We can see that the request is using the “info” and “infosize” HTTP parameters. These parameters are later used in layer 2 SWF.

Figure 2 Malicious SWF Download Request

Here is the layer 2 SWF code which uses one of the dynamically passed parameters. The data dynamically passed is converted to binary form and is decompressed. The decompressed data is connection information about malicious server 2 which serves malicious data.

Figure 3 Parameter Usage Inside Layer2 SWF

As we saw from the overview diagram, layer 2 is loaded dynamically from the malicious SWF. The following code from the malicious SWF file shows how the layer 2 SWF file is loaded. The “loadBytes” method from “flash.display.Loader” class is called to load layer 2 SWF dynamically. This is a very typical way of loading malicious layer 2 SWF as seen in recent SWF malware.

Figure 4 Dynamic Loading Of Layer2 SWF Using loadBytes

One notable thing with the layer 2 SWF file is that it is using the”Shared Object” feature from Adobe Flash Player. This is the mechanism to save persistent data on a user’s machine which can be shared through sessions. When the same SWF file is loaded later, it can retrieve previously saved data from this “Shared Object”. By using this “Shared Object” feature, the malware avoids multiple exploitation attempts by checking the existence of the data and not performing the exploitation when it is found.

Figure 5 Usage Of Shared Object To Prevent Multiple Exploitation

As usually seen from malware abusing Adobe Flash Player, this malware is also using a heap spray technique to achieve shellcode execution. The following code part shows how the heap spray is happening. During this heap spray phase, you can observe that the application’s memory usage spikes.

Figure 6 Heap Spraying

The following picture shows what the shellcode sprayed on the memory looks like. When the exploitation is successful, the control flow is passed to one of these sprayed shellcodes in the memory.

Figure 7 Sprayed Shellcode On the Memory

The overall attack requires multiple modules to work together. We don’t see the attack as widespread yet. The vulnerability is not about the carrier that triggers the downloading of the SWF, but more of the Adobe Flash Player’s vulnerability. So, if you update your Adobe Flash Player, you can prevent the attack from affecting you.

Related detection name and SHA1 for the SWF exploits:

4d12200ede6cf44660399ca43c92fc87295b31cd detected as Exploit:SWF/CVE-2012-0779.A

53FE2CE5920CA0963638A68338433AD85F55BD0D detected as Exploit:SWF/CVE-2012-0779.B

c485712675509c233f70c64b84969b41164fab48 detected as Exploit:SWF/CVE-2012-0779.D

— Jeong Wook Oh & Chun Feng

Categories: Adobe, CVE-2012-0779, exploits Tags:

An interesting case of Mac OSX malware

April 30th, 2012 No comments

In June 2009, Microsoft issued security update MS09-027, which fixed a remote code execution vulnerability in the Mac version of Microsoft Office. Despite the availability of the bulletin (and the passage of time), not every machine is up to date yet – which is how nearly three years later, malware has emerged that exploits the issue on machines running Office on Mac OS X. Fortunately, our data indicates that this malware is not widespread, but during our investigation we found a few interesting facts we’d like to share with you.

For our investigation, we used a malware sample (SHA1: 445959611bc2480357057664bb597c803a349386) that is detected as Exploit:MacOS_X/MS09-027.A.

Overall execution flow

Figure 1 – Overall Execution Flow

Firstly, the vulnerability is a stack-based buffer overflow – the attack code could corrupt variables and return addresses located on the stack. As we analyzed the malware, we found that the malware author managed to corrupt a local variable and used that corrupted variable to deploy ‘stage 1’ shellcode to a designated area. This corrupted variable is later used for a target address and is where the stage 1 shellcode is copied. The corrupted return address points to this target address as well.

This target address is important, as, with Snow Leopard, we could confirm that it was used to exploit a specific location on the heap that is writable and also executable. The point is, that with Lion, that specific memory address can’t be written, so the exploit fails.

We can assume that this malware itself is targeting only Snow Leopard or lower versions of Mac OSX. That means the attacker had knowledge about the target environment beforehand. That includes the target operating system, application patch levels, etc.

Stage 1 shellcode

Figure 2 Stage 1 Shellcode

This stage 1 shellcode leads to stage 2 shellcode, which is located in memory. The stage 2 shellcode is actually where the infection of the system occurs. The stage 2 shellcode creates three files:

  • /tmp/launch-hs
  • /tmp/launch-hse
  • /tmp/file.doc

 File creation by stage 2 shellcode

Figure 3 File Creation by Stage 2 Shellcode

As you can see from the above picture, the exploit attack code uses typical Unix style shellcode to run system calls. So far, this is nothing new.

Later in the shellcode, the file “/tmp/launch-hs” is executed by a system call to “execve” to execute commands. The contents of “/tmp/launch-hs” should be a shell script or executable.

Figure 4 Execution of /tmp/launch-hs script file

We looked into the the contents of the “/tmp/launch-hs“, and it appears like following:

Contents of "/tmp/launch-hs" script

Figure 5 /tmp/launch-hs script contents

It is just a tiny shell script that runs “/tmp/launch-hs” and and opens “/tmp/file.doc“. The file “/tmp/launch-hse” should be the main binary that contains all the malicious code. Also “/tmp/file.doc” is a fake document file that will be displayed to the user to deceive the user from seeing any abnormalities or malicious symptoms.

The main payload file is “/tmp/launch-hse” – it is a Mach-O format, or standard executable format, for Mac OSX. This binary a command and control (C&C) agent that communicates with a C&C server (master) to perform unauthorized actions that are similar to other C&C bot clients. The function names give clues that might indicate that this binary is connecting to a C&C server, parses command from it and performs file retrieval or creates process.

Peek into the function names gives you an idea

Figure 6 Peek into the function names gives you an idea.

The main difference about this malware is that it is written for Mac OSX. For example, if you look into a “RunFile” function, which runs a command on the infected machine, you can see that it’s a Mac OSX version of backdoor. Basically it runs a command supplied from the C&C server.

RunFile function

Figure 7 RunFile function

No operating system that exists outside a laboratory is entirely immune to malware. As different operating systems continue to gain in popularity they attract more attention from would-be attackers – especially since, as we see in the example analysis above, the techniques and understanding needed to do so may be much the same as those used against other platforms. And even though an operating system may include many risk-reducing mitigation technologies, any machine’s defenses against vulnerabilities are directly related to how current its security updates for applications are kept.

If you’re using Microsoft Office 2004 for Mac, Microsoft Office 2008 for Mac or Open XML File Format Converter for Mac, be sure to update using the latest product updates. For this specific vulnerability, you can visit the Microsoft Security Bulletin MS09-027 page and download the update.

Jeong Wook (Matt) Oh


Categories: exploits, MS09-027, OSX Tags:

A tangled web…

April 27th, 2012 No comments

The moment of infection, and the circumstances that lead to the introduction of malware to a system, are often not obvious. This short case study examines our observations and investigations into a particular example that illustrates a fairly typical method of compromise that is played out countless times each day​ all over the web.

A couple of days ago, our attention was drawn to a website that appeared to use the Microsoft brand. We received reports that a website with the word “Microsoft” in big friendly letters at the top of the page, may have been serving malware. We were worried that users may visit the site with confidence and trust its content because it carried our name. So, we took a closer look at this “Microsoft” website.


We can see it does use the title “MSPinoy – Microsoft Philippines Users Group”, and when you click on the Forums tab up top, it sends you directly to an actual Microsoft website. Everything goes well initially, but after less than a minute, the system becomes sluggish and Microsoft Security Essentials reports a possible malware infection.

So the question is: who is “MSPinoy”? After some searching, we found out that the website has existed since June 2008 and has a legitimate registration contact in the Philippines. Based on our research, we assume that this website is probably not malicious, but is a community users group which references some official Philippines Microsoft links for its users.

So, if the site is a real users group (if not Microsoft endorsed per se), then how are visitors getting infected? When we looked further into the webpage source a suspicious iframe emerges at the end of the page. This iframe, which referenced a different host (, soon redirected to another one. Upon being redirected the new webpage contained several malicious Java applets that tried to exploit vulnerabilities on the system and download other malware. When we visited, these exploits were detected as variants of Exploit:Java/CVE-2010-0840 (example file SHA1s observed 626D495992C77BE9E47A9F2A1ED573739F34636F and A67C7CC6BD6C516D865C8BB37134F457E0B89A3D) and Exploit:Java/CVE-2012-0507 (example SHA1 of file observed 374F8FDB2EB49D5C883785A6ED627BE6CF9BACC9).

We also then did an online search into


Looks like the registrant is from Australia and belongs to an organization called The registration date is just a couple of days ago. We continued to monitor this website and found that the malicious iframe was refreshed every day with a different host (such as or which was also registered to

So, it looks like the MSPinoy website we investigated had been compromised, and the hijack code is being refreshed daily, presumably from a C&C server.

So, our last question: Who is According to their website, is a company that provides a privacy protection service for domain owners, so that their registration contact details are not generally available to the public. So the true identity behind these domains is still a mystery.

As stated, this short case study is a fairly typical illustration of how malware is distributed, and it teaches some valuable lessons about how to defend yourself:

  • Use a complete AV solution (such as Microsoft Security Essentials)
  • Update your AV daily. As this example shows, the bad guys update their code daily, so you need to as well.
  • Get and install the latest updates for ALL of your computer programs. Be proactive – this is really important.
  • Be vigilant. Bad guys will attempt to take advantage of your existing trusted relationships (such as the relationship you might have with a company like Microsoft).
  • Be aware that these types of attack are prevalent and dangerous and that attackers will try to take advantage of you, your computer and your assets. Use caution online.

Tim Liu


Categories: CVE-2010-0840, CVE-2012-0507, exploits Tags:

Analysis of the Eleonore exploit pack shellcode

April 20th, 2012 No comments

‘​Eleonore‘ is a malware package that contains a collection of exploits used to compromise web pages. When the compromised web pages are viewed via vulnerable systems, the exploit payload is run. Eleonore is purchased by an attacker from an underground website. The attacker then gains access to Internet web servers and installs the exploit by modifying webpages, which are then served to the public. The malware pack also contains functionality for the tracking and management of compromised computers.

Remote attacker purchases the exploit pack, installs Eleonore (courtesy of MMPC)

Image 1 – Remote attacker purchases the exploit pack, retrieves web pages from Internet servers and installs Eleonore

Eleonore is developed and released as version updates. This blog post focuses on the shellcode exploit from one of the releases, version 1.2. At a high level, the Eleonore shellcode locates kernel32.dll in an exploited process space. It uses the spatially efficient hash lookup to find the absolute address of key Kernel32 APIs:

Image 2 – FindFuncHash routine

With access to these functions, the shellcode creates a file in the temporary files folder (%TEMP%) and calls URLDownloadToFile with a URL that is 0x67 bytes after the shellcode. The shellcode then executes that file.

The exact URL is dependent on bytes included in the exploit payload and is beyond the scope of this analysis. The exploit then decrypts bytes right after the shellcode for another URL and calls URLDownloadToFile for a second time, copying the file from a URL such as the following:

<website domain with Eleonore installation>/path/getexe.php

This URL was obtained by looking at the entire exploit payload from an Eleonore installation – that data is not included in this article. The “getexe.php” file creates a server-side response that returns a file named “load.exe“. The contents of this file are put into a secondary file, decrypted in memory, written back to the file and finally executed.

Decrypt routine

Image 3 – DecryptBytes routine


The shellcode ends here as “load.exe” begins, with the affected computer now compromised.

Eleonore v1.2 contained numerous exploits and attack code that targets several programs including:

  • DirectX 9, affecting certain versions of Windows operating system
    • Vulnerability discussed in CVE-2008-0015 and
      fixed with Microsoft Security Bulletin MS09-032
    • Malware detected as Exploit:JS/CVE-2008-0015 and Exploit:HTML/CVE-2008-0015
  • Microsoft Internet Explorer 7 memory corruption
    • Vulnerability discussed in CVE-2009-0075 and
      fixed with Microsoft Security Bulletin MS09-002
    • Malware detected as Exploit:JS/CVE-2009-0075
  • Microsoft Internet Explorer ActiveX control “snpvw.Snapshot viewer Control.1”
    • Vulnerability discussed in CVE-2008-2463 and
      fixed with Microsoft Security Bulletin MS08-041
    • Malware detected as Exploit:JS/Objsnapt.E, Exploit:JS/Objsnapt.F and Exploit:HTML/Snavic.gen!D
  • Microsoft Internet Explorer 6 MDAC
    • Multiple vulnerabilities, discussed in CVE-2004-0549 and CVE-2006-0003, and
      fixed with Microsoft Security Bulletin MS04-025 and MS06-014
    • Malware detected as TrojanDownloader:VBS.Psyme.X, TrojanDownloader:JS/Adodb (and other names)
  • Opera telnet 9.25
  • Certain versions of Mozilla Firefox
  • Certain versions of Adobe Reader

To protect against Eleonore and other threats, the MMPC recommends maintaining security updates across all products, not only those serviced by Microsoft Windows updates, and using security software with active scanning enabled.


— Nik Livic & Patrick Nolan, MMPC


Get gamed and rue the day…

October 26th, 2011 No comments

As we discussed last week, socially engineered threats are specially crafted threats designed to lure the eye and trick the mind – they look legitimate or benign, and in worst case, may take advantage of a trusted relationship, by utilizing a compromised account or familiar website. Social engineering techniques may be used in isolation, but are often used by attackers in tandem with other types of exploit in order to perform the attacker’s real purpose – delivering the payload. What follows is a typical example that illustrates how attackers attempt to exploit both people and systems in order to achieve their goals. 

Last month, Worm:Win32/Gamarue, a bot-controlled worm, was discovered as the payload of a series of browser-hijacks and traffic redirects to malicious servers hosting and performing multiple browser-based exploit attacks.
The initial trigger event was identified as shared content, commented on a social networking site.


When users clicked on a link in a comment from a contact in order to see more information, they were first directed to another profile and then encouraged to click on another link. 


However, this second link directed affected users to malicious content that loaded a hidden iframe (detected as Exploit:JS/BlacoleRef.D SHA1 8da25114758b2e3f454af0346ce7e716ac91c829). This iframe referenced an exploit server hosting a version of the ‘BlackHole’ exploit kit (detected as Exploit:JS/Mult.DJ SHA1 4cba7b2385b7ee7a84992ddaf77aa6d85b72b5ce).  The exploit server attempted to exploit multiple known vulnerabilities in the affected user’s browser, until a successful compromise could be achieved. In our example, a malicious Java applet stored within a Java Archive (.JAR) (detected as Exploit:Java/CVE-2010-0840.FK SHA1 87800737BF703002263E3DBA680E4EE9FE9CA5B0) was observed being loaded on browsers with enabled vulnerable versions of the Java plugin. This Java vulnerability allows an unsigned Java applet to gain elevated privileges and potentially have unrestricted access to a host system outside its “sandbox” environment.  The final result? The installation of Worm:Win32/Gamarue.A (SHA1 427fa7d7aa1e4ee8a57516979711e11e59e51559). When it first appeared this threat did not appear to be detected by any known scanners.


Figure 1 – Method of delivery for Worm:Win32/Gamarue.A

A code fragment of this threat suggests that it may be a new bot called “Andromeda”.  Similar to known bots such as Zeus and Spyeye, Andromeda is also a modularized program which  can be functionally developed and supported using plug-ins.  It is also sold via an underground forum, where pricing varies depending on the version of the bot, the number of domains utilized, and the purchaser’s plugin development requirement.

The elaborate methods used to distribute this threat suggest that along with being mindful of illegitimate attempts to convince you to perform particular actions, and keeping your software updated, your choice of browser really matters.  Microsoft recently launched a new website, which ranks your browser security from 0-4 and provides information on the risks involved in continuing to use older versions. 

As always, we encourage you to stay safe online.

Methusela Cebrian Ferrer


SIRv11: Putting Vulnerability Exploitation into Context

October 14th, 2011 No comments

As Vinny Gullotto, our GM blogged earlier in the week, the 11th edition of the Security Intelligence Report (SIRv11) has been released. One of the new areas of research in this release is a study of the most prevalent kinds of vulnerability exploitation and how much of that exploitation is 0-day (short for zero-day, an attack or exploitation of a vulnerability without an available update). We took two paths to find this answer. The first was an analysis of how the top families found by the Microsoft Malicious Software Removal Tool (MSRT) were known to infect systems. We found that none of the top 27 families were known to use 0-day vulnerabilities in 1H11.

The second way we approached this answer was to measure all of the exploit activity tracked by the MMPC through our real-time protection products (such as Microsoft Security Essentials and Forefront Endpoint Protection) and compare the number of attacks that were 0-day at the time (no update available) versus attacks that occurred after the update was made available. We actually gave a month buffer zone (so any exploits that happened during the month in which the update was made available was still counted as 0-day). We expected the percentage to be low, and it was– 0.12 percent to be exact for 1H11. Here’s what it looks like in chart form:

Chart illustrating percentage of exploits that were 0-day in 1H11
Chart 1 – Chart illustrating percentage of exploits that were 0-day in 1H11

One question that we discussed a lot while working on this report was: How do we measure what we don’t know and therefore can’t see? (In other words, 0-day by definition means you may not know about it.) Great question! Answer: We can’t measure what we can’t see. However, what we have seen tells us that “secret 0-days” don’t stay a secret for very long. Take, for example, a few we tracked in 2010. These attacks nearly always started out as targeted – sometimes reported as affecting only one entity when they were discovered. The trend they have in common is that they broaden to more generalized use (eventually) and we find out about them sooner or later.

  • CVE-2010-0806 was a 0-day affecting Internet Explorer 6 and 7 on older operating systems (like Vista and XP) that was reported as being used in targeted attacks. A few days later, after the release of public exploit code, we saw those attacks escalate and they have remained a sizable part of exploit activity throughout 2011.
  • CVE-2010-3962, which we dubbed the Weekend Warrior for its peaks of activity in Korea on the weekends, was discovered in Nov. 2010 when it was used in targeted attacks. Attackers broadened the targets of their attacks near the end of the month.
  • Another example is CVE-2010-3962, the vulnerability that used malicious .lnk files that was found with Stuxnet. It took a matter of weeks before this one technique used in this very targeted, singular attack got picked up by many other families of malware like Sality, broadening the impact considerably.

The point here is that although it’s true that “you don’t know what you don’t know,” our experience tells us that when it comes to 0-day activity, we find out, and often, we find out quite quickly. Things start to unravel rapidly the moment the 0-day affects either a target that’s really paying attention or when the attacks start to affect a broader, less targeted audience.

So, even if our estimates for 0-day activity were off by 5 fold, the estimated activity for 1H11 would remain under 1 percent. That’s still pretty small.

Most Frequent Exploits

So, now that the question of 0-day is out of the way, let’s talk about the broader volumes of exploit activity that were revealed in SIRv11. Although there are many interesting trends in the chart below, I want to focus on a few of them in this blog: Java (and the age of vulnerabilities in general) and Operating System vulnerabilities. If you want details about the other categories in this chart, see the full Security Intelligence Report.


Exploit activity over a one year period

Chart 2 – Exploit activity over a one year period

Java Exploits

As we blogged a year ago, in 3Q10, the exploitation of Java vulnerabilities skyrocketed to new levels that we had never seen before. The analysis in SIRv11 shows that Java exploitation remains high and that the targeted vulnerabilities are quite old. The top four Java exploits are CVE-2010-0840, CVE-2008-5353, CVE-2010-0094, and CVE-2009-3867. These CVEs affect the Oracle Sun Java JRE or JDK, and all of them have updates available to fix them now. The most recent, CVE-2010-0094 and CVE-2010-0840, received updates in April 2010 after following a coordinated disclosure process with an external vendor.

Operating System Exploits

The jump in operating system exploits is primarily due to one technique: CVE-2010-2568 (the vulnerability mentioned earlier that was found with Stuxnet). This exploit was picked up by a number of families that were known to abuse Autorun. And, although CVE-2010-2568 has nothing to do with Autorun itself, the behavior is quite similar: the user connects to a USB device and browses the drive, the malware automatically executes (if the user hasn’t applied the update to fix the issue, that is). Malware authors must have found this exploit technique alluring. At least, the data certainly seems to indicate that they did. It’s also possible that attackers, after Microsoft released updates to harden the Autorun feature on older systems (which did appear to put a dent in their ability to infect users), were searching for ways to broaden their infection rate.

Another interesting aspect in our exploit data on CVE-2010-2568 is the location of the targets. I recently did a talk at Virus Bulletin on the top exploits of 2011, and in that talk, I looked at geographical differences for regions that face the most exposure to exploitation attempts. Several regions that were at the top, Indonesia, Pakistan, and Vietnam, were there because of exploitation attempts for CVE-2010-2568. If you combine those three locations with two more, India and Mexico, those five together represent 52% of all the computers that have reported CVE-2010-2568 attack attempts in the first three quarters of this year. Although I don’t have update statistics for these regions, this data might indicate that there are large numbers of systems there that have not yet applied this very important update (MS10-046).

Net Net

I’ve talked about a lot of data in this post, and sometimes it’s hard to synthesize it. The key point of the exploit analysis in SIRv11 is that older vulnerabilities are what the vast majority of exploitation attempts target (90 percent are more than a year old). The special 0-day section of the report takes this concept even further – we look at how much of the malware infections are actually attributed to the exploit of vulnerabilities in general. (The answer: Less than 6 percent in 1H11.) To find out what the other 94 percent of infections are attributed to, download the report and keep your eye on this blog for more analysis to come.

– Holly Stewart, MMPC

A Technical Analysis on the Exploit for CVE-2011-2110 Adobe Flash Player Vulnerability

July 1st, 2011 No comments

On June 14, Adobe released updates and a security bulletin (APSB11-18) referencing attacks affecting Adobe Flash Player (versions and earlier). These attacks have been observed as hosted on webpages containing malformed SWF files. We spent some time analyzing this Flash Player vulnerability (described in CVE-2011-2110) and are providing some technical details of this in-the-wild exploit.

The Shellcode

The following steps describe how the SWF constructs the shellcode:

  1. The SWF downloads a binary file from a URL which is specified in the HTML file. The attacker can simply change the HTML file to reuse the exploit to download another file.
  2. The SWF decrypts the binary file with a simple XOR operation.
  3. The SWF then decompresses the decrypted data.
  4. The SWF builds up a shellcode including ROP gadget addresses which saves the decompressed data to “%TEMP%\scvhost.exe” and executes it.

Details of the exploitation process:

Unlike other SWF exploits, this exploit doesn’t use heap-spray technique. Instead, it uses a 3-stage ROP-based attacking process, which can be described as the following:

  1. The malformed SWF leverages the vulnerability in the Adobe Flash Player and mocks up a fake Object data structure with a deliberately crafted VTABLE (virtual table), which can cause the control transfer from the JIT (Just-In-Time) compiled code to the ROP gadgets built from the Flash Player DLL.
  2. The ROP gadgets call VirtualAlloc( ) to allocate an executable memory region and build the following trampoline code into it.
  3. The trampoline code calls VirtualProtect() to make the aforementioned shellcode built by the SWF executable and then executes it.


Figure 1: ROP address adjustment according to Flash version and container type


The unique thing about this malware is that it is version-specific when constructing shellcode. Rather than just using a static shellcode, it’s building it according to the Flash Player version and the type of container holding the SWF file (see Figure 1 above). Based on this information, it’s adjusting the ROP gadget addresses (see Figure 2 below). Every gadget address is inside the Flash Player’s own DLL and this makes the exploit process very stable. Currently we saw the malware targeting versions, and

Figure 2: The dynamically built shellcode based on Flash Player version


The downloaded PE file

The downloaded PE file executed by the shellcode is detected as PWS:Win32/OnLineGames.ZDV (SHA1: 4a13a14523fe95817cc53c75f86ee4af36ee2464) which specifically targets the Korean online games community. This focus on Korea has been also evident in our telemetry from our protected Microsoft Security Essentials and Forefront customers, where, aside from one day (June 22) where attacks increased in Europe and Russia, attack attempts have been predominantly reported from computers in Korea.


Figure 3: MMPC Telemetry on CVE-2011-2110 Attack Attempts during June 17 – 30, 2011



— Jeong Wook Oh, Chun Feng & Marian Radu

Microsoft Safety Scanner detects exploits du jour

May 25th, 2011 No comments

We recently updated the Microsoft Safety Scanner – a just-in-time, free cleanup tool.  The new version adds support for 64-bit Windows systems and also allows for the download of the tool to run in non-networked systems such as those behind an air-gap network, those within an ISPs walled garden, and those where the infection has impaired internet connectivity.  You can download the Microsoft Safety Scanner (MSS) at

Early results have been very positive with this tool and we are actively reviewing telemetry from our customers who use it in order to better understand aspects of threat impact from specific malware families. In addition, we urge our customers to install security updates provided by Microsoft for our operating systems and applications, as well as from other third-party applications and any security updates that may be provided by Internet service providers. Early telemetry gathered from the release of the Microsoft Safety Scanner echoes this continuous messaging.

During the first seven days of the MSS release, there were close to 420,000 downloads, or 60,000 downloads per day, of the product. It cleaned 20,097 infected computers in total, for users that suspected their computers were infected and downloaded MSS to scan their machines. Kudos to these users for having security awareness.

Among the detections, 7 of the top 10 threats are files containing exploits for Java vulnerabilities such as CVE-2008-5353, CVE-2010-0094, CVE-2010-0840 and CVE-2009-3867. (For more information related to these exploits, see the blog post “Have you checked the Java?” by our colleague Holly Stewart.)

Below is a table detailing Microsoft Safety Scanner detections in the first seven days since its release:



Threat Count

Machine Count





Java Exploit




Java Exploit




Java Exploit




Java Exploit








Java Exploit




Malicious Win Media File




Key Generator Hacking Tool




Java Exploit




Java Exploit


Of course many of these detections by MSS are the debris or aftermath after the exploit has already executed. By the time a user downloads and runs MSS to detect malware, the machine may have already been infected, if it was vulnerable to the exploit at the time.  For example, aside from additional malicious Java code detections, the following active threats were also reported on machines found to be infected by Exploit:Java/CVE-2008-5353 on April 15 2011:



Percentage of machines
where MSS also detected




Rootkit Data Stealing Trojan



Browser Modifier















Rogue Downloader






Encrypted Threat





On average, MSS detected 3.5 threats on each of the infected computers.


Threat Count

Infected Machine Count

Threats Per Infected Machine





This won’t surprise you if you have read our newly published Security Intelligence Report (SIR).  For example in the exploit section, the data shows Java exploits uptake in 2010:

Exploits detected by Microsoft desktop antimalware products in 2010, by targeted platform or technology


If you are one of these users, we encourage you to apply security updates from Microsoft (and from the ISVs where applicable). In addition, take care and protect your Internet activities.  Install antimalware security software such as Microsoft Security Essentials (or other AVs) to protect your computers proactively using real-time scanning technology.

We want to give a special thanks to Holly Stewart for her assistance in this post.


— Scott Wu & Joe Faulhaber, MMPC

Dead code walking

May 24th, 2011 No comments

Recently I had a moment to review a group of PDF exploit files. Many exploits use various tricks to obfuscate embedded JavaScript. I thought I could de-obfuscate the samples by throwing them into a sandbox environment and enjoying the beautified source code, but these samples required a different method to coax the legible code into view.

In these examples, which come from Exploit:Win32/Pdfjsc.NJ (SHA1 45d04db8617a85f5359fb1a33ad867ef3d43eb7f), the files contained JavaScript that was embedded into an XFA form that allowed Adobe Reader to run the code when the file is opened by setting an event handler for field initialization. This trick is not new, but it is relatively easy to extract the malicious JavaScript code, as visible in this snippet:

extracted JavaScript
Image 1 – extracted JavaScript

The embedded code contains many useless variable assignments and arithmetic operations. After reviewing the block of code, nothing interesting was readily identifiable; most of the code resembled the image shown below:

arithmetic assignments
Image 2 – arithmetic assignments

It is quite different than the obfuscation seen before in other samples. By carefully examining the code, several obfuscations that utilize the reverse process of code optimization are identified.  Look at this piece of code:

dead code
Image 3 – dead code

The local variable ‘dv’ is assigned a value and has a ‘minus’ operation. But after that, the variable is never accessed in its life scope, which means these two lines are dead code that can be removed without affecting the result of the program. Besides this, fake conditions are added in many places to make the code more confusing:

meaningless code
Image 4 – other meaningless code

The variable ‘dc’ is constant when compared to the constant value ‘7266’; the code block inside the ‘true’ branch of the ‘If’ statement will never be executed, which makes the whole ‘If’ statement useless. After removing all of this dead code, other interesting things begin to show up and all of the strings are encoded in two ways:

decoding algorithm
decoding algorithm
Image 5 – decoding algorithm

A function named ‘kop’ is used all in several places to decode the strings using an algorithm. The above example will simply set variable ‘g’ to the value ‘substr’. All external functions are used in the following way so that the strings must decode first before knowing what the function is called.

Therefore, this:

before substituting variables

Is equivalent to this:

after substitution of variables

At this point, based on the decoder algorithm found in function ‘kop’, all the decoded strings can be replaced to its original string and then all JavaScript function calls can be revealed. After the de-obfuscation, the code looks clearer. By examining what each function was doing and renaming the variables and strings accordingly, I derived the following copy of the main function:

de-obfuscated main function
Image 8 – de-obfuscated main function

The exploit checks the PDF reader’s version to select exploit shellcode accordingly, then performs a heap spray to try and exploit a vulnerability discussed in CVE-2010-0188. The malformed TIFF data is concatenated as a base64 string and assigned to ‘rawValue’ of XFA field ‘ska’. After the decoding, the TIFF data is shown as following for PDF reader versions between 8.0 to 8.2.1:

TIFF data as viewed in a hex viewer
Image 9 – TIFF data as viewed in a hex viewer

The shellcode simply downloads and executes additional malware from a remote server. At the time of this writing, the malware was detected as TrojanDownloader:Win32/Epldr.A.

We can see that malware authors are taking obfuscation more seriously to try and evade security software. Although this exploit uses complex obfuscation methods to avoid being detected and analyzed (which makes it more advanced than other exploits) the technique used here is not new.

As always, be safe and use up-to-date security software.


— Shawn Wang, MMPC

Categories: exploits, JavaScript, PDF exploit, research Tags:

Slick links linked to slinky Winwebsec

May 3rd, 2011 No comments

I received a spam email from a friend lately after which I immediately notified him of a potential malware infection.  He insisted his technician had taken care of the infection once and for all.  After I returned from my vacation I received another three spam mails from him.  This time I decided to look further.

Message 1, about two weeks old, contained a simple URL shown as ‘’.  The hyperlink actually is for a different site, “”, a site that has been taken down when I tested in our lab.

Message 2 contained another URL, also displayed as ‘’ and the hyperlink this time was for another site, “”.   As of April 27, the site was still alive, and appears to be a fake site for the purchase of drugs online:

Image 1 – fake pharma site


Message 3 arrived only a few days ago, and it too used the ‘’ ruse. The message contained a single line of content, with a displayed link of ‘’ and an actual hyperlink of “”. I turned to a fellow researcher Tim to investigate. Below is a short summary of what he discovered.

When visiting the URL, it installs a program with a file name of “pack.exe” (ShA1: 6286972A5DA540E058DD2AEDFC38B6061FF67F14). A quick search at VirusTotal – an online service that scans submitted malware samples using multiple security scanners – indicated no current detection by security vendors.

When I ran the program, a familiar interface popped up – it was the rogue Win32/Winwebsec:

Image 2 – Win32/WinWebsec rogue


And now, they want $99.95 for it:

Image 3 – purchase lure


After having a peek at the HTML code of the malicious website, we found there was actually an exploit kit being implemented to install rogues, using a “drive-by-install” method. The exploit is similar to the known “Zombie Infection Kit” and also the “Siberia exploit kit”, and it includes the following exploitation methods:


Image 4 – CVE-2006-003 – Microsoft Data Access Components (MDAC) Vulnerability


Image 5 – CVE-2010-0886 – Java Deployment Toolkit Vulnerability


Image 6 – CVE-2010-1885 – Microsoft Windows Help and Support Center Vulnerability

If these exploit methods look familiar, that’s because they are the exact exploit toolkits heavily used to distribute Zbot (aka Zeus). The rogue installed by the web page mentioned above is detected as Rogue:Win32/Winwebsec.

If you only draw one conclusion from our research, let it be “don’t click on suspicious links”.


–Tim Liu & Scott Wu, MMPC

Analysis of the CVE-2011-0611 Adobe Flash Player vulnerability exploitation

April 13th, 2011 Comments off

About a month ago, we blogged about an Adobe Flash Player vulnerability (CVE-2011-0609) that was actively exploited in the wild. That exploit was hidden inside a Microsoft Excel document. Over the weekend, a new Adobe Flash Player 0-day (CVE-2011-0611) was reported by Adobe in a recent advisory (APSA11-02).

It all started with spam emails enticing users to open its attachment, typically a Microsoft Word document (or a zip file of a Microsoft Word document), which contained the malicious Flash exploit inside.  Most of the files we have captured with our signature are named:

  • Fukushima .doc
  • evaluation about Fukushima Nuclear
  • 首場政見會後最新民調略升-蔡英文粉絲團~聲援 .doc
  • 日志分析.doc

Inside the .doc file a malformed Adobe Flash file is embedded. Once a user opens the document, Flash Player will load the malicious file and exploitation will occur. Unlike the previous vulnerability, a bug in the ActionScript Virtual Machine version 1 is now used in the exploitation process. Another difference is that this is not a result of fuzzing clean files. We won’t disclose any detail on what triggers the vulnerability, for security reasons, obviously.

In order to exploit this vulnerability the attackers packaged the AVM1 code inside an AVM2 based Flash file. The latter is embedded inside the Word document and assigned with setting up the exploitation environment.

Initially the AVM2 code constructs a heap-spray buffer made of a NOP-sled (image below):

Image 1 – NOP-sled

The AVM2 code constructs a Win32 shellcode(constructed in highlighted  ByteArray  “s”):

Image 2 – shellcode

It then loads the attack code inside the Flash Player. The AVM1 code that triggers this vulnerability is loaded as a separate SWF file, converted from a hex-encoded embedded string and executed as in the screen dump below:


Image 3 – CVE-2011-0611 attack code

Shellcode details

The shellcode is injected starting at address 0x11111111 and is a fairly standard one.

Its task is to launch the payload while trying to hide the signs of an infection. It does that by dropping a clean Word document which will replace the original, malicious one.

Let’s see, in detail, what the shellcode does once it gets executed:

  • Resolves needed APIS’s :
    • LoadLibraryA
    • GetFileSize
    • GetTempPathA
    • TerminateProcess
    • CreateFileA
    • WideCharToMultiByte
    • SetFilePointer
    • ReadFile
    • WriteFile
    • WinExec
    • CloseHandle
    • GetCommandlineA
    • GetModuleFileNameA
    • CreateFileMappingA
    • MapViewOfFile
    • GetLogicalDriveStringsA
    • QueryDosDeviceA
    • ZwQueryVirtualMemory
  • Brute-forces its way to the Word document’s file handle by knowing that
    • File size must be > 0x7000
    • It must contain the marker 0x7010 at offset 0x7000
  • Retrieves the file path of the Word document file using ZwQueryVirtualMemory and GetLogicalDriveStringsA
  • Decrypts a binary from the document, dumps it as %temp%\scvhost.exe (SHA1 adbf24228f0544a90979a9816569e8c7415efbac – detected as Backdoor:Win32/Poison.M) and finally executes it.


Image 4 – Win32 Shellcode fragment

  • Decrypts an embedded doc file and saves it as ‘%temp%\AAAA’. This file is the clean Word document we mentioned earlier.
  • The freshly dumped doc file is then used to overwrite the initial Word document.
  • The new document is launched to hide symptoms of infection.
  • Using the utility “taskkill.exe”, it terminates all processes with the name ‘hwp.exe’.

The current WinWord (Microsoft Word) instance is terminated.

We currently detect the malicious Word document and the embedded attack Adobe Flash file as Exploit:SWF/CVE-2011-0611.A. We urge you to read the advisory from Adobe for mitigation details about this vulnerability.As always, we advise you not to open emails from untrusted sources or emails that seem suspicious to you, even if they apparently come from people you know.

Marian Radu, Daniel Radu & Jaime Wong

PS: We’d like to thank our colleague Bruce Dang for his contribution to this blog post.

Embedded JavaScript in SWF

March 7th, 2011 Comments off

In a blog published in November titled “Explore the CVE-2010-3654 matryoshka“, we discussed a 0-day Shockwave (SWF) exploit that uses JavaScript to do malicious actions. In this blog, we discuss another advanced way SWF malware is combined with JavaScript only this time, without using a 0-day exploit.

In January we noticed a very large spike in telemetry for a threat named Trojan:SWF/Jaswi.A. Going back to December 2010, we had picked up a few spikes for this issue, one around Christmas, a second after New Year’s, a second after New Year’s and then a third and largest spike the weekend after New Year’s:

Image 1a – Prevalence chart for Trojan:SWF/Jaswi.A

Image 1a – Prevalence chart for Trojan:SWF/Jaswi.A

When we looked deeper into the targets of these attacks, we discovered that they were predominantly reported by computers in South Korea. Since the beginning of this year, 89% of the targets were in South Korea with 75% of them specifically in Seoul. Here’s a chart with a breakdown by unique machines in the months January and February of this year (there has been no activity in March):

Image 1b – Attack attempts by unique machines in the months January and February of 2011

Image 1b – Attack attempts by unique machines in the months January and February of 2011

Interested in the anomaly, I decided to have a look. After spending some time reviewing it, an interesting thing emerged. The malware Trojan:SWF/Jaswi.A is unlike other SWF malware; other SWF malware typically calls “getURL <website address>” within an ACTION tag in order to visit a malicious website link without user consent. For more about this, see the following:

Trojan:SWF/Jaswi.A contains an embedded malicious JavaScript that initiates a legal Windows API call to trigger the payload. Although the analysis was only slightly involved, let’s take a simple step by step tour of the malware.

1. SWF with embedded JavaScript

Image 2 – Embedded JavaScript within Trojan:SWF/Jaswi.A

Image 2 – Embedded JavaScript within Trojan:SWF/Jaswi.A

If we convert the JavaScript into Actionscript, it should appear as below:

Image 3 – JavaScript from Image 1 converted to Actionscript illustrating Windows API call

Image 3 – JavaScript from Image 2 converted to Actionscript illustrating Windows API call

From the image above, we can see the legal function has been made to complete a procedure of initiating JavaScript injection. Well, this is not a new method after all, but only a few SWF malware take advantage of this technique.

2. JavaScript obfuscation
We notice the embedded JavaScript is also simply encrypted by a method “fromCharCode()”. After decryption, the real JavaScript code appears (edited below):

Image 4 – Decrypted JavaScript with black-outs added

Looks familiar? Yes, the Microsoft Internet Explorer vulnerability CVE-2010-0806 has been abused! This particular exploit affects Microsoft Internet Explorer versions 6, 6+SP1 and 7, and could allow a remote attacker to execute arbitrary code.

3. Shellcode
In Image 4 above, you can see Unicode encrypted by the method “unescape()” – this is the malware shellcode body, which includes a simple xor algorithm to avoid the detection. Further into the obfuscation, we finally see the destination, show below:

Image 5 – Destination URL indicating an executable named “uusee.exe”

Image 5 – Destination URL indicating an executable named “uusee.exe”

The file “uusee.exe” from the obfuscated URL shown above is actually a prevalent password stealer in China that Microsoft antimalware technologies detects as PWS:Win32/Lolyda.AU (SHA1: 0bd98a39c2eaa9c523e41cec250623b44f6d3239).

We mentioned the embedded JavaScript technique used in the malicious SWF here because it appears to be a trend and may become a popular method. As always, use caution while surfing the Interwebs and use on-access antimalware protection from a credible scanner (for more information on antimalware software, see


— Tim Liu, Malware Researcher, MMPC