Search This Blog

Ring Ø Labs DOES NOT advocate using any of the malware, techniques, or information presented here for harm and doing so may violate the law. These topics are for mitigation and educational purposes only. Read more about us here

Thursday, September 21, 2017

Triaging Malicious Word Document


Today we show how to quickly triage a malicious word document rigged with a VBS downloader and obfuscated Powershell.




WARNING: USE OF INFORMATION IN THIS REPORT FOR ANY ACTION AGAINST A MACHINE WITHOUT THE OWNERS CONSENT MAY VIOLATE THE LAW.



DETAILS

Filename
trin594d.doc
Protection
None
MD5
ea677003262604084a6afc3f459dfba3
Sample
Type
Word Document VBS Downloader
Video



To start today's analysis, we drop the Word Document in a hex editor to inspect the file's header:



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. 



CONCLUSION

This analysis was focused on quickly triaging Microsoft Office Word Documents rigged with VBS macros and Obfuscated Powershell. This is one of the most prevalent methods of downloading malware to a victim machine. Always be on the lookout for unexpected documents even if they're from known senders.


INDICATORS