Archive for the ‘Adobe’ Category

Keeping Adobe Flash Player

Years ago, Java exploits were a primary attack vector for many attackers looking to infect systems, but more recently, Adobe Flash Player took that mantle.

After accounting for almost half of object detections during some quarters in 2014, Java applets on malicious pages decreased to negligible levels by the end of 2015, owing to a number of changes that have been made to both Java and Internet Explorer over the past two years.

In January 2014, Java Runtime Environment was updated to require all applets running in browsers to be digitally signed by default. Later that year, Microsoft published updates for Internet Explorer versions 8 through 11 that began blocking out-of-date ActiveX controls. Windows 10’s default browser, Microsoft Edge, does not support Java or Active X at all, and other browsers like Google’s Chrome and Mozilla’s Firefox are doing the same.

With defenses against Java attacks gaining the upper hand, Flash Player objects have become the most commonly detected threat hosted on malicious web pages by an overwhelming margin. This type of exploit has led the way in each of the past four quarters, from a low of 93.3 percent in the first quarter of 2015, to an all-time high of 99.2 percent last fall.

Adobe Flash

While this information may be unsettling for security teams whose web sites and applications rely on Flash functionality, it’s clearly an important piece of intelligence. Knowing where attackers are targeting their cyber threats makes it easier to plan mitigations to defend against malicious web pages. It also illustrates the importance of keeping your full technology stack – including Adobe Flash Player – updated. And fortunately, as with Java, modern browser mitigations are beginning to turn the tide against Flash exploits as well.

Both Internet Explorer 11 and Microsoft Edge on Windows 10 help mitigate many web-based attacks. For example, Internet Explorer 11 benefits from IExtension Validation, which can help defend against Adobe Flash malware.

Real-time security software can implement IExtension Validation to block ActiveX controls from loading malicious pages. When Internet Explorer loads a webpage that includes ActiveX controls, the browser calls the security software to scan the HTML and script content on the page before loading the controls themselves. If the security software determines that the page is malicious (for example, if it identifies the page as an exploit kit landing page), it can direct Internet Explorer to prevent individual controls or the entire page from loading.

For a thorough analysis on the state of malware in the latter half of 2015, take a look at our latest Security Intelligence Report. And for a high-level look at the top ten trends and stats that matter most to security professionals right now, be sure and download our 2016 Trends in Cybersecurity e-book.

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:

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


Vulnerability analysis, practical data flow analysis and visualization

March 23rd, 2012 No comments

Recently at CanSecWest 2012, we presented on the technology we use for analyzing malicious samples and PoC files. As malware often actively attempts to exploit software vulnerabilities these days, understanding the internals of these vulnerabilities is essential when writing defense logic.

Out of the many methods that can be used for vulnerability analysis, we presented a method that uses dynamic binary instrumentation and data flow analysis. Dynamic binary instrumentation and data flow analysis are fancy concepts, and they can be a little bit difficult to apply to real world cases.

We showed a case where we used data flow analysis for a simple integer overflow vulnerability. By showing the result in a more visualized way, it helped us to understand the vulnerability. But the real issue we raised was how to use these technologies in more complicated cases, for example, for analyzing an uninitialized memory access vulnerability. We used CVE-2011-2462 (a vulnerability in Adobe Reader and Acrobat – this issue was addressed by Adobe and you can find more information here) as an example to show how to trace back to the root cause of the vulnerability using these techniques. (Note: the Adobe Reader X Protected Mode and Acrobat X Protected View mitigations (the Reader X and Acrobat X sandboxes) would prevent exploits of this vulnerability from executing – this is an exercise in analyzing a vulnerability not an exploit.)

The vulnerability is a little bit complicated, as the data flow does not show the whole picture of the connection between the user data and the crash point.

Data flow analysis for crash case

Figure 1 Data flow analysis for crash case

We performed data flow analysis on the data related to the crash point. As you can see from the above picture, we can clearly see that the data source used in the crash point comes from an area of freed memory. As the execution order is from bottom to top, the free operation is performed first – the data is passed to Adobe Reader and is used for operations later which leads to an uninitialized memory issue.

Data flow analysis for normal case

Figure 2 Data flow analysis for normal case

The above data flow graph is from a good sample file which hits the same area of the code as the crash case. But in this case, we can see that the data comes from an allocated area using malloc API.

Crash case and normal case

Figure 3 Crash case and normal case

By performing data differential analysis between the crash case and the normal case, we can pinpoint the exact instruction that is responsible for the diversion of data flow. The following table shows the difference in the instruction that makes the data flow diversion and you can see that “mov dword ptr [ecx+ebx*4h], eax” is the key instruction that makes the difference.

Crash case and normal case

Figure 4 Crash case and normal case

So we start control flow differential analysis from that specific key instruction.

Key instruction from data flow differential analysis

Figure 5 Key instruction from data flow differential analysis

The following graph shows the control flow differential analysis result.

Control flow differential analysis result

Figure 6 Control flow differential analysis result 

From the graph above, we can see that the instruction at 10009E72 basic block (in red) is the instruction that determines the fate of the control flow. The control flow depends on the value of eax register; it is key to creating the crash condition.

We traced back this eax value from that instruction point in the crash case, and got the following graph. Finally we could locate the exact file location where the eax comes from. And this eax value controls the condition for the crash later.

EAX Control

Figure 7 EAX Control

So the whole point of this post is that data flow analysis is a good tool for vulnerability analysis, but it doesn’t solve all the real world vulnerability cases. Real world vulnerabilities are more complicated. So to apply this technology, you need to introduce more strategies and methods. We showed data flow differential analysis and control flow differential analysis as examples that could solve an uninitialized memory access case.

For the full content of the presentation, please visit this page. It should be available soon.

Jeong Wook Oh

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