CryptoWall 3.0

This post presents an analysis for a sample of the crypto-virus known as CryptoWall 3.0. 

.::[ ARTIFACT CHARACTERISTICS

Table 1 shows general information about the analyzed binary.

Table 1: Artifact General Information

Characteristic	Value
File name	sample1.xxx
MD5	15914886232c164bb2521af59aa0e06e
SHA1	cdff1327225a6a721e32f204ad1e4eb3a4a1d44e
Size	220 KB
Binary type	PE
Architecture	x86
Bits	32

.::[ GENERAL DESCRIPTION

The analyzed sample represents a variant of the CryptoWall malware delivered as payload by Angler Exploit Kit. There are some more elaborated analyses about this malware around the Internet [1][2][3]. 

CryptoWall is categorized as a ransomware by most anti-virus technologies. Its main behavior is: 

• run some "anti-debugging" techniques (e.g. verifies if the caller process is Perl or Python);
• deactivate native OS protections;
• deactivate backup and file snapshotting policies;
• start communication with C&C server;
• generates a temporary crypto key for each request;
• Uses this key to encrypt (RC4) the communication between the infected machine and the C&C server. This key is passed as parameter inside each HTTP request;
• sends an unique identification of the infected machine to the server (called "CUUID");
• the server sends back a public key and an unique image used to link the infected machine to its server side session;
• this process uses this public key to encrypt specific files inside the disk of the victim (according an extensions table);
• the malware redirects the victim to a web page where the user can pay (in Bitcoins) to obtain the private key and recover the encrypted files;
• the malware deletes itself (files remain encrypted);

Once the amount requested is paid the user receives a private key which can be used for recovering the encrypted files. 

Fireeye - FlareOn 2015 (Challenge #4), Relocation Table and ASLR

Continuing the series of posts about the FlareOn reversing challenges 2015 [1]. If you interested, you can find my previous post with solutions for the first three challenges here [2]. 

I had some "extra work" due to infra-structure issues during this challenge and ended up learning new things. So I decided to dedicate a whole post for the challenge #4 not only explaining the solution but also explaining these issues. 

.::[ PREAMBLE

As the previous challenges the objective in this task is to recover the flag (an e-mail address) from a PE-32 binary file. The main insight for this challenge is that the binary was packed using UPX [3]. There are many ways to raise evidences that a binary was packed using UPX, the main is to examine sections. We could obtain this information using rabin2 by the following command. Figure 01 shows the sections labels for the analyzed binary.

Figure 01: Sections information for analyzed binary.

As we can notice there are 2 sections (marked with the red rectangles) called "UPX0" and "UPX1". These sections are used by UPX to store compressed data of the original binary.