Red October [Shell Code Analysis]

Hash: 

51edea56c1e83bcbc9f873168e2370af

VirusTotal: 
https://www.virustotal.com/en/file/16d5114b8613f9ebec9dce24ecc16bdf1f9770aa7adc7e60b50c137a2b610613/analysis/


Introduction
This post walks through the analysis of the execution of 2 chunks of shell codes which are part of the file "51edea56c1e83bcbc9f873168e2370af", that lead to the decoding and unpacking of the stage 1 dropper.

Identify, Extract and Decode the First Chunk of Shell Code
After analyzing the byte distribution of the file, you would realize that there large portions of text that are hex encoded strings. Visually inspect the file from top-down, disregard strings that are not repetitive sequences of one or two bytes and disregard strings that are not within the hex encoding byte range (0x0 to 0xF). You should arrive at the first chunk of shell codes at line 105 of the file. Refer to the post Red October [Hex Code Analysis] for more details on analyzing hex codes.

The first chunk of shell code.

Analyzing Shell Code in IDA

Because shell codes do not come in the structure of a PE file, IDA will  treat the file as a binary file and not resolve any functions, imports or exports. It would be helpful to look at the strings, and resolve functions within the shell code; after which you would arrive at the function of interest at 0xF1.

Handy IDAPython script for iterating through unknown/unexplored lines of code, checking if they are bad addresses and converting them to functions if possible. Remember to change the segment name in the first line.
*script was modified from a sample found here

Analyzing sub_F1

Notice the first line of the function sub_F1, it is comparing a value on the stack with the string "T@TP". Note that the values on the stack are stored in little endian, as such, the actual value compared is "PT@T". Remember this string. Now note the "pusha" instruction at 0x13A; this instruction pushes the contents of the general-purpose registers onto the stack (read more here), and is typically done before an unpacking/decrypting routine. 

Function of interest found at 0xF1.

XOR Decoding Routine

After the registers are saved using the "pusha" instruction, the function proceeds to a xor decoding routine at  0x13D, with the xor key being used at 0x165. 

A broad look at the xor decoding loop.

The xor key is 0xB6.

Extracting and Decoding the Second Chunk of Shell Code
Now lets take the information learned during the analysis of the first shell code and use it on the file "51edea56c1e83bcbc9f873168e2370af". Notice that the first chunk of shell code looks for a string "PT@T". This string can actually be found in the file, and is used to mark the offset for the second chunk of shell code. We also know that the second chunk of shell code goes through a XOR ^ 0xB6 decoding routine. 

The string "PT@T" marks the offset for the second chunk of shell code.

Extract and XOR ^ 0xB6 decode the second chunk of shell code.

Analyzing the Second Chunk of Shell Code

Now that we have the second chunk of shell code on hand, repeat the steps taken when analyzing the first chunk - look at strings, resolve functions and then analyzing the functions to determine what the shell code does. Just a note that in some cases, the shell codes may not resolve to any meaningful functions, in that case, you'll have to analyze the assembly code without the logical representations of functions and subroutines. Following the described steps, you'll arrive at the function sub_E0.

Function of interest found at 0xE0.

Analyzing sub_E0

We find a similar flow as that of the first chunk of shell code. The instruction at 0x14A is comparing a value on the stack with the string "iNYD". Note that the values on the stack are stored in little endian, as such, the actual value compared is "DYNi". Follow the function flow and find the "pusha" instruction at 0x218 and subsequently the start of the xor decoding routine at 0x21B and the xor key 0xDE being used at 0x23D.

Note the string comparison of "DYNi" at 0x14A.

XOR ^ 0xDE at offset 0x23D.

Extracting and Decoding the Packed Dropper
Based on the information gathered from analyzing the second chunk of shell code, we can proceed to extract and decode the packed dropper. Find the string "DYNi", extract the bytes and XOR ^ 0xDE decode them to get the packed dropper binary.

Locating the packed dropper.

After extracting the bytes, XOR ^ 0xDE decode them.

You will find the packed dropper file with a suggested name "msmx21.exe".

Remove the first 10 bytes and you will have the result is the packed binary msmx21.exe.

Alternative Approach >> Hex Code Analysis

Next >> Unpacking the Dropper "msmx21.exe"

Red October [Unpacking "msmx21.exe"]

Previous >> Hex Code Analysis

Previous >> Shell Code Analysis

Hash: 
51edea56c1e83bcbc9f873168e2370af (Original File)
2719a0e95075802e22008f7530ea8f99 (Dropper "msmx21.exe" - Packed)


Introduction
This post will walk through the unpacking of the dropper msmx21.exe. Analysis of the binary reveal that the file "2719a0e95075802e22008f7530ea8f99" is likely to be packed. To quickly unpack the dropper, we set break points at VirtualAlloc and start off debugging from there.

Shell Codes
The first memory allocation is a VirtualAlloc of size 0xA34. Here you will find that shell codes are written to that memory location that will be responsible for unpacking the stage 1 dropper.

Memory allocation for shell codes that will perform unpacking of the stage 1 dropper.

Observe the memory region created by the memory allocation for the shell codes.

Shell codes responsible for unpacking the stage 1 dropper are written to 0x30000.

Unpacking of the Stage 1 Dropper, msmx21.exe

Observe the next memory allocation, VirtualAlloc of size 0x6100. Analysis will surface that the shell codes shown above unpack msmx21.exe and write it to the memory location 0x40630.

Observe the memory allocation meant for the unpacked msmx21.exe.

Observe the memory region allocated for the unpacked stage 1 dropper msmx21.exe.

Offset 0x308ca is where the shell codes start to unpack msmx21.exe.

Notice the offset 0x40630, which is the start of the stage 1 dropper msmx21.exe.

Dumping msmx21.exe

The stage 1 dropper msmx21.exe is dumped from memory.

Interesting to note that it was compiled in March 2011.

A peek at the OEP.

Next >> Analysis of the dropper msmx21.exe

Red October [Hex Code Analysis]

Hash: 

51edea56c1e83bcbc9f873168e2370af

VirusTotal: 
https://www.virustotal.com/en/file/16d5114b8613f9ebec9dce24ecc16bdf1f9770aa7adc7e60b50c137a2b610613/analysis/


Introduction
This post walks through the analysis of the hex encoded shell codes in the file "51edea56c1e83bcbc9f873168e2370af" that lead to the decoding and unpacking of the stage 1 dropper.

Analyze the Byte Distribution of 51edea56c1e83bcbc9f873168e2370af

Most of the bytes are within the range of 0x0 to 0x9 and 0xA to 0xF. This indicates that there are large portions of text that are hex encoded strings. 

Visual Inspection
Visual inspection of the file will reveal that the shell codes are actually hiding in plain sight. In this particular file, they are easy to tell apart from the rest of the extra bytes. 

The strings to look out for are:
- strings that are continuous;
- strings that are of a reasonable length;
- strings that only have bytes that are in the range of 0x0 to 0x9 and 0xA to 0xF.

The strings to ignore are:

- strings that are not ascii;

- strings that contain characters that are out of the range of  0x0 to 0x9 and 0xA to 0xF;

- strings that are long repetitions of one or two bytes (eg. 00000000000..., 01010101010101..., EFEFEFEF..., etc).

The analysis steps above will lead you to find 3 chunks of interesting hex encoded strings.

First chunk of encoded hex strings.

Second chunk of encoded hex strings.

Third chunk of encoded hex strings.

Decode the Strings
The chunks of hex encoded strings are decoded using a handy python script. The result is 3 binary files.

Python script for hex decoding.

Analyze the file sizes and byte distributions

The file size of third chunk is significantly larger that the first two chunks and the analysis of the decoded bytes surfaces an interesting fact - the byte 0xDE has the most occurrences, and makes up 25.6%. This suggests that this binary chunk is XOR ^ 0xDE encoded.

0xDE is the majority byte, making up 25.6% of the entire chunk.

Decoding the Packed Dropper
Based on the information gathered from analyzing the bytes, proceed to XOR ^ 0xDE decode the file and retrieve the packed dropper.

Decode using another handy python script.

Remove the first 10 bytes and save the file. 

The result is the packed binary msmx21.exe.

Alternative Approach >> Shell Code Analysis

Next >> Unpacking the Dropper "msmx21.exe"

Zero Access [Terminate Services]

Source: 
http://www.kernelmode.info/forum/viewtopic.php?f=16&t=1713&sid=cd3cc5cbadd7a7c0f917c0929b8df486

Hashes: 
2EFE003B8969FA946F194333152F334C (Original Binary)
9645CD309A01211C8DB323EBFCC44C6B (Unpacked Binary)

VirusTotal: 
https://www.virustotal.com/en/file/8be9b39f78064d454e90b7fead8d51e8e4749e880f1e00b0fd843227b7677bd1/analysis/


Introduction:
Persistence mechanisms refer to any functionality that help the malware continue to operate in it's environment. These include the termination of anti-virus,anti-malware or any process/service that hinders it's operations.

Using DeleteService API to Terminate Services

The following subroutine is part of the function that deletes services (renamed to Mod_Svcs_DeleteSvc). Prior to this function call, the malware will attempt to open a particular service, set the source index (ESI) to it's service handle and call the Mod_Svcs_DeleteSvc function.

The calling function of Mod_Svcs_DeleteSvc iterates through a fixed set of specific services to delete.

Zero Access will attempt to delete the following services:

MsMpSvc - Microsoft Protection Service

Windefend - Windows Defender Service

SharedAccess - Internet Connection Sharing (ICS) Service (affects Windows Firewall)

iphlpsvc - IP Helper Service

wscsvc - Windows Security Center Service

mpssvc - Windows Firewall Service

bfe - Base Filtering Engine Service (required for ESET NOD32 Antivirus & Zonealarm v9.2.X)

Zero Access [HTTP Callbacks]

This summary is not available. Please click here to view the post.

Zero Access [Unpacking]

Objective: 
- To unpack this variant of Zero Access and retrieve the underlying payload for analysis.

Source: 
http://www.kernelmode.info/forum/viewtopic.php?f=16&t=1713&sid=cd3cc5cbadd7a7c0f917c0929b8df486

Hash:
2EFE003B8969FA946F194333152F334C

VirusTotal:
https://www.virustotal.com/en/file/8be9b39f78064d454e90b7fead8d51e8e4749e880f1e00b0fd843227b7677bd1/analysis/


Set Breakpoints at Memory Allocations

• [A] break when memory is allocated for the payload > this will help us determine the size of the payload.
• [B] step to the ret > this will help to determine the starting address where the payload will be written to.
• [C] break after the payload is written to memory and unpacked > dump the unpacked payload.

So we set break points at the LocalAlloc and LocalFree functions and analyze the memory allocations, the address space of those allocations and the contents that were written to those allocations as the malware continued to execute.

@the second LocalAlloc, note the parameters of the call [SIZE = 1E604]:

@the return of the second LocalAlloc, Note the value of EAX [START ADDRESS = 0x16ADE8], the address space 0x16ADE8 is still vacant.

 

@the first LocalFree call, the encrypted payload bytes have been written to 0x16ADE8:

 

@the third LocalAlloc call, the payload bytes are decrypted! Time to take a dump.

 

And dumping the exe.

 

 9645CD309A01211C8DB323EBFCC44C6B