One of the most common attack vectors in today’s world is the exploitation of Microsoft’s Dynamic Data Exchange (DDE) functionality, a feature that is implemented within the Microsoft Office suite. Attackers and penetration testers have been leveraging such functionality to gain a foothold in organization’s network environments to establish access, extract data, and just even to poke around. This attack vector has become more popular recently due to the ability to run code with less suspicion from the end-user, making it even more easier to exploit end-user systems.

Prior to the discovery of Microsoft’s DDE functionality, attackers leveraged the ability to run macros in Microsoft Office products to perform remote code execution. However, unlike executing code via Microsoft DDE, embedding macros will force a security warning prompt at the top of the document, warning users that macros have been disabled. The image below is an example of the security warning that is presented when opening a Microsoft Office Word document with a macro embedded.

Microsoft Word prompt to trust macros (Word for Mac OS X)

… or if you’re on Microsoft Windows…

Microsoft Word prompt for trusting macro (Word for Windows)

In order for an attacker to convince the user to click “Enable Content,” which would run the malicious code in the document, the attacker would have to become creative, such as including an image in the picture below.

Example of malicious Microsoft Word document convincing user to trust macros

On the other hand, here are examples of security warnings presented to users that attempt to open a Microsoft Office document that contains embedded DDE code.

Warning prompt prior to executing DDE code

… and if the user clicks “Yes” to the prompt above, a variation of another warning (shown below) is also presented, allowing a second opportunity to prevent code execution.

Result of user clicking "yes" to previous prompt

Depending on the type of phishing campaign executed by the attacker, this may or may not convince the end-user to actually enable the macros. Although there should be many red flags triggered here to avoid proceeding, we have concluded, from numerous assessments, that a significant number of end-users have actually enabled the macros based on a similar image above. Both of these attack vectors have been widely used amongst phishing attacks and, while Microsoft DDE exploits have become much more popular in the recent past, both of the methods can result in the same end-goal: a successful system compromise.

Identifying Malicious Code

With two perfectly fine and working attack vectors within Microsoft Office, attackers can leverage either one of these techniques to target end-user systems. Whether or not one technique is used or not primarily depends on the type of phishing attack the attacker chooses, as both can provide the same end-result. Let’s take a look at some ways attackers leverage these attacks to compromise systems.

Exploitation via DDE

As previously mentioned, Microsoft DDE exploits have become more popular lately due to it being much less suspicious to the end user. More specifically, the messages and warnings that are presented to the user can be customized to an extent, which essentially increases the chances of a user engaging with the document and enabling access. In many cases, the fields that contain embedded malicious code is hidden by Microsoft’s functionality that pretty much attempts to “resolve” the field or formula. Let’s take a look at an example.

In the figure below, you’ll notice that the Microsoft Word document does not look suspicious from an initial glance.

Message that displays in Word document after executing DDE code

However, by right clicking “Error! No topic specified.” or pressing CTRL-F9, you have the option to toggle field codes, which then exposes the code behind the field/formula. The image below is a perfect example of hidden malicious code behind the field/formula.

Code behind DDE link

A well-informed security engineer or network administrator could analyze this code and attempt to trace back where the source of the malicious code could potentially be originating. In some examples, the code above is also encoded in base64 (if the -Enc option is specified as an argument), in which case an administrator could simply take the encoded string and decode it using a base64 decoder. This can be done safely as long as the administrator is not attempting to execute this base64 decoded string from a tool such as command line.

It should also be noted that this form of an attack has been demonstrated in many different Microsoft Office products, including Microsoft Outlook, Word, as well as Excel.

Exploitation via Macro

In order for an attacker to embed malicious code into a Microsoft Office document by leveraging a Macro, it must be performed by including the macro code into the document’s Visual Basic code editor functionality. In addition to the warning presented to the user, it is possible to detect this by enabling the Developer tab in the specific Microsoft Office product and then inspecting the code. This can be accomplished by navigating to File -> Options -> Customize Ribbon. Once enabled, macros can be identified by going to the Developer tab and opening up the Visual Basic window (not the Macros window).

The image below is an example of malicious code that is intended to run as macros once executed by the end-user.

Example of macro source code within malicious Microsoft Word document

As mentioned in the Microsoft DDE exploit section, the above image demonstrates a perfect example of a PowerShell command which leverages an encoded string (base64 encoded). By decoding this using a base64 decoder, an administrator could determine where the PowerShell command is actually communicating to.


As these attack vectors are extremely popular and are being targeted by attackers around the globe, it is imperative that administrators ensure their end-users are well-educated and their systems are up-to-date with cutting edge software that goes beyond just simply detecting malware in executables. Here are some additional suggestions to preventing these types of attacks within your organization.

Disabling Microsoft Office Features

As with any protocol, service, and system within your organization, services that are not required to perform business operations should be disabled. Microsoft Office comes with support for DDE enabled by default. Therefore, if your organization isn’t using this feature and has no future plans for it, it should be disabled. This can be accomplished using the following steps:

  1. Open Microsoft Word/Excel
  2. Go to “File”
  3. Go to “Options”
  4. Select “Advanced”
  5. Disable the functionality for “Update Automatic Links at Open”

Performing this on every single computer can be a significant task; therefore, you can also accomplish this by leveraging the Microsoft Windows registry, as mentioned in Microsoft’s guide here: It should also be noted that, if users heavily rely on Microsoft Excel spreadsheets to automatically update information based on links and references to other documents and network share locations, this automatic updating feature would be impacted.

With regards to Microsoft Office macros, administrators can easily disable support for Visual Basic macros on a global level by leveraging Group Policy. To accomplish this task, download the necessary custom Group Policy objects defined by Microsoft here: Once imported, administrators should have the ability in Group Policy to go into the Trust Center for the specified Microsoft Office product and disable support for VBA macros. Additional information can be found on Microsoft’s article located here:

End-User Security Controls

Many end-user software security controls are considered weak based on the modern attacks that occur today. In many instances, penetration testers compromise end-user systems by using commonly known security attacks and are successful due to the lack of capabilities by the security software. For example, rather than simply monitoring for malicious files, end-user systems should also be monitoring for potential attacks that occur within memory and monitor the behavior of files. Additionally, the security software should be able to detect what API calls are being made within memory in case trusted files attempt to make calls to functions that could result in code or unexpected command execution.

Security Awareness Training

In addition to the aforementioned technical controls, employees should undergo thorough user awareness training to ensure that they are aware of the security risks of interacting with unfamiliar documents. Users should be trained to question IT staff if a document seems suspicious or presents them with warnings that could result in a compromise. Furthermore, training should be provided on a frequent basis, whether created and hosted by the organization itself or a third-party vendor.