Inter-Process Communication

Applications can ask each other to act

Inter-process communication, or IPC, allows software components to exchange information or request operations. Operating systems and applications provide many such interfaces. Abuse uses those normal relationships to trigger unauthorized behavior, potentially through a process that appears familiar or trusted.

IPC is not inherently suspicious. Desktop integration, automation, service operation, and application features depend on it. The investigator needs the requesting process, receiving component, requested action, permissions, and resulting behavior rather than a generic alert that two processes communicated.

A document requests an unexpected action

In a fictional office, a document-related process causes another application component to launch an unfamiliar program. The analyst examines the process sequence, available application events, document or automation content, and the receiving interface's expected purpose.

A legitimate integration may explain the interaction. The team compares the behavior with approved workflows and a known safe example. A familiar receiving application does not establish that the request it processed was trustworthy.

Different IPC mechanisms expose different evidence. Some sources show only the resulting process, while others may record the request or component relationship. Avoid naming an exact interface if the evidence supports only an indirect launch through an application.

Identify the trust relationship

Determine which identity made the request and which context performed the action. A component may act on behalf of a caller or under its own service authority. The interface's authorization rules determine whether the request should have been allowed.

Authorization explains that boundary, while Command and Scripting Interpreter may describe a later execution step. IPC abuse and Process Injection are not interchangeable: requesting an operation through an interface differs from placing code inside another running process.

Preserve relevant input and configuration through controlled handling. Do not open unfamiliar documents on a normal workstation simply to reproduce the chain; use an authorized isolated process appropriate to the risk.

Address the request path

Contain harmful behavior as justified and review the permissions, application settings, or weakness that allowed the request. Disabling one feature without understanding its business use can break legitimate integrations, so coordinate with the owner.

For practice, compare an approved application automation request with a fictional document-triggered request launching an unexplained program. Identify the caller, receiver, input, authority, and outcome records needed to distinguish them. Write a conclusion when only the resulting process is visible and identify the additional evidence needed to name the IPC mechanism confidently. Incident reporting and handover should preserve that uncertainty.

Related concepts

• MITRE ATT&CK
• Logs and telemetry
• Incident response
• Remote Services