T1559: Inter-Process Communication
Adversaries may abuse inter-process communication (IPC) mechanisms for local code or command execution. IPC is typically used by processes to share data, communicate with each other, or synchronize execution. IPC is also commonly used to avoid situations such as deadlocks, which occurs when processes are stuck in a cyclic waiting pattern.
Adversaries may abuse IPC to execute arbitrary code or commands. IPC mechanisms may differ depending on OS, but typically exists in a form accessible through programming languages/libraries or native interfaces such as Windows Dynamic Data Exchange or Component Object Model. Linux environments support several different IPC mechanisms, two of which being sockets and pipes.[1] Higher level execution mediums, such as those of Command and Scripting Interpreters, may also leverage underlying IPC mechanisms. Adversaries may also use Remote Services such as Distributed Component Object Model to facilitate remote IPC execution.[2]
Analyst context for executives and security teams
Inter-Process Communication (IPC) is normal operating-system and application plumbing, so abuse of it can look like legitimate software behavior. Its business significance is that local code or command execution may occur through trusted process-to-process mechanisms rather than obvious standalone executables. For leaders, this is a coverage question: can the SOC and endpoint controls explain when IPC behavior is expected versus suspicious across Windows, macOS, and Linux?
Executive priority
Prioritize this as an execution-risk and visibility-control issue, not just a malware signature problem. Ask whether critical endpoints and servers have telemetry for process relationships, privileged process activity, and OS-specific IPC mechanisms such as Windows COM/DDE, macOS XPC services, and Linux sockets or pipes. The relationship context also makes this relevant to secure software design, privileged account governance, endpoint behavior prevention, feature reduction, sandboxing, and secure configuration evidence for audits and incident readiness.
Technical view
ATT&CK lists T1559 under Execution for Linux, macOS, and Windows. The most useful validation path is OS-specific: review Windows COM and DDE exposure via the listed sub-techniques, macOS XPC service and privileged helper activity, and Linux sockets/pipes used for process communication. Because ATT&CK provides no official detection text for the parent technique, detection engineering should use the related DET0493 strategy and local baselines to identify abnormal parent/child process relationships, unusual IPC-triggered execution, unexpected privileged context, and IPC activity chained with command/scripting interpreters or remote services.
Likely telemetry
- Endpoint process creation, parent/child lineage, command-line, user, integrity/privilege context, and process ancestry
- EDR or OS audit events for process-to-process communication, API behavior, service/helper invocation, and suspicious execution chains
- Windows telemetry relevant to COM objects, DDE activity, DLL/EXE server activation, and related process launches
- macOS logs and endpoint telemetry for XPC service communication, privileged helper tools, and root-running service activity
- Linux audit and system telemetry for sockets, pipes, process execution, user context, and service interactions
Detection direction
- Start with baselining: IPC is common, so detections should focus on abnormal process relationships, unexpected caller/callee combinations, unusual privilege transitions, and execution from applications that do not normally initiate commands.
- Map coverage separately for the sub-techniques: T1559.001 Component Object Model, T1559.002 Dynamic Data Exchange, and T1559.003 XPC Services; do not assume one analytic covers all IPC abuse.
- Tune for chains involving command and scripting interpreters or remote services where IPC may be the execution bridge, as described by ATT&CK.
- Validate that telemetry exists on all listed platforms; many blind spots come from macOS/Linux IPC activity being less consistently logged than Windows process creation.
- Use relationship context from campaigns and software only as prioritization input for threat-informed testing, not as proof of current exposure or active exploitation in the environment.
Mitigation priorities
- Apply least privilege and privileged account management so IPC-triggered execution has limited authority and is attributable.
- Reduce attack surface by disabling or removing unnecessary software features, legacy components, or IPC-exposed functionality where business use does not require them.
- Use secure software configuration and application developer guidance to harden applications that expose IPC interfaces or privileged helper functions.
- Deploy behavior prevention on endpoints where it can restrict suspicious process behavior and IPC-linked execution patterns.
- Use application isolation or sandboxing for higher-risk applications so abuse of IPC is less likely to affect the broader host or sensitive resources.
Analyst notes and limits
This parent technique is broad by design. Its best operational value comes from decomposing it into OS-specific mechanisms and validating whether detection logic can distinguish normal application IPC from execution abuse. The supplied relationships show multiple mitigations and many campaigns/software entries using the behavior, which supports prioritizing threat-informed coverage reviews without making environment-specific assumptions.
ATT&CK provides no official detection text for T1559 in the supplied fields. The take therefore avoids claiming guaranteed detections and relies on the listed platforms, sub-techniques, mitigation relationships, and DET0493 relationship for defensive direction. Local baselines, application inventories, and endpoint logging configuration are required to determine actual coverage.
Inter-Process Communication
Adversaries may abuse inter-process communication (IPC) mechanisms for local code or command execution. IPC is typically used by processes to share data, communicate with each other, or synchronize execution. IPC is also commonly used to avoid situations such as deadlocks, which occurs when processes are stuck in a cyclic waiting pattern.
Adversaries may abuse IPC to execute arbitrary code or commands. IPC mechanisms may differ depending on OS, but typically exists in a form accessible through programming languages/libraries or native interfaces such as Windows Dynamic Data Exchange or Component Object Model. Linux environments support several different IPC mechanisms, two of which being sockets and pipes.[1] Higher level execution mediums, such as those of Command and Scripting Interpreters, may also leverage underlying IPC mechanisms. Adversaries may also use Remote Services such as Distributed Component Object Model to facilitate remote IPC execution.[2]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1559.003 | XPC Services Sub-technique | XPC Services subtechnique of this object. |
| Enterprise | T1559.002 | Dynamic Data Exchange Sub-technique | Dynamic Data Exchange subtechnique of this object. |
| Enterprise | T1559.001 | Component Object Model Sub-technique | Component Object Model subtechnique of this object. |
Groups, software, and campaigns
S1229: Havoc
Havoc is an open-source post-exploitation command and control (C2) framework first released on GitHub in October 2022 by C5pider (Paul Ungur), who continues to maintain and develop it with community contributors. Havoc provides a wide range of offensive security capabilities and has been adopted by multiple threat actors to establish and maintain control over compromised systems.
S1200: StealBit
S1130: Raspberry Robin
Raspberry Robin is initial access malware first identified in September 2021, and active through early 2024. The malware is notable for spreading via infected USB devices containing a malicious LNK object that, on execution, retrieves remote hosted payloads for installation. Raspberry Robin has been widely used against various industries and geographies, and as a precursor to information stealer, ransomware, and other payloads such as SocGholish, Cobalt Strike, IcedID, and Bumblebee.[1][2][3] The DLL componenet in the Raspberry Robin infection chain is also referred to as "Roshtyak."[4] The name "Raspberry Robin" is used to refer to both the malware as well as the threat actor associated with its use, although the Raspberry Robin operators are also tracked as Storm-0856 by some vendors.[5]
S1150: ROADSWEEP
ROADSWEEP is a ransomware that was deployed against Albanian government networks during HomeLand Justice along with the CHIMNEYSWEEP backdoor.[1]
S1123: PITSTOP
PITSTOP is a backdoor that was deployed on compromised Ivanti Connect Secure VPNs during Cutting Edge to enable command execution and file read/write.[1]
S0022: Uroburos
Uroburos is a sophisticated cyber espionage tool written in C that has been used by units within Russia's Federal Security Service (FSB) associated with the Turla toolset to collect intelligence on sensitive targets worldwide. Uroburos has several variants and has undergone nearly constant upgrade since its initial development in 2003 to keep it viable after public disclosures. Uroburos is typically deployed to external-facing nodes on a targeted network and has the ability to leverage additional tools and TTPs to further exploit an internal network. Uroburos has interoperable implants for Windows, Linux, and macOS, employs a high level of stealth in communications and architecture, and can easily incorporate new or replacement components.[1][2]
S0537: HyperStack
HyperStack is a RPC-based backdoor used by Turla since at least 2018. HyperStack has similarities to other backdoors used by Turla including Carbon.[1]
S1172: OilBooster
OilBooster is a downloader written in Microsoft Visual C/C++ that has been used by OilRig since at least 2022 including against target organizations in Israel to download and execute files and for exfiltration.[1]
S1244: Medusa Ransomware
Medusa Ransomware has been utilized in attacks since at least 2021. Medusa Ransomware has been known to be utilized in conjunction with living off the land techniques and remote management software. Medusa Ransomware has been used in campaigns associated with “double extortion” ransomware activity, where data is exfiltrated from victim environments prior to encryption, with threats to publish files if a ransom is not paid. Medusa Ransomware software was initially a closed ransomware variant which later evolved to a Ransomware as a Service (RaaS). Medusa Ransomware has impacted victims from a diverse range of sectors within a multitude of countries, and it is assessed Medusa Ransomware is used in an opportunistic manner.[1][2][3][4]
S9024: SPAWNCHIMERA
SPAWNCHIMERA is a backdoor that supports command and control and can inject malicious components into native processes.[1][2][3] SPAWNCHIMERA It incorporates capabilities from multiple tools within the SPAWN malware family, including SPAWNANT, SPAWNMOLE, and SPAWNSNAIL.[4][2][3] SPAWNCHIMERA was first reported in April 2024.[2] SPAWNCHIMERA has been observed in activity attributed to People's Republic of China (PRC) state-sponsored threat actors, including UNC5221..[4][5][2][6]
S0687: Cyclops Blink
Cyclops Blink is a modular malware that has been used in widespread campaigns by Sandworm Team since at least 2019 to target Small/Home Office (SOHO) network devices, including WatchGuard and Asus. Cyclops Blink is assessed to be a replacement for VPNFilter, a similar platform targeting network devices.[1][2][3]
S1078: RotaJakiro
RotaJakiro is a 64-bit Linux backdoor used by APT32. First seen in 2018, it uses a plugin architecture to extend capabilities. RotaJakiro can determine it's permission level and execute according to access type (`root` or `user`).[1][2]
C0048: Operation MidnightEclipse
Operation MidnightEclipse was a campaign conducted in March and April 2024 that involved initial exploit of zero-day vulnerability CVE-2024-3400, a critical command injection vulnerability in the GlobalProtect feature of Palo Alto Networks PAN-OS.[1][2]
C0057: 3CX Supply Chain Attack
The 3CX Supply Chain Attack was the first publicly reported case of one supply chain compromise triggering another, leading to a cascading, two-stage intrusion. The initial supply chain attack began when a 3CX employee downloaded and executed a trojanized, end-of-life version of the X_Trader trading software from Trading Technologies. This provided UNC4736, a threat cluster associated with AppleJeus, access to the 3CX environment. From there UNC4736 compromised the Windows and macOS build environments used to distribute the 3CX desktop application to their customers.[1] While 3CX serves more than 600,000 customers and 12 million users, only a subset of systems were affected. Subsequent targeting focused on victims in the defense and cryptocurrency sectors, where attackers deployed secondary payloads such as Gopuram for credential theft and persistence.[2] The campaign began in late 2022 and was disrupted after security vendors publicly reported the compromise in March 2023.[3][4]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.4 | Current bundle | f7de1021ceed… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Linux IPC
N/A. (2021, April 1). Inter Process Communication (IPC). Retrieved March 11, 2022.
Open source URL -
[2]
Fireeye Hunting COM June 2019
Hamilton, C. (2019, June 4). Hunting COM Objects. Retrieved June 10, 2019.
Open source URL -
[3]
mitre-attack T1559Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.