I was asked for help with this maldoc sample: 394c97cc9d567e556a357f129aea03f737cbd2a1761df32146ef69d93afc73dc.
It can be found on MalwareBazaar too.
Looking at it with oledump.py, we can see the VBA code:
This is the VBA code:
A couple of declare functions for WIN32 API functions.
Filling of an array with hexadecimal values (&H..):
And then calling the WIN32 API functions:
Let me translate their meaningless names into something more understandable:
And now we see MultiByteToWideChar is called. Remember, for later in this analysis, that its first argument is 65000.
Let’s grep for the 32-bit code:
And decode the hexadecimal data with re-search.py:
There are some NUL (0x00) bytes in there that we need to fix, since they only take one hexadecimal character:
And now we can convert this to binary:
This throws an error because of a character that can’t be encoded. I’m just going to ignore errors, and see where we end:
This is very interesting: binary data followed by source code (assembler). This is probably a mistake by the malware authors, they’ve appended part of the source code to the binary shellcode.
I will save this shellcode to disk, and analyze it with scdbg:
The shellcode executes and crashes after 3332 steps. The analysis report doesn’t find anything in memory.
Let’s try with the 64-bit shellcode:
This shellcode has decoded itself into memory. Let’s dump it and take a look:
And here we see the URL (the protocol is a bit obfuscated, this could be the result of the UNICODE translation error I ignored).
Turns out that this is a sample from APT-C-35, according to this blog post (I found it by searching for MyAssemblyMacrosMain which appears in the leaked source code).
And I will need to figure out why scdbg was able to analyze the 64-bit shellcode and not the 32-bit, because IIRC, scdbg doesn’t handle 64-bit shellcode …
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.