We can see that the file begins with "PK" indicating that this file is a ZIP. In Microsoft Office Terms this means that the document is of the newer ".DOCX" format and not the old ".DOC". In order to get the contents of the file out we can rename the "file.doc" to "file.zip" and open it with any archive manager:
To extract VBS Macros from the document we traverse the archives directory to "word\vbaProject.bin":
Opening "vbaProject.bin" file in a text editor reveals illegible text:
In order to extract the actual script from this binary file, we can use OFFICEMALSCANNER with the following command: officemalscanner.exe ourfile.doc info
Now that we have dumped the VBS script we can inspect it in a regular text editor:
As we can see the script is quite obfuscated, so we can analyze it dynamically in Microsoft's built in Script editor inside Word. This is achieved by going to the Developer tab and clicking Visual Basic. If your Word Program does not have the developer tab at the top, please Google how to enable the developer tab in Microsoft Office. :
Once inside the Visual Basic Editor/Debugger we can pinpoint a few key areas to breakpoint on. The first is a concatenation of two obfuscated variables. After the variables have been deobfuscated this will hold the final result:
It is important to note that in the Visual Basic debugging GUI if a variable is too long, you will not be able to copy the contents from the variables window. This is an annoying feature but it is one we can work around by adding some of our own code. Directly after the concatenation of the two variables we can add "MsgBox(variable_here)".
When we debug this line of code it will popup a messagebox with our variables contents inside:
Now this window is non-selectable, meaning you cannot take your mouse and select the text to copy. However, there is a trick with these types of windows. You can select the window, press "CTRL+C", open a text editor, and paste the text inside. Now we have our long variable's contents.
The second breakpoint should be placed at the very bottom on a variable that uses the ".readtext" method. This is another point at which an obfuscated variable will become legible:
Finally, a third breakpoint should be placed just after a reference to Wscript.Shell. This is an indicator that Wscript is about to execute a command. If we look at the next line the ".RUN" supports our claim.
At this point we can see that the final deobfuscated text is:
This script will be run through the Wscript.Shell object and will first delay execution by issuing a delay through "Ping". This is a common technique to delay execution or implement a pause without using a "sleep" function. After the Ping command is complete, Powershell will launch the script directly after it. This can be launched in Powershell ISE and debugged to get the final output of the obfuscated variables:
In our case the deobfuscated text is stored in the "$ANjUWhho" variable. In order to retrieve the content of this variable we can go to the command window at the bottom of the ISE, type "$ANjUWhho", and press ENTER. This will output the following URLs:
Navigating to each of these URLs we can see that the PHP takes an argument of "f=#". In our testing each of the PHPs accepted the numbers 1, 2, and 3. Each number invoked the site to download an Executable to our machine. Each of the PHPs accepting 3 numbers led to 9 files in total, however, there were only 2 unique hashes for all of the EXEs. These are the final payloads of the VBS downloader.
Email
YouTube
Twitter
Reddit
