October 16, 2017

We’ve all heard about malicious macros in Office documents right? By now it is a well known fact that macros might be malicious and as such, might infect unsuspecting victims upon execution.

Security solutions are aware of the “macro risk” and are monitoring and analyzing incoming documents for such malicious macros.

What if I were to tell you that there’s another way to get malicious code execution using Office documents, all without the use of macros?

Introducing DDE

Dynamic Data Exchange (DDE) protocol is one of the several methods in which Microsoft allows two running applications to share the same data. The protocol can be used by applications for one-time data transfers and for continuous exchanges in which apps send updates to one another as new data becomes available.

It has been known for a while that by applying DDE commands to several Microsoft products, one can achieve reliable code execution on a machine.

A previous report by SensePost, demonstrated the use of DDE commands in an Excel spreadsheet. When inserted into an Excel spreadsheet cell, the following code, gets evaluated and executed –

=cmd|’/c calc.exe’!A1

  • Popping the calc.exe as a proof.

DDE isn’t limited to Excel; Word has also had DDE capabilities for some time. But, while Word has been mentioned by others as a possible avenue for attack, no one has actually demonstrated this, as far as we know.

However, the same research team at SensePost has now been able to demonstrate that DDE capabilities can also be applied in Word. The exploitation technique that the researchers describe varies in syntax only, which may be the reason that it has remained unexplored until now. Just as with Excel, the method causes Windows to display “security” warnings to victims – asking them if they want to execute the application specified in the command. However, the pop-up alert may also be eliminated “with proper syntax modification,” the researchers say.

The researchers go on to explain, in detail, how to create a Word document with a DDE command in it–by inserting a Field (through Insert tab -> Quick Parts -> Field) and providing the following code:

{DDEAUTO “C:\\Windows\\System32\\cmd” “/c calc”}

The DDEAUTO keyword is used to inform MSWord that this is a DDE field, which will auto execute when the document is opened. The second part of the equation is the full path of the executable to execute, and the last part of the equation, which is in between quotes is the argument to pass to this executable (execute calc.exe).

By creating a .msg file with such a field and attaching it to an outgoing message, attackers are able to execute a remote code by simply sending an email.

Other office products

@SecuritySift tweeted about Outlook being vulnerable to such attacks as well, and additional Office products are likely to be vulnerable, although this has yet to be proven.


When contacted, Microsoft responded that DDE execution is just a feature and that no further action will be taken. However, this feature may be considered for a next-version candidate bug.

The security community has provided various methods to tackle this problem. For example, @dnlongen has provided some tricks to detect DDE execution in the event logs and @DidierStevens has provided some YARA rules for further detection of such documents.

Another way to deal with this issue is to eliminate the detection phase all together and move on to prevent malicious active content execution.


DDE attacks have been known for a long time now. Up until now, no one was able to exploit them in Word. The “blooming” of these DDE techniques has caused a massive surge in such attacks being spotted in the wild – and this is only the beginning. We estimate that these kinds of “Old school” techniques will be further explored by the security industry and malicious actors alike, and will be featured in malicious schemes in the future.

We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it. Privacy policy