Hacking

Hunting for “Red October”: Cyber-Espionage Toolkit Exploded

Introduction

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

"Red October" appears to be a cyber-espionage toolkit discovered quite recently by Kaspkersky's laboratories. The viral code seems to have targeted government agencies and institutions based in Europe, ex-USSR countries and countries in Central Asia. The malware is still active, and it's currently gathering data that is sent to multiple C&C servers. For the level of complexity, its malicious code is compared to the already famous "Flame Virus" and is spread via phishing emails directed exactly to selected potential victims.

"Red October" exploits different vulnerabilities for Microsoft Word and Excel and, if the attack is successful, a Trojan-Horse is dropped on the infected machine, seriously undermining the confidentiality of the data stored in it. Researchers believe that the attack has been active for a minimum of five years, based on PE timestamps and C&C domain names' registration dates.

This paper tries to dig deeper into the actions of this malware. The version in the possession of the analyst is spread through a Microsoft Word ".rtf" document and, for the infection of the victim, tries to exploit the vulnerability described in CVE-2012-0158 (http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0158).

Preliminary Analysis

Preliminary analysis led to the identification of an ".rtf" document which presents, inside of it, hex-encoded code snippets that would later be executed in case the exploitation of the vulnerability was successful. The first step taken by the analyst, for the analysis of this malware, has been the isolation of the first piece of useful code. This is basically a hex-encoded code used to find and decode the second set of instructions. In order to find where to start decoding, a branch instruction is used and, in the moment in which the string "PT@T" is identified, the "XOR" decoding loop begins.

An image is shown below for the first isolated hex encoded code (the output is truncated due to space reasons):

In summary, the analyst has been able to retrieve the first complete instruction executed, converting the payload in a format more easily analyzable. Basically, the instructions carried out here points to the decoding of the second set of code, which is also present in the document as hex-encoded text. The particularity of the second piece in fact, is that it presents some form of protection mechanism, which has been recognized during the analysis of the first piece of instructions.

The image shown below is a picture of what the second piece of isolated code looked like:

The analyst, through the instructions analyzed in the first segment of code, wrote a few lines of Python code in order to automate the process of recovery.

This second piece of hex-encoded code is in fact de-coded using a BYTE-BYTE decoding loop through a "XOR al, 0B6h" instruction.

He then proceeds to recover the original code of the second set of instructions.

The software created for this occasion fills a file named "dexor.txt" with the instructions of the original code, and converts back them to hex format.

At this point, the analyst again converts the hex data in a format more easily analyzable, and, by analyzing the second piece of code, concludes that the instructions executed are very similar to the previous, with the difference that this time, the dropper of the real malware will be decoded.

Bypassing Dropper Code Protection

As mentioned above, the instructions executed by the second piece of code present within the vector of infection (.rtf file) are similar to those performed previously, with the difference that this time the decoding is performed with a different key, and the dropper of real malware is also decoded.

The following represents an image of the second decoding loop:

Based on the information obtained in the analysis of this code, the analyst goes to retrieve the set of original instructions of the Red October's dropper.

This time, the file is saved clearly.

Here is a snippet of the resulting file:

We can now analyze it more easily.

EP is located at 0x4118A4 and the dropper appears to be protected by some custom packer/encrypter.

The analyst continues tracing the instructions step by step. The first of these to be carried out concerns the dynamic linking of some useful functions through the call "GetProcAddress" at sub_413FCF…

…to arrive, finally, after further instructions considered minor, at calling "VirtualAlloc" to allocate a region of memory in its own address space in order to execute the unpacked binary, which is visible in the next image.

The dump of the used memory region is performed by the analyst in order to recover the original executable.

After doing this, we can also collect some additional information about it.

Finally, we are going to begin analysis of the dropper's code.

Dropper Analysis

EP is located at 0x403910.

The first action conducted by the dropper is deleting some registry entries at sub_4038A0.

Registry keys deleted are:

"HKCUSoftwareMicrosoftOffice11.0WordResiliencyStartupItems"

"HCKUSoftwareMicrosoftOffice11.0WordResiliencyDisabledItems"

After retrieving strings of environment variables, the dropper goes to execute its main function: the creation of files called "svchost.exe," "wsdktr.ltp" and "msc.bat."

The main subroutine responsible for retrieving names and folders of the "svchost.exe" and "wsdktr.ltp" files that will be created is located at 0x402430.

Inside this, another function, located at 0x401570, is called for actual file creation.

The first file to be created is "svchost.exe" under the "%programfiles%Windows NT" path…

…and the following buffer, located at 0x9b5e28…

…is written into it.

Finally, a 206 KB large file is created.

The second file to be created is "wsdktr.ltp", which is always under the "%programfiles%Windows NT" path.

74556 bytes are written into it.

The buffer is located at 0x9e98a0.

Finally, a 75 Kb large file is then created.

At this point, a sub located at 0x4019D0 goes to launch the svchost.exe through the CreateProcess function call.

At 0x401D40, a msc.bat file is created.

310 bytes are written into it.

The content that is written onto this is the following:

chcp 1251

:Repeat

attrib -a -s -h -r " previously recovered dropper path "

del "previously recovered dropper path"

if exist "previously recovered dropper path " goto Repeat

del "previously recovered msc.bat path "

Dropper sleeps execution flow for 10 seconds.

Msc.bat is also started through the CreateProcess and ResumeThread functions.

After executing these instructions, the dropper ends its work flow.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

The next steps that will be taken will be analyzing the instructions executed by the svchost.exe, which were previously created under the "%programfiles%/Windows NT/"
path. This file will also be protected by a customized compression mechanism. As we shall see, this file will subsequently decrypt the content of "wsdktr.ltp."