top of page
  • Writer's pictureJosh Stroschein

Maldoc uses RC4 to hide PowerShell script, retrieves payload from DNS TXT record

Updated: Feb 11

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.

Figure 1: Image used to social engineer the user

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.

Figure 2: Oledump output

After extracting the macros, the entry point of the code can be identified through the button click event (Figure 3).

Figure 3: Macro code for initial button click

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).

Figure 4: Decrypt User Form

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.

Figure 5: Unlock button click event

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).

Figure 6: RC4 decryption and WScript.Shell object creation

The results from both strings are concatenated together and result in the following PowerShell command:


Which decodes to:

Figure 7: Decoded PowerShell script

As can be seen in figure 7, the second stage PowerShell uses nslookup to query a TXT record from This record, which can be arbitrary text, is executed upon return and contains the command to retrieve the next stage (figure 8) from hxxp:// This payload is then executed using msiexec.

FIgure 8: Value of TXT record

Wrapping Up

This maldoc requires a little more interaction to execute the malicious logic then simply enabling content. This not only has the e\affect 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.



Want to know when my latest content drops? Sign-up to receive email notications and access to other exclusive content!

bottom of page