Reversing A Malicious Office Document — Part 02

In Part 01 we tore apart a new Emotet variant’s malicious Office document dropper file, this time in part 02, lets take a look at the binary that’s downloaded by that Office document.

File MD5 — ee15dbb42e1c2d8f5b3e2a8558994d54

The first thing I started with when analyzing this file was checking its strings, usually strings are obfuscated, but its worth a shot. In strings, two things stood out:

In the first image above, we can see a file name called yahavSoduku.txt, yeah… I doubt they are playing Soduku (Sodoku, whatever it is) with this binary, so lets keep an eye out for that. And second, in the second image we can see the names of dll’s and some functions of importance.

If we go to the single reference to the kernel32.dll string, we can see they are using CoLoadLibrary to load the kernel32 function VirtualAlloc, as it is not listed as an import in the import table.

Lets run it through IDA and see what we can find…

The first thing that really stands out when running this through IDA is the attempt to load a DLL that does not exist at least on my sandbox.

Also near by in the instructions we see it looks to load SC.exe, which exists in System32 normally. If this fails to exist, it calls exit process, so this may be utilized as an anti analysis technique.

In both images above, we can see just before the JNZ instruction the TEST instruction is performed checking to see if RAX is null indicating whether or not the dll/exe exist on the system.

A little further down we come across a loop over some what appears to be obfuscated code, this is probably important so lets keep our eye on this data.

In the image above you can see the instruction LEA to load the long string into RCX, if this is followed we see it eventually call the value loaded into RAX as shown below.

Following this, we see what we expected, a bit of shellcode loaded that IDA does not recognize as a function.

Following this code, we come across VirtualProtect and some other dll’s being called, indicating we may have code injection occurring. Here below we see the call to qword ptr [rbp-18h] which points to the VirtualProtect function.

This is generally something important to keep an eye on, as it should give us an idea where the code injection is occurring. If you take a look at RCX, we can see the value it was passed for protection to be changed to RWX (read/write/execute). More information on the x86–64 bit calling convention for Windows can be found here.

So with this, we can see 0x18002F000 is where the protection was set to RWX, if we continue on a little more, once the memory is committed, we can see a call to a section of this memory.

And if we look at where it specifically is calling, we can see the following.

If we start up ProcessHacker we can see that address space contains a PE, so this is exactly what we were anticipating.

This binary was a giant pain in the butt to tear apart, mostly because it did a lot to hide what it was doing, with a lot of obfuscation and red herrings leading me in all different directions as the authors intended, if you recall from our first areas of interest listed in the blog post. In our next post, lets take a look at this injected code and see what its doing.