Feel free to download the document and play along.
Part 1: Getting through the macros.
My first step is to always dump out the macros and look at them. This is easy enough to do with OfficeMalScanner. Line 16 below shows the ‘Shell’ command being run on three variables (lines 10, 12, and 14). The rest of this macro is 1192 lines that are mostly taken up by function ecJ4XvnDW (line 19). This function is huge and most of it is taken up by complete garbage.
In such a case, it can be useful to make use of the built-in Microsoft Visual Basic for Applications. There we can use it as a debugger to step through the macro and see how it works. It can also allow us to set breakpoints which allow us to skip over the garbage and get to the good stuff.
To do this, we will need to open up the document. We will be presented with the option to “Enable Macros” or “Disable Macros”. In order to use the debugger, we will need to enable macros. HOWEVER, make sure that you do this on a safe system that does not have internet access. You don’t want to go and infect yourself just yet. When you enable macros, you’ll be able to see that mshta.exe is a child process of EXCEL.EXE. Feel free to kill the process.
Once you’ve killed it, go back to the document and press Alt+F11 to open up Microsoft Visual Basic for Applications. You will then be presented with a screen like this:
This is where we can start investigating the macros and see how they run. The debugging feature allows us to do this. If we hit the ‘play’ button (F5), the macro will automatically execute and run to the end. We don’t want that. We want to control the code execution. Looking under the ‘Debug’ menu, we can see the option for ‘Step Into’ (F8). This means that we can run code and it will pause after each line. This allows us to watch what variables are being created and see how it all works. But sometimes stepping through each line one-by-one can take too long. In that case, we can set breakpoints. Breakpoints will allow us to set a point at which the code will… well, break. We can then press ‘play’ (F5) and the macro code will run until it hits a breakpoint.
Looking at the above code, we can see that it all seems to come together at the line that contains Shell(Kd1 + Kd2 + Kd3). It stands to reason that variables Kd1 – 3 will contain some important information. If we set a breakpoint at that line, we should be able to see what information is being fed to Shell(). Setting a breakpoint is very easy. All you need to do is click on the space to the immediate left of the line. A red dot will appear and the line will be highlighted in red.
We can now press ‘play’ (F5). The code will run, making variables, messing around in all of the garbage obfuscation, but we don’t care because we’re going to see the final output.
Looking at the variables below, it is almost trivial to piece them together. This is the command that is going to be executed. It is also the child process that we saw above:
On to part 2!