In a previous post we covered what it looks like from the user perspective when a Trickbot phish is opened. In this post, I'll briefly cover the same mechanism for a stealthier phish iteration surrounding Emotet.
A quick triage in olevba shows some of the suspicious indicators associated with the file
Based on this, we know that the macro within the file will auto run upon it being opened, as well as the IP it'll attempt to call out to in some way, shape, or form.
HERE COMES THE [QUIET] BOOM
With all of our monitoring tools in place, we click on the file like an unsuspecting user and get the following image:
The image, with a typo, prompts the user to enable macros in order to see the rest of the file. Upon doing so, nothing at all visibly happens. No document populates to further deceive the user, and the same "image wall" that was present prior to enabling macros is still at the forefront of the document.
If we pivot over to ProcessHacker, we can see an instance of mshta has started:
This is interesting, because unlike the Trickbot phish we analyzed previously, there are no windows and not even the slightest indication that this activity has taken place. Without any signs of compromise, the user may conclude that the file was corrupted or faulty in some way and just close it. Of note, the MSHTA instance persists since its in the process tree of a svchost process. Looking at further details on the file, we see that it's indeed set up to call out to the IP we identified in the olevba output.
Another instance of note is that EXCEL spawned a process called splwow64. This process, according to Microsoft, is used to "translate the driver model of a 64-bit operating system and a 32-bit program." At the time of analysis and within this specific execution of the malware, the context of splwow64 is unknown.