LadyBoyle Comes to Town with a New Exploit

[Update: February 12, 2013] By now you have probably heard of the new zero-day exploit in Adobe Flash that was patched today. FireEye Labs identified the exploit in the wild on February 5, 2013, which based on the compile time and document creation time is the same day the malicious payload was generated. Adobe PSIRT has released information about this threat here. They have also released an advisory with details on versions and platforms affected along with applicable patches. The two exploits have been assigned CVE-2013-0633 and CVE-2013-0634. It is highly recommended that you apply this patch right away, as this threat is active in the wild.

We will examine the payload executed as a part of this threat in the wild. We have identified two unique word files containing CVE-2013-0634 so far. It is interesting to note that even though the contents of Word files are in English, the codepage of Word files are “Windows Simplified Chinese (PRC, Singapore)”. The Word files contain a macro to load an embedded SWF Flash object.

The SWF file contains an action script with the name “LadyBoyle” that contains the exploit code. The exploit only supports limited version of Flash as evident in the action script seen in Figure 1. It also checks for the presence of activex component.


Figure 1

It drops multiple exe files and a DLL payload. The payload that is dropped and executed when the exploit is successful is also embedded in the SWF file in an SWFTag (Figure 2). The payload is 64-bit and was compiled recently on February 4, 2013. The malware family is not new though and we have seen it being used in attacks before.


Figure 2

One of the dropped executable files is digitally signed with an invalid certificate from MGAME Corporation, a Korean gaming company. The same executable renames itself to try to pass itself off as the Google update process.


Figure 3

It creates startup registry entries for persistence after reboot. The malware checks for presence of the AV processes listed below:





It also creates a configuration file under %appdata%config.sys. This configuration file is XOR encoded with the key ‘0xCF’. The decrypted configuration file is as shown in figure 4. It contains the C2 domain contacted by the malware.


It has a unique callback with the keyword “9002” and beacons to the CnC server at


Figure 5

On mining our database we found multiple domains associated with this threat:

The md5′s of crafted document files are listed below:



We will continue to research this threat and provide updates as we find more information.

[Update: February 8, 2013]

Yesterday, we blogged about the new Flash exploit we identified in the wild on February 5, 2013. Since then AlienVault has also published a blog detailing the threat. Peleus Uhley from Adobe published some information on an new feature in the upcoming version of Flash. This feature would identify if Flash content is being run from within an older version of Office that does not have protected mode and warns the user of potentially malicious content before it is executed. Every extra step in making the attackers job more difficult counts.

It is interesting to note, as also observed by AlienVault, that the Flash content and the payloads are not obfuscated or encrypted at all. It is odd and sloppy for a threat attempting industrial espionage.

We continued looking into the payload which is part of this exploit and found some additional interesting behavior. The malware creates a registry entry under “HKEY_CURRENT_USERSoftwareClassessoftbin.” The value of this registry key is a large amount of XOR encrypted data. The key used for this encryption was “0xC4.” The decrypted data is shown in Figure 6. After some initial data in the decrypted content, it contains an embedded executable. This executable contains code for HTTP POSTS as seen in Figure 7.


Figure 6


Figure 7

After allowing the malware to run for an extended period of time we observed HTTP POSTs being generated by the malware. The URI is incremented sequentially in these requests.


Figure 8

The HTTP post data for these requests is the same as shown below. The CnC server is not responding to the POSTS at this time.


Figure 9

[Update: February 12, 2013]

After further analysis we have confirmed that the exploit used in the analyzed documents is  CVE-2013-0634 and not CVE-2013-0633 as originally stated.

This post was written by FireEye researchers Josh Gomez, Thoufique Haq, and Yichong Lin.