Uncovering a new MFC downloader

Last July 23, 2015, ThreatTrack's new product, ThreatSecure Network (TSN), uncovered a new sample that was not detected by any major antivirus vendors. Using TSN's unique behavioral determination engine, we were able to tag that a particular sample going through one of our appliances was possibly malicious.

Our engine determined that it performed anomalous behaviors some of which are
   Nonstandard memory operations
   Creates suspended or unsuccessful process
   Sleeps for a long period of time
   Beacons out to remote locations
 
Sample md5: 759c8c5b2b8cf9cd4dcbc1beee1cf3b7

Looking at its internals, the sample is compiled using c++ MFC. Possibly in an attempt to make it harder for analysts to reverse engineer what it does. Delving more deeply and using tools that are on my disposal, I was able to find the function that the MFC calls that performs a malicious behavior.
Initially, trying to find the malicious code is a bit tricky. The sample itself was compiled using MFC.
I could also use IDA and debug it side by side with Olly, but I'm kinda lazy so I just downloaded the .lib files that would allow me to resolve the API names from the ordinals.
Tracing through the calls, I found an interesting API on the MFC42.dll memory space that accepted 5 arguments (Fig 1)

Fig 1

The interesting part here is that this points to an API that would eventually call a function inside the sample we're debugging. Tracing a bit more and we landed on a curious set of codes that does some sort of copying.

 Fig 2

Fig 2 illustrates the snippet of code that copies part of the malware onto the stack and jumps to it. This in itself is malicious, as starting from Windows XP SP2, Microsoft has implemented a technology that prevents data from executing on certain memory locations (DEP).

So what the engine told me about "NonStandardMemory operations" was true. What about the rest?

To make it easier for me, I dumped the parts of code that it copied on the stack, inserted it to a "container" file and launched IDA :) This way, even though it has several levels of encryption, I'll be able to follow the jumps and calls, and tag it while I debug it in Olly. 

Fig 3

Fig 3 Shows that multiple functions that writes code into the  memory process of a suspended thread and after some time, resumes it. This in turns executes another "copy" of it in memory.

Now, this sample contains 2 more executables inside its body which are encrypted. These are the ones responsible for connecting to a remote location, in turn downloading and executing another executable in memory. Doing more research yielded the family connected to this downloader sample was also seen trying for the following remote URLs

89.136.39.204/loader/arisx06.exe (seen inside the sample)

89.136.39.204/arisx06.exe

89.136.39.204/loader/b0be001.exe

89.136.39.204/loader/cclub11.exe

89.136.39.204/cclub02.exe

89.136.39.204/arisx06.exe

89.136.39.204/sdhfjkl.exe

89.136.39.204/pod2/xiitoui.exe

89.136.39.204/pod1/priyo03.exe

89.136.39.204/loader/cclub11.exe

89.136.39.204/mobile7.exe

89.136.39.204/loader/jera001.exe

89.136.39.204/pod1/priyo03.exe

89.136.39.204/loader/cclub11.exe

77.122.146.34/pod2/gavrill.exe

77.122.146.34/gavrill.exe

77.122.146.34/rain003.exe

77.122.146.34/pod1/mobile7.exe

77.122.146.34/suba002.exe

77.122.146.34/loader/cclub02.exe