Yet Another DOSfuscation Sample
Last Updated: 2018-12-12 18:42:53 UTC
by Didier Stevens (Version: 1)
Reader Vince asked for help with the analysis of a malicious Word document. He started the analysis himself, following the method I illustrated in diary entry "Word maldoc: yet another place to hide a command".
Following this method, Vince found a shell statement:
And then searched for string zOSpqpzMSfs, but couldn't find the PowerShell command.
In the diary entry followed by Vince, I search for a VBA string, that is a string delimited with double quotes: "j9tmrnmi". Because this VBA string is used to identify an object that we can find in the streams of the OLE file.
String zOSpqpzMSfs, what Vince is searching, is actually a VBA variable name, and not a VBA string. The value of this variable is calculated at run time, and is not explicitly stored as an object property:
That is why the method followed by Vince does not work for this sample. You need to find the value of the variable, for example by reverse engineering the VBA statements and then calculate the value accordingly.
But there is also a "quick-and-dirty" method that I illustrated in diary entry "Quickie: String Analysis is Still Useful": just search for long strings (printable character sequences) in the document file, regardless of the internal file structure.
This works for Vince's sample (here I'm grepping cmd to keep the output short):
What we have here, is a PowerShell command obfuscated with a DOSfuscation technique.
This command-line statement selects characters from the string in red using indices in yellow:
to build the following command:
I used Python to do the indexing and concatenation to decode the PowerShell command:
And this PowerShell command is a downloader: a command that downloads and executes a malicious executable.
Notice that this downloader tries 5 URLs:
to download an Emotet variant.