With the potential threat of trying to come up with presentation material (still not sure I want to brave the stage,) I decided to try and make a macro document Dridex infection chain work locally (so as to not rely on URLs that don't live for a full 24 hours) and as a result ended up learning a lot more about the behind the scenes of the sample I was playing with.
First off, to step through the macro code, we'll need more than just oledump. The easiest way to step through a macro, is within Word's own developer tools. However, most threat actors password protect their macros (big shock, eh?) Fortunately, there's a VERY easy workaround. Simply load the document in a hex editor of choice, search for DPB (or the bytes 44 50 42) and change it to DPX (or 44 50 58). Then open the document, load developer tools (alt+f11), click past the errors, right click on the project, select properties, project protection, then uncheck "Lock project for viewing" save, re-open, and viola!
The next step is enabling macros, otherwise Word won't let you step through it. This can get dicey, since enabling the macro will also run it when you open the document. I get around this by disabling the network adapter until the macro times out.
Now we get to the fun parts. Stepping through and modifying the code to allow local file use. Initially I was trying to use literal local files (e.g. "C:\Users\User\Desktop\malfile.txt"), but trying to rewrite the function that normally uses an object.response() call on an HTTP request turned out to be a Royal pain. I pretty much had it, and realized my error, but then after sleeping on it, I came up with a much more elegant solution. Host the files on a different VM with python -m SimpleHTTPServer, then modify the macro code to simply call those URLs. Works like a charm!
So, as we step through, there's a lot of junk, and random functions and variable assignments that serve no purpose except to make things look confusing and possibly change the signature of the file. The first important part to look at (in this sample) is where the first URL gets set.
As we can see in the code above, I've already modified it to use the text file hosted on my local machine (although I forgot the port :8000). Originally it set PBIn = STT1 + CDDD + TSTS, which from the above code is pretty easy to see what it's doing.
The next part of code to edit, is where it sets the URL for the second file pull. This file (rara.txt) simply contains a dropbox link that downloads an executable file. I had already pulled this file down, and so set the link of rara.txt to be "http://172.16.2.138:8000/ose08.exe" instead of the dropbox link.
Now, in this sample there are some Module2.Crispy(1) calls which are nothing but delayed time wasters, if you're stepping through the code, you can just comment them out with a single tick.
There comes a function that simply parses out the text of a variable (which was set to the text of the first file we downloaded, the 7777etc.txt file), set a breakpoint at the first line after the loop, and hit continue. It's splitting up the text file into two separate files, a .vbs and .bat script. The .vbs script is responsible for using the link found in rara.txt to download the executable, and the .bat executes it and does some cleanup, removing the scripts from disk. The function that calls them passes the file path of the script file to Shell(filepath, 0).
Lastly it runs some junky code that basically hangs Word. Why it does this, I'm not entirely sure, but I suppose it's already done its job.
There's also this interesting "hidden" white text in the body of the document, but near as I can tell it serves no purpose. Perhaps the .exe uses it at some point for unpacking or something. I'll try reversing the .exe some more later.