We are presented with a Word document that has macros. The VBA code for the macros is obfuscated but we can clearly see that it is using some interesting Win32 API calls like VirtualAlloc and CallWindowProc, which later renames.

Thus, we can just set a breakpoint on the renamed CallWindowProc function to trace shellcode. (This is explained more in depth by the Minerva guys).

Shellcode

The shellcode first resolves LdrLoadDLL:

Then resolves Kernel32.dll

Resolves ExpandEnvironmentStringsA:

And calls it with %TMP%\\bg618.exe.

Then resolves CreateFileA, VirtualAlloc, VirtualFree and CreateWindowProcA, ReadFile, CloseHandle and stores them on the stack.

Payload

Payload analysis

I suspected payload was ending prematurely (before contacting C2). This was backed up by the fact that the payload does not import any WININET functions. So I did set up a breakpoint on CreateProcess (it seemed like a good candidate to start with).

To what is it doing process hollowing is not very important, we can dump the injected buffer to a file instead. The address of the written buffer can recovered from the eax register after the VirtualAlloc call.

As we can see it already has a PE header but no content (all zeroed lower down the section). At the end of the WriteProcessMemory loop should be fully written, so we can breakpoint there and dump the memory map.

Further considerations

Even easier, if function is statically analyzed we can realise that the injected buffer is passed to the function as the second parameter, so we can also grab it from there.

Next we can investigate how this function is called. There is only one calling function - WinMain.

From this function we can gather that payload is stored as a PE file resource and then XORed against a hardcoded value. It also has some performance checking and based on that it decides wether to use a XOR key or another. Funny thing is, both referenced XOR keys are actually the same for this sample.