Saturday's diary entry "VelvetSweatshop Maldocs" is a reminder that Excel spreadsheets encrypted with password "VelvetSweatshop" are opened with Excel without prompting the user for a password.

The streams inside the ole file do not contain macros, but there is a stream with name 'EqUATIoN NATiVE':

Peeking at the content of this stream, I see that it starts with 1C00:

This is the size of the "Equation OLE" header, as I explained in diary entry "Dissecting a CVE-2017-11882 Exploit". Such exploits can contain a short command, or shellcode. Looking at the strings, no command can be seen:

There's not a single intelligible string, not even a URL. It's probably encoded shellcode. This time, instead of dissecting this exploit like I did in the diary entry I mentioned earlier, I'm trying to find the shellcode quickly with xorsearch. Option -W uses xorsearch's build in signatures to find 32-bit shellcode:

At position 0x75, without any encoding (XOR 0x00), a typical get EIP shellcode instruction was found. I'm going to test if this is indeed shellcode with the shellcode emulator scdbg. For this, I need to store the shellcode inside a file:

And then I can try the shellcode emulator (-foff 75 sets the entrypoint of the shellcode: offset 0x75 was found with xorsearch):

This confirms that I found shellcode. First this shellcode calls GetProcAddress to lookup the address of ExpandEnvironmentStringsW (passed as a string argument), and then it calls ExpandEnvironmentStringsW. The emulation stops here, as the shellcode emulator does not hook this API call (e.g. it does not support this API call).

The shellcode has decoded itself, and string ExpandEnvironmentStringsW was decoded. I can dump the decoded shellcode to a file with option -d:

The decoded shellcode is written to file shellcode.unpack, and (most likely) starts at decimal position 833, because that's where the shellcode was modified:

And indeed, I can see many ASCII and UNICODE strings in this decoded shellcode (including ExpandEnvironmentStringsW):

I see a filename (%PUBLIC%\vbc.exe) and a path (/dfxjj), but no URL, domain name or IPv4 address. It's clear from the strings found in this shellcode, that it is a downloader. But I need to figure out from where it downloads its payload. I continue my shellcode analysis, first I extract the modified (decoded) shellcode:

This is indeed shellcode:

The emulator stops at the call for ExpandEnvironmentStringsW, because this API call is not hooked. I'm checking this: option -hooks lists all hooked calls:

Grepping for string "expand", I confirm that ExpandEnvironmentStringsW is not hooked, but ExpandEnvironmentStringsA is:

ExpandEnvironmentStringsW is the UNICODE version, and ExpandEnvironmentStringsA is the ASCII version. I'm going to use the following trick: I'm going the replace string ExpandEnvironmentStringsW with ExpandEnvironmentStringsA in the shellcode. In real code, this would not yield the result wanted by the malware author, but with this emulator, I hope it will continue running and this might give me then more information to figure out what this shellcode is doing.

I can patch the shellcode in memory before execution. First I need to figure out to position of character W:

It's at hexadecimal position 0x77: I'm using option -wstr to overwrite W with A, and then emulate the shellcode:

My trick worked: although the environment variable expansion didn't work, the emulator continued with its emulation, and I can now see that this downloader connects to host gg[.]gg and requests path /dfxsv.

This was actually right in front of my nose when I looked at the strings of the decoded shellcode, but I did not recognize the string for domain gg[.]gg:

This shellcode downloads from hxxp://gg[.]gg/dfxsv, it's an URL shortener:

The downloaded PE file is TrickbotLokibot.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com