Exploit targeted

In September Microsoft published information about a new Internet Explorer vulnerability – CVE-2013-3893. The vulnerability affects IE versions 6 through 11 for platforms from Windows XP through Windows 8.1. Later in September, the company released a patch closing the vulnerability.

Cybercriminals are happy to exploit such vulnerabilities because they are easy to monetize – the Internet Explorer remains popular.

Top 5 browsers according to http://gs.statcounter.com

This type of vulnerability is very dangerous because it allows the execution of arbitrary code on the target system. In late September, we discovered an exploit for the vulnerability, which uses an attack of the Use After Free type against the Internet Explorer’s HTML rendering engine –mshtml.dll.

We have recently discovered that a modification of the exploit was used in targeted attacks against a number of high-profile organizations in Japan.

The vulnerability is exploited only on those computers which are part of specific subnets of the target organizations’ networks:

Defining subnets in which computers will be attacked

If a computer’s IP address belongs to one of the ranges defined by the cybercriminals, the vulnerability will be exploited after a user visits an infected web page.

The following information is obtained in the first stage of the attack:

Operating system versionInternet Explorer versionLanguage used by the OSWhether Microsoft Office is installed

The exploit selects the appropriate ROP chain and shellcode based on the data obtained in this stage:

Choice of ROP chain and shellcode

It is worth mentioning that the exploit will not work on those Windows 7 systems which do not have Microsoft Office installed.

Checking OS version and whether Microsoft Office is installed

This is because today’s operating systems include mechanisms that make exploiting vulnerabilities more difficult. One of such mechanisms is ASLR (Address Space Layout Randomization). The exploit uses a clever trick to evade the mechanism: it loads a module compiled without ASLR support into the context of the browser process – the hxds.dll library.

Code after executing which hxds.dll is loaded

The library, which is part of the Microsoft Office package, does not support ASLR. It is loaded at known addresses in memory, after which the attackers use the ROP technology to mark the memory containing shellcode as executable.

The following shellcode is executed after the vulnerability has been successfully exploited:

It can be seen in the figure above that the shellcode decrypts its main part using 0x9F as key.

After decryption, the code searches for functions needed to download and launch the payload, finding them by their hashes:

Hashes of the functions used

When the search for the addresses needed is completed, the following activity takes place:

a malicious object named “runrun.exe” is downloaded from the attackers’ server:

Downloading the payload

Since the module downloaded is encrypted, the shellcode reads it from disk and decrypts it using 0x95 as key, after which the decrypted module is launched:

Decrypting the module downloaded

As mentioned above, the targeted attack used only one modification of the exploit for CVE-2013-3893. At the same time, the total number of modifications discovered to date amounts to 21. Attacks using this exploit have mostly been detected in Taiwan:

We have the following information on the servers from which the exploit’s payload has been downloaded:

A brief analysis of one of the payload’s variants (md5 - 1b03e3de1ef3e7135fbf9d5ce7e7ccf6) has shown that the executable module has encrypted data in its resources:

Encrypted data in the payload’s resources

The executable module extracts the data and converts it to a DLL module:

Extracting encrypted data

The DLL created by converting the data extracted from the payload is written to disk using the following path:
TempPath\tmp.dll (md5 - bf891c72e4c29cfbe533756ea5685314).

The library exports the following functions:

Functions exported by tmp.dll

When the library has been written to disk, it is loaded into the process’s address space and the ishk exported function is called:

Calling the ishk exported function

The library itself performs an injection into another process’s address space.

After launching, the malware communicates to a server in South Korea. The following requests are sent from the infected machine:

Requests sent from the infected machine

Kaspersky Lab detects the payload downloaded as Trojan-Dropper.Win32.Injector.jmli.

We detect the exploit as HEUR:Exploit.Script.Generic.