On October 9th 2017 an interesting method was detailed in order to execute arbitrary code in Microsoft Word with the use of the Dynamic Data Exchange (DDE Protocol). The method was described in detail by Etienne Stalmans & Saif El-Sherei in a sense post blog post.
So, what is the DDE protocol? According to Microsoft:
“Windows provides several methods for transferring data between applications. One method is to use the Dynamic Data Exchange (DDE) protocol. The DDE protocol is a set of messages and guidelines. It sends messages between applications that share data and uses shared memory to exchange data between applications. Applications can use the DDE protocol for one-time data transfers and for continuous exchanges in which applications send updates to one another as new data becomes available.”
The feature in Windows isn’t new, with Cimpanu reporting that the attack has existed since the early 90’s with the introduction with DDE, with groups such as FIN7 re-introducing the attack method in ‘limited targeted attacks’, according to Kevin Beaumont.
So how can this be used? A common method employed by actors presently in order execute arbitrary code on a user’s system is through the use of VB scripts embedded into Word Documents, often delivered through malspam campaigns. It’s common place to see this, where the user is asked to ‘Enable editing in order to view the content’.
Fig 1.1 – Screenshot From MyOnlineSecurity
With this discovery, rather than the user being asked to ‘Enable Content’, the user instead is presented with a two dialogue boxes when opening the document. The first dialogue box informs the user the document contains links that may refer to other files. Should the user click ‘Yes’ a second dialogue box is presented to the user, informing them that the remote data is not accessible and if they would want to start the application. Should the user click ‘Yes’ for the second-time whatever arbitrary code has been embedded within the field code will be executed.
Fig 1.2 – Dialogue Boxes Presented To Users
It’s already been leveraged in recent malspam campaigns in the wild through the likes of Trickbot & Locky, with Microsoft responding that it’s a built in feature and no further actions will be taken, with a potential for it to be considered for a next-version candidate bug.
Testing
With this in mind, I’ve attempted to replicate this exploit using Windows 7 & Office 2016 and a safe executable located on a remote server. Below is a breakdown of the tests conducted.
Versions
Below are the versions of Windows 7 and Office used:
- Windows 7 – Build 7601 (SP1) – As fully patched as possible
- Office 2016 – Version 1709 – Build 8528.2147
Payload
For this demonstration, I created a simple Windows Application in Visual Studio which does nothing (an image, a button with a message box).
Fig 2.1 – Demonstration exe (http://aminul.co.uk/L33txpl0it[.]png)
Fig 2.2 – The file was uploaded to my server as a png.
Creating The Document
Insert -> Quick Parts -> Formula
Select =(Formula) and Click OK
Right Click Inserted Field -> Toggle Field Codes
Copy in the code that you want to execute. Below is the example & breakdown below of the code I used:
Save the document as a .docx. Opening the document will present the below dialogue boxes, press ‘Yes’ to both. This should then download and execute the payload onto the system.
Below is a Wireshark output along with the file within the temp directory
Outlook
Tests further conducted by Kevin Beaumont & Czumak show that Outlook can be used to perform the exact same attack with the code used within the word document (above) simply copied into the email. The code is rendered once the user attempts to reply to the email.
- Create a new email, ensure RTF is enabled in the email. For reasons unknown inserting an object, picture or chart will trigger the DDE command. Copy the DDE command into the email (can be formatted in white so it’s not seen) and encourage the user to reply to the email
The receipt of the email won’t be able to see anything, and when attempting to reply to the email they be presented with exactly the same two dialogue boxes as seen when using this in word.
Mitigation
- Uploading the test file into Virus Total shows a number of detections for the newly created file, with a number of detection engines detecting the file as a Trojan Downloader. However, this might produce different results if the PowerShell script was to be obfuscated in some manner.
Conclusion
I personally anticipate this method being used more frequently going forward as receipts have been less exposed to seeing this when compared to the more traditional macro enabled documents.
Samples
SHA-256: b519f7399199322028e5c6f56776df1994624f392da9cb84ef288bbfd8bbe691
Hybrid Analysis: Threat Score 100/100
Virus Total: 23/60
Sources