How exploit packs are concealed in a Flash object

One of the most important features of a malicious attack is its ability to conceal itself from both protection solutions and victims. The main role in performing a hidden attack is played by exploits to software vulnerabilities that can be used to secretly download malicious code on the victim machine. Generally, exploits are distributed in exploit packs which appear in the form of plugin detects (to identify the type and version of software installed on the user computer) and a set of exploits, one of which is issued to the user if an appropriate vulnerability is found.

Recently, we have come across a new technique used to hide exploit-based attacks: fraudsters packed the exploit pack in the Flash file.

Downloading an Exploit

The standard technique used in a drive-by attack is to compromise a web site with a link leading to a landing page with the exploit pack. From there the pack uploads the necessary exploit onto the user computer.  From the point of view of security software, this unmasks all the components of the exploit pack because they are simply uploaded onto the landing page. As a result, the exploits and the plugin detects are visible in the web traffic. The criminals must mask each component separately if the attack is to go unnoticed.

The unconventional new approach with the Flash package is definitely more efficient for criminals. The standard landing page is missing. The user follows the link to get to a page with a packed Flash object that turns out to be the exploit pack and the configuration file in an image form. The packed Flash file with the exploit pack is loaded to a page in the browser and has the right to write to and modify the page, i.e. it can add exploits to the page which will then be executed.

Let us look into how this works, using the Netrino exploit pack as our example.

This is what the packed Flash object looks like:

The packed Flash object (exploit pack)

This is how it looks after de-obfuscation:

The Flash object (exploit-pack) after de-obfuscation

The packing is supposed to prevent the malicious object from being detected. A Flash object like this is not opened by most popular deobfuscators. For instance, SWF Decompiler freezes and then reports an error.

The results of using a popular deobfuscator on the Flash object of the Neutrino exploit pack

The Flash object is written to a page in the user’s browser with the parameter allowscriptaccess = “always” – this allows for the page to be modified, even if the object was loaded from a different domain. Although Flash objects rarely require page modification rights, there is nothing very unusual about this option and indeed a lot of legitimate Flash content is loaded this way. With this privilege, the malicious Flash object simply writes exploits to the page from its binary data.

Thus, there is no malicious content in the web traffic or on the page delivered to the browser. The malicious content is hidden behind a good packer, and the exploits emerge while a page is processed by the browser.

Contents of the Flash object

Let us have a look at what the analyzed Flash object contains, and what it writes to a web page. After unpacking, we see six embedded binary objects. These binary objects are coded with RC4, and some are also compressed with the standard ‘deflate’ algorithm.

The encoded binary objects within the Flash object

Here is how one of the objects is decoded and delivered:

The code for decrypting and adding the exploit to a page

Other objects are decrypted in a similar manner.

Let us summarize the binary objects contained in the Flash pack:

• An exploit for the CVE-2013-2551 vulnerability in Internet Explorer



The exploit for the CVE-2013-2551 vulnerability

• A malicious DLL which is also part of other versions of the Neutrino exploit pack (discussed later in this article).
• Two exploits for the CVE-2014-6332 vulnerability in Internet Explorer’s VBS processor:




Exploits for the CVE-2014-6332 vulnerability

• An exploit for the CVE-2014-0569 vulnerability in Adobe Flash



The exploit for the CVE-2014-0569 vulnerability

• An exploit for the CVE-2014-0515 vulnerability in Adobe Flash



The exploit for the CVE-2014-0515 vulnerability

By the way, there is no plugin detect for Adobe Flash exploits in this exploit pack. ActionScript tools are used to check the version of Adobe Flash. Adobe Flash versions that can be attacked using exploits are hardcoded in the Flash-pack code:

In the most recent versions, modifications were introduced into the Flash pack. These include adding another exploit for the vulnerability CVE-2015-0536 in Adobe Flash.

The configuration file

Let us have a look at one interesting function in the Flash pack.

It should be remembered that an image (a configuration file) is posted on the landing page alongside with the Flash object.

The image posted on the page

A special function reads this image from the landing page, decodes its Base64 and RC4, and thus obtains the configuration file.

The function for obtaining the configuration file

The configuration file contains the keys and identifiers of the exploits discussed above, which are available for the user to download. The availability of the configuration file gives some flexibility to the cybercriminals: they can specify the best settings for its operation at each specific period of time without changing the exploit pack itself. For example, they can specify priority exploits or separately keep the keys with which to decrypt the objects within the pack.

The configuration file decrypted from the image

In the later versions of the Flash pack, however, the configuration file is part of the actual exploit pack rather than a separate picture.

Implementing the payload

The shell-code of one of the exploits is a VBS code with binary code in a string, which is executed by the exploitation of the vulnerability CVE-2014-6332 in Internet Explorer’s VBS processor. As a result, the file shell32.dll is loaded to the folder “%temp%/System32/.

The name and the path of the loaded file are similar to those of regular Windows DLLs. Using the regular DLL hijacking technique, one can go without using the functions run, start, open etc., and thus mask the launch of a malicious DLL from the security product.

Using DLL hijacking shell32.dll

The exploit modifies the environment variable SYSDIR and attempts to load System.ShellApplication – this launches the malicious DLL.

The launched DLL is a dropper which loads the script”p.js” to the victim’s computer and launches it.

The main part of shell32.dll code

The launched p.js script

This script is the loader of the principal malicious file.

Distribution

The version of the Flash pack described in this article emerged in late 2014 and was actively distributed in Q1 2015. There were also new modifications of the Flash pack, but their basic working principles didn’t change.

It wasn’t until March 2015 that we observed Neutrino Flash pack attacks on the computers of 60,541 users. On average about 2,000 users were attacked every day; on certain days, the number of potential victims reached 5,000 to 6,000.

The number of unique users attacked by Neutrino Flash pack

This exploit pack is predominantly used to attack users located in the USA and Canada.

The geographic distribution of Neutrino Flash-pack attacks (as of March 2015)

Conclusion

The idea of use a Flash-pack to distribute exploits is relatively new and it has proved fairly successful for cybercriminals. Existing Flash properties allow them to pack the exploit pack into a Flash object and conceal it with an obfuscator. The Flash capability to specify website access parameters then allows them to write exploits to a webpage in the user’s browser. The exploit-pack’s components are not found in the web traffic, nor in the loaded page.

Although the malware writers are constantly updating the exploit-pack and introducing modifications into the code of the malicious Flash pack in order to prevent security products from detecting it, Kaspersky Lab responds promptly to these threats. Alongside regular protection methods, Kaspersky Lab’s products use a special “Anti-Exploit Protection” (AEP) component, which detects this threat with the help of behavior analysis.

Kaspersky Lab’s products detect this Flash pack under the verdict HEUR:Exploit.Script.Blocker, HEUR:Exploit.SWF.Generic.