While today’s analysis will be similar to one we’ve done before, it will be almost exactly the same as this one from SANS. Although it’s been done by others, it never hurts to practice using these tools and get that muscle memory down. We’ll be working off of this document right here: https://app.any.run/tasks/db864efd-35b3-4e91-9e84-c6149dbfd4d7.
Using oledump, we see a big chunk of data called ‘EncryptedPackage’.
In this case, it means that one or more sheets in the workbook have been locked to protect changes to the data.
But there are tools to get around this. By simply pointing msoffcrypto-crack.py at the document, we will see a familiar password pop up.
At this point, we could do one of two things. We could use msoffcrypto-crack.py to crack the password and output a new unprotected file of the same name…
… or we could just pipe the output directly into oledump.py. Doing so, we see that there are no macros or anything like that. Instead, we see ‘eQUaTiON naTIvE’.
Let’s dump that part of the object to another file where we can work on that.
We can use XORSearch.exe to search that binary file for various signatures of 32-bit shellcode. We see that GetEIP was found in two locations.
We then move to a shellcode emulator called scDbg.exe. We can load the dumped binary in there and feed it the offset position and to see if any sort of decoded shellcode appears.
And it does! Note that it dumped it to a file called oledump.unpack. However, notice how the unpacked information isn’t very informative. But that last line says, “Change found at 402438…”. We can use another tool called to cut-bytes.py to look at the oledump.unpack from that point. Notice strings such as LoadLibraryW… ExpandEnvironmentStringsW… APPDATA\vbc.exe… htp://frndgreen and so on.
But can we get this output in a little more… readable form? Yes, we can do with scDbg.exe again. First, let’s cut out only the bytes necessary.
Using oledump-cut.unpack, we do run into a problem when we toss it into scDbg.exe. We don’t see anything beyond ExpandEnvironmentStringsW.
The SANS blog post referenced at the beginning shows how to deal with this. It turns out that scDbg.exe does not hook ExpandEnvironmentStringsW. But it does hook ExpandEnvironmentStringsA. We can then try patching the .unpack file by overwriting the StringsW with StringsA. Save your change and then toss it back into scDbg.exe like we tried above.
Another option is to overwrite that character directly from the command line. Looking at the hex editor above, we can see that we are at offset 0x77. We can add that to the starting point in scDbg.exe like so:
We can now see everything in a much clearer format and it looks like it’s downloading Lokibot.
Thanks for reading!