Press "Enter" to skip to content

Analysis of Password Protected Malicious Word Document

Last updated on April 23, 2021

Let’s take a look at an example of a malicious Word document that has a password-protected VBA project. When looking at malware, it is a good idea to first verify the file type you are looking at. Many malware authors will purposely use deceptive file extensions to try to look as benign as possible. So, running the “file” command on the file, it is confirmed to be a Word document, as the extension suggests.

"file" command output

Our next step is checking the streams for macros using The following three streams have macros in them, indicated by an uppercase “M”.

oledump streams with macros

Searching for an “open” statement as the entry point, we find an “autoopen” function, which calls the function “mainaletic” in stream 14. These functions are important to recognize as they will begin execution once the document is opened and macros are enabled.

autoOpen function

In line 6 of this function, we can see a variable “der” is used as the path parameter for a file to execute with the Shell function. In VBA the Shell function can execute commands, executables, and scripts, like Python or Powershell scripts, via the command line. This is something we will want to take a deeper look into. In order to trace this further, we can see that “der” is set to the value of the function “naletic” in line 5.

mainaletic function with "der" variable

To avoid having to go through the arduous process of reverse engineering these variables to see their values, the easiest thing to do is use the built in debugger in Microsoft Office. We see the typical prompt in malicious Office documents to enable content, which allows macros to run.

opening malicious Word document

However, upon trying to view the VBA using the developer tools, we get a message telling us that the project is password protected.

project password prompt

However, there is a tool called EvilClippy ( that can help us remove the project protections. Once compiled, running the command“EvilClippy.exe -uu <filename>”, allows us to see the contents of the project and use the debugger.

unprotected project view

We can see “naletic = ViiZ” on line 47. Tracing further up to line 40, “ch” is an element in the byte array that came from a text box in a form that was in the VBA. You can see there is a form in the screenshot of the project above. The screenshot below shows two elements being retrieved from this form. “.Edit2.Text” is the obfuscated string we are interested in. You can see this string by looking at the “Text” box of “Edit2” in the drop down menu of the form properties.

edit2.text textbox with obfuscated code

Line 31 is where two for loops begin which take one byte at a time from the byte array and perform some simple subtraction, get the resulting character, and add it to the now deobfuscated string, “ViiZ”. Once the deobfuscation finishes, the code returns to line 6 and launches the Shell function with the new code.

deobfuscation routing
variables set to form properties

We know that, der = naletic, and naletic = Viiz, which seems to be where the deobfuscation is taking place, so we can simply add a watch to the variable naletic on line 5, shown below. This is where the function returns after deobfuscation.

breakpoint set to "der"

This is the deobfuscated code:

deobfuscated Powershell script

Here we can see a shell command to execute Powershell code that creates a web connection and attempts to download a file from two different url’s, and then execute the file. Below is the process tree from ProcessHacker, with Word spawning a cmd.exe, which in turn spawns conhost.exe, and then the powershell is executed, which possibly downloads another stage of the malware, which we were not able to retrieve in this example.

Process Hacker process tree

Sample Information and IOCs

Name: bad.doc
MD5: 654d36c13b27bb250bbdb81e6c35942f

IOCs – EXE Download


Comments are closed, but trackbacks and pingbacks are open.