This document came slip-streamed as a reply to a previously existing email conversation. I’m always surprised when a malicious document isn’t Emotet and this was no exception.
Also, shout-out to @malwaresoup for help with the macro and pointing me in the right direction!
Part 1: Quick overview
Extract the macros however you see fit. I’m always a fan of OfficeMalScanner. However you get them, I noticed that the main macro commands weren’t obfuscated at all. We can see that variable s contains a large string of some sort. But it is rather strange that everything else is out in the open.
A quick attempt at behavioral analysis doesn’t give much information either. There was no powershell.exe or cmd.exe processes spawning from WINWORD.exe where we could quickly grab a command line or two. WmiPrvSE.exe wasn’t used in any way, either. This just means we’ll have to do a little more work in order to understand what variable s is hiding.
Part 2 – Unlocking document
To investigate the macros and see what they’re doing, we can open the document and press Alt+F11 to open Microsoft Visual Basic for Applications. Double-clicking on the project shows that it is locked.
Remember, this means that the vbaProject.bin file inside the malicious document is password protected. I wrote before on the steps to get around this here. Basically, it involves changing the document to a .zip file, copying the vbaProject.bin file elsewhere, editing the .bin file with a hex editor, copying the edited file back into the appropriate .zip folder location, and finally changing the extension back to .docm.
You’ll see some errors pop up when you open the document, but they’re safe to ignore. Hit Alt+F11 again to get back to the project. Right-click on it, choose Project Properties, and uncheck “Lock project for viewing”. Save your changes, re-open the document and you should be good to continue.
Part 3 – Macros explained
The main portion of the macro is below. This is where string s gets transformed and then executed. How exactly does this work? Please, correct me if I don’t get this right.
Line 249-250: Take characters from s two at a time; prefix them with “&H”; Val() transforms it to decimal; subtract that from 255; add to array called s1.
Line 257: This line is interesting. “VarPtr will always return the address to the content of the variable itself. What is stored there depends on the type of the variable…” So this command is finding the memory address of variable s1.
Line 258: vp is short for VirtualProtect. This command “changes the protection on a region of committed pages in the virtual address space of the calling process”.
Matching this up with what we see, lpAddress is the location of s2, dwSize is 2000 bytes, and flNewProtect is 64. 64 is 0x40 in hex, which means that memory space is set to Page_Execute_ReadWrite. Lucky us!
Line 259: SetTime creates a timer. In this case, the time-out value is set to 10 milliseconds and the function to be called is located at s2.
Line 261: DoEvents will “yield execution so that the operating system can process other events.” It seems to me that other event will be the one located at s2.
Part 4 – Extracting shellcode (almost)
So what exactly is living at the address space listed in s2? In this case, the memory address in s2 is 236183625. Translate this to hex and you get 0xE13E049.
ProcessHacker allows us to look at the memory space used by WINWORD.EXE. Digging down into address 0xe13e000, we can find the beginning of what is stored in 0xe13e049. We can then save this data out to a file and inspect it at our leisure. I’m warning you that it isn’t very pretty.
@malwaresoup suggested to attach a debugger (Ollydbg, x64dbg), set a breakpoint at 0xe13e049, run the code up to that point and dump the output… but I haven’t gotten to that yet. Maybe later. Although, if you inspect what gets dumped above, you’ll sort of see the URL for what gets called next. However, it is a bit jumbled up.
Part 5 – After the document
Way back at the top, I had a link to the document we are investigating. It showed one single connection to 18.104.22.168. Looking at that IP in VirusTotal, we only a few hits (at the time of this writing).
Thanks for reading!