Programs need to talk to each other. Operating systems give them pipes, sockets, shared objects and message channels for that. Inter-Process Communication (T1559) is the technique of abusing those channels to run code or commands. MITRE lists it under Execution, for Linux, macOS and Windows.
How attackers use it
MITRE explains that IPC is used to share data, communicate and synchronize execution, and to avoid situations such as deadlocks. The mechanisms differ by operating system. On Windows, the examples are Component Object Model (COM) and Dynamic Data Exchange (DDE). On Linux, MITRE names sockets and pipes. Higher-level execution mediums, such as command and scripting interpreters, may also lean on the underlying IPC mechanisms. Adversaries may also use Remote Services such as Distributed COM to run IPC remotely.
The subtechniques are COM (T1559.001), DDE (T1559.002) and XPC Services on macOS (T1559.003).
How to detect it
MITRE's detection strategy has a variant for each platform family:
- Windows. Anomalous use of COM, DDE or named pipes. Correlate the creation or access of IPC objects with unusual parent and child process relationships or code injection. A classic example is an Office application spawning cmd.exe through DDE.
- Linux. Abuse of UNIX domain sockets, pipes or message queues. Look for unexpected socket creation by suspicious binaries, odd shell pipelines, or injected processes opening IPC channels.
- macOS. Anomalous use of Mach ports, Apple Events or XPC services, such as automation scripts sending privileged Apple Events to security-sensitive apps.
How to reduce the risk
MITRE lists these mitigations.
- Disable or remove features. Office registry keys can disable automatic DDE and OLE execution. Microsoft also created, and enabled by default, keys that completely disable DDE execution in Word and Excel.
- Software configuration. Consider disabling embedded files in Office programs, such as OneNote, that do not work with Protected View.
- Application isolation and sandboxing. Keep all COM alerts and Protected View enabled.
- Privileged account management. Tighten process-wide and system-wide COM security settings using the registry or Dcomcnfg.exe.
- Behavior prevention on endpoint. On Windows 10, turn on Attack Surface Reduction rules to prevent DDE attacks and child processes spawned from Office programs.
A way to think about IPC abuse
The techniques in this family share a shape. Something legitimate, built to let programs cooperate, is used to cause an unexpected program to run. The legitimate feature is not going away, so the defenses are layered:
- Make the dangerous feature hard to reach. Disable automatic DDE and OLE execution, restrict COM security settings, and require developers to validate XPC clients.
- Contain the application that handles untrusted content. Protected View and sandboxing keep a document from reaching the IPC mechanism.
- Watch the result. The tell is almost always the process tree. An Office application with a command interpreter child, a helper tool launched from the wrong parent, or a socket opened by a binary that has no reason to.
Log process creation with parent details everywhere you can. It is the single data source that serves almost every detection in this family.
Check your own environment
- Do your endpoint logs capture process creation with parent process, so you can see Office applications launching command interpreters?
- Are Protected View and the ASR rules for Office child processes enabled by policy, not just on some machines?
- On macOS, do your helper tools validate their XPC clients?
Quick check
Which process relationship is the textbook sign of DDE abuse?
An Office application such as Word or Excel spawning a command interpreter.
