Summary

On October 9^th an interesting method was described 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 function 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. It’s a common to see this where the user is asked to ‘Enable editing in order to view the content’.

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.

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)
• 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).

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, code example & breakdown below

Save the document as a .docx. Opening the document will present the below dialogue boxes, press ‘Yes’ to both.

Below is a Wireshark output along with the file within the temp directory

Outlook

Test further conducted by Kevin Beaumont & Czumak show that Outlook can be used to perform the exact same attack which 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.

1. 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.
2. 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.

Mitigations

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 show different results if the PowerShell script was to be obfuscated in some manner.

Cisco AMP should show Generic IOC’s for cmd opening from the office product with it further being clear in the device trajectory that an executable has been dropped onto the user’s system. The command line arguments will show the command passed as demonstrated above.  

Conclusion

Although not a new method into social engineering users to open documents laced with arbitrary code, it’s one that all analyst should be aware of when analysing Cisco AMP alerts and spam emails forwarded to the spam mailbox, with the SOC already handling an incident where this method was used (INC00000). 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:

https://www.hybrid-analysis.com/sample/b519f7399199322028e5c6f56776df1994624f392da9cb84ef288bbfd8bbe691?environmentId=100

Virus Total:

https://www.virustotal.com/#/file/b519f7399199322028e5c6f56776df1994624f392da9cb84ef288bbfd8bbe691/detection

Sources

https://sensepost.com/blog/2017/macro-less-code-exec-in-msword

https://msdn.microsoft.com/en-us/library/windows/desktop/ms648774(v=vs.85).aspx

https://www.bleepingcomputer.com/news/security/microsoft-office-attack-runs-malware-without-needing-macros