Obfuscated Flash Files Make Their Mark in Exploit Kits

In recent years, we noticed that more and more malicious Adobe Flash (.SWF) files are being incorporated into exploit kits like the Magnitude Exploit Kit, the Angler Exploit Kit, and the Sweet Orange Exploit Kit. However, we did some more digging and found out that the number of Flash files isn’t the only thing that has changed: these files use obfuscation techniques than files from two to three years ago.

Antivirus evasion is the primary goal of obfuscation. SWF files use obfuscation techniques to avoid detection by signatures and by emulation. While there are numerous obfuscation techniques, I will discuss four techniques that are commonly used and found in exploit kits.

String Replacement

In this technique, key data may be disguised as strings, which will be processed by the String.substr and String.replace APIs. If the data is numeric, it could be translated from the parseInt function.

Figure 1. Sample strings

Figure 1 comes from a sample of the Sweet Orange Exploit Kit. In this screenshot, the data is hidden in strings such as FRE2325D5E0CC4. This particular data is a memory address, used in malware code.

Special address values could also be hidden in strings that would be processed dynamically. Such a method could be used to evade signature detection by way of checking information in the constant pool. The constant pool saves important information that could be used by Flash Player—which can be used as a detection method.

Figure 2. Sample strings

In Figure 2, the value of _loc23_ is 0x9FRE2R9FRE2R9FRE2R9FRE2R. In reality, the value of _loc23_ is actually 0x90909090, which could be used as a NOP instruction in shellcode. The NOP instruction is often just a placeholder but this is often used in heap spraying. Thus, one simple detection technique would be to check for the value 0x90909090. Replacing it with 0x9FRE2R9FRE2R9FRE2R9FRE2R is a way of avoiding detection.

Array-based Embedded Flash

In this type of obfuscation, the malicious SWF content is stored in an Array object, which is built in a sub function, such as the function cartd() in the screenshot below. If they analyze the decompiled code, security products will not detect any malicious behavior (as the malicious SWF content did not load).

Figure 3. Sample from the Fiesta Exploit Kit

In Figure 3, the embedded SWF content is saved into the Array object. Once the array is deobfuscated, the content is decoded and the embedded SWF content is loaded by the loadBytes API.

This sample also displays the string replacement technique. The strings writeUnsignedInt and addEventListener are used in decoding obfuscated data in SWF content. Here, they are processed via string concatenation. String concatenation is the process of appending one string to the end of another string. It would be hard to find evidence of malicious routines via string matching as concatenation would result in modified strings.

Control Flow Obfuscation

This type of obfuscation changes the control flow by the goto instruction. Control flow refers to “the order in which the individual statements, instructions, or function calls of an imperative or a declarative program are executed or evaluated.” Changing the control flow makes it difficult to literally read and process the malicious Flash file in p-code detections.

Figure 4. Changes in flow of code in the sample from the Angler Exploit Kit

Obfuscation in DoSWF Packer

As one of the more well-known exploit kits, the Magnitude Exploit Kit uses highly obfuscated malware. In this particular sample, it’s packed by a commercial Flash packer named DoSWF. A close look shows that the obfuscated data (the embedded .SWF file and some control data) is saved in the binary data tag.

Figure 5. Malicious SWF file saved in binary data; highlighted portion is the trademark of the packer used

The code below is used to extract content from the binary data shown in Figure 5. Here, ZG is a ByteArray that represents the obfuscated data. It defines its own memory domain—the Flash file runtime environment—by using flash.utils.ByteArray. Modifying its domain not only makes it harder for AV products to detect it but also make it easier for the malware to perform its routines. It then uses op_li8/op_li32 to use direct memory access through the avm2.intrinsics package. These could be used to evade emulators as most VM software do not implement these instruments. The intrinsic instruments are implemented by Tamarin, which is the ActionScript Virtual Machine (AVM) in Adobe Flash Player.

Figure 6. Code used to extract the binary data

Looking at the uncompressed data, we can see that some garbage .SWF files will be created in memory, which can disturb memory searches and make it harder for products and researchers to find the malware. It will then load the malicious .SWF file by calling the loadBytes API to execute the said file.

Figure 7. Garbage files generated

The Future of Flash Files

We predict that we will continue to see malicious Flash files be used in exploit kits. As Flash packers can easily obfuscate SWF files easily, we can predict that these will be used more in cybercriminals’ schemes. Of course, the increased use of Flash packers could also mean more difficulty in detecting the malicious files.

Trend Micro detects and blocks the malware (detected as SWF_EXPLOYT.MJE) mentioned in this entry.

Hashes for the samples mentioned in this entry are as follows: