Updated 20 October: Added a note regarding enabling full command line logging for process creation events; added a note clarifying that "Creator Process Name" is only recorded in Windows 10 and Windows Server 2016. Older versions of Windows record the creator process ID but not the process name; added references to a variety of exploitation techniques found by other researchers or seen in the wild.

Updated 11 October: I originally wrote that this exploit technique bypassed both disabled macros, and Protected View. That is incorrect: this technique will work if macros are disabled, but the code does not trigger while in Protected View. Thanks to Matt Nelson (@enigma0x3) for pointing out my mistake.

I love reading exploit techniques that rely on native features of the operating system or common applications. As an attacker, I find it diabolically clever to abuse features the target fully expects to be used and cannot turn off without disrupting business. As a defender, I am intrigued by the challenge of detecting malicious use of perfectly legitimate features.

Researchers Etienne Stalmans and Saif El-Shereisuch of Sensepost wrote of a slick way to execute code on a target computer using Microsoft Word – but without the macros or buffer overflows usually exploited to this end. Instead, they use dynamic data exchange, or DDE – an older technology once used for coding and automation within MS Office applications. This is particularly clever because it works even with macros disabled – because it's not using the macro subsystem.
Read more »
Security for Real People