Macros get most of the attention, so it is easy to forget that an older Windows feature can run commands from a document with no VBA at all. Dynamic Data Exchange (T1559.002) is an Execution technique for Windows and a subtechnique of Inter-Process Communication.
How attackers use it
MITRE describes DDE as a client-server protocol for one-time or continuous IPC between applications. Once a link exists, applications can exchange strings, warm data links (notifications when a data item changes), hot data links (copies of changes), and requests for command execution.
Object Linking and Embedding was originally built on DDE. DDE was superseded by COM, but MITRE notes it may still be enabled in Windows 10 and most of Microsoft Office 2016 through registry keys.
The risk comes in three forms:
- Office documents poisoned with DDE commands, directly or through embedded files, delivered by phishing or hosted web content. This avoids VBA macros entirely.
- CSV files with DDE formulas, meant to be opened in a Windows spreadsheet program.
- Use by an adversary already on a machine who has no direct access to a command interpreter. DDE can also be invoked remotely through Distributed COM.
How to detect it
MITRE's analytic looks for Office applications such as WINWORD.EXE and EXCEL.EXE spawning command interpreters or loading unusual modules through DDEAUTO or DDE formulas. It correlates parent and child process relationships, registry keys that enable DDE, and module loads that do not fit normal Office use.
Process creation logging with parent process details is the single most useful data source here. On Windows, Sysmon event ID 1 and Security event 4688 with command line auditing both provide it.
What the abuse looks like from the defender's chair
The pattern is consistent. A user receives a document or spreadsheet by email or from a website. It opens in an Office application. The application then starts something it has no business starting, such as a command interpreter. From the endpoint logs, you see an Office process as the parent of a command interpreter, or an Office process loading modules that normal documents never load.
That parent and child relationship is the reliable signal. The document content may be obfuscated and the delivery may change, but the Office application starting a shell is hard to hide from process creation logs.
CSV files deserve the same suspicion as documents
MITRE says adversaries may embed DDE formulas in CSV files meant to open in a Windows spreadsheet program. People tend to treat CSV as plain data, and exports from web systems are opened constantly. That makes them a convenient carrier. Two habits help.
- Treat CSV files from outside your organization as untrusted until opened in a safe viewer.
- If your own application exports CSV from user-entered data, neutralize cells that begin with characters a spreadsheet treats as a formula, such as an equals sign, plus, minus or at sign. This is a developer control that closes the hole at the source.
If you find it
- Isolate the endpoint and keep the document for analysis, without opening it again on a normal machine.
- Pull the process tree for the Office process, and identify what the child process did next, including network connections.
- Search mail and file shares for the same attachment name or hash, and remove it.
- Check whether the registry keys that control automatic DDE and OLE execution were enabled on that machine, and fix the baseline so they are off everywhere.
- Confirm the ASR rule for Office child processes is in block mode on the fleet.
How to reduce the risk
MITRE lists four mitigations.
- Behavior prevention on endpoint. On Windows 10, turn on Attack Surface Reduction rules to prevent DDE attacks and child processes from Office programs.
- Application isolation and sandboxing. Make sure Protected View is enabled.
- Software configuration. Consider disabling embedded files in Office programs, such as OneNote, that do not work with Protected View.
- Disable or remove feature. Office registry keys can disable automatic DDE and OLE execution, and Microsoft also created, and enabled by default, keys that completely disable DDE execution in Word and Excel.
Check your own environment
Since this is about policy more than commands, work through the list.
- Is the ASR rule that blocks Office applications from creating child processes enabled on every managed Windows 10 and later endpoint, in block mode and not only audit mode?
- Is Protected View enforced for files that come from the internet or email?
- Does your email gateway flag spreadsheets and CSV files with formulas that start with an equals sign and call out to programs?
- Can you query, across all endpoints, for Office processes with command interpreter children in the last 30 days?
The last question is a good rehearsal. If it takes a week to answer, the detection is not ready.
# Windows (PowerShell): confirm Sysmon is installed and log size, read-only
Get-Service Sysmon64 -ErrorAction SilentlyContinue
Get-WinEvent -ListLog "Microsoft-Windows-Sysmon/Operational" | Select-Object LogName,RecordCount,MaximumSizeInBytes
Common mistakes
- Relying on macro settings alone. DDE does not use macros, so a macro block does not cover it.
- Enabling the ASR rule in audit mode and never reviewing the results. Audit mode records but does not block.
- Leaving Protected View off for files from internal shares, when a compromised internal mailbox is a common source of the next attachment.
Quick check
Why is DDE attractive to an adversary compared with macros?
MITRE notes it can deliver execution without VBA macros, so controls that only look at macros miss it.
Which Windows 10 feature does MITRE suggest to block both DDE attacks and Office child processes?
Attack Surface Reduction rules.
