How T1559 Inter-process communication shows up in intrusions
T1559 Inter-process communication lets an adversary use the mechanisms that programs use to talk to each other in order to run instructions inside a process other than the one it first compromised. The MITRE ATT&CK tactic TA0002: Execution defines the goal as "The adversary is trying to run malicious code or instructions on a system," and T1559 is one of several ways to reach it. The technique has three sub-techniques, and this page maps detections to ATT&CK version 20.0. For a SOC lead, the difficulty is that this activity often resembles normal software behavior: an application calling a helper component, a service messaging a background process, or an installer coordinating its own parts. Alerts on these events are easy to dismiss unless triage asks who initiated the exchange, what the receiving process was asked to do, and whether the same host shows anything unusual in the minutes before.
In intrusions, T1559 usually appears after an adversary already has a foothold. It helps the adversary move execution into a process that is more trusted, better connected to the network, or less likely to be inspected closely. Illustrative example: an endpoint alert shows a document-handling application starting a scripting host shortly after a user opened an attachment, and the parent and child relationship is the only clear clue. Triage should treat the event as one step in a chain and correlate it with the earlier events that gave the adversary access. The decision to make before go-live is which inter-process relationships are expected in your fleet. Record that baseline per operating system and per business application, so that a deviation from it is visible when it happens.
Before tuning any rule, confirm what your endpoint detection tooling and host logging capture for inter-process activity. The sub-techniques surface through different telemetry on Linux, macOS and Windows, so one rule set will not cover every case. Ask your platform team to confirm which process creation fields, parent process details and script execution records are retained, and for how long. Also record in your detection register that this mapping targets ATT&CK version 20.0, because MITRE's release notes show that techniques can be renamed, deprecated or revoked between versions, and a mapping that is not versioned becomes hard to audit.
Which telemetry reveals T1559 on each platform
This table maps the telemetry that exposes T1559 Inter-Process Communication on Linux, macOS and Windows to the open-source collectors that gather it. Read each row as a platform, then check the collector and the items to confirm in your own environment before relying on a detection. The main takeaway is that coverage depends on what each endpoint records, so validate it on your own hosts.
| Platform | Telemetry to collect | Open-source collector | What to confirm |
|---|---|---|---|
| Linux | Process creation and command execution records, file access on sockets, pipes and shared memory, and script or interpreter activity | Wazuh agent with auditd rules, Velociraptor artifacts, Zeek for network-side context | Whether auditd or equivalent kernel auditing is enabled for IPC system calls, retention length, and log volume limits |
| macOS | Process creation, script execution records and file access to user-level IPC endpoints such as sockets and mach-related paths | Wazuh agent with unified log forwarding, Velociraptor for on-demand collection, Security Onion for network context | Which unified log predicates are forwarded, whether endpoint security tooling exposes process events, and agent support for your macOS versions |
| Windows | Process creation with command line, script block logging, named pipe creation and connection events, and file creation in pipe and temp paths | Sysmon-based pipeline forwarded to Wazuh, Velociraptor for hunting, Zeek for SMB and RPC traffic | Sysmon configuration covers pipe events, PowerShell logging is enabled, and event channels are sized to retain enough history |
| Cross-platform data components | Process Creation (DC0032), Command Execution (DC0064) and File Creation (DC0039) as referenced by ATT&CK detection strategies | Wazuh, Velociraptor and Security Onion pipelines mapped to these components | The exact data component IDs and detection strategies in the ATT&CK version you target, since releases can change mappings |
| Network context | Connection and traffic metadata that shows local IPC or remote process communication leaving the host | Zeek and Suricata sensors within Security Onion | Sensor placement covers the segments where your IPC-linked services talk, and whether local-only traffic is visible at all |
Detection logic for T1559 that SOC teams can tune
T1559 Inter-process communication covers abuse of legitimate IPC mechanisms to run instructions in another process. The cards below describe detection ideas in words, each with the threshold to tune and the benign activity that usually causes noise, so teams can express them as Sigma rules that name the ATT&CK version they target.
Process creation baseline by family
Group process creation events by the IPC sub-technique family relevant to each platform, then record which parent and child process pairs appear during normal operations for each host group. Alert on pairs that have not appeared in the baseline window, and tune the window length to the change cadence of your fleet. Expect false positives from configuration management agents, endpoint management suites and scheduled backup jobs that launch helpers on demand. Start with one host group and widen only after the baseline stops changing.
Unexpected interpreter script execution
Flag script execution events where an interpreter is started by an IPC-capable parent that does not normally launch interpreters, such as a desktop application or a database service. Set the threshold at first occurrence for servers in production and at a short repeat count for workstations, where users run scripts more often. Common false positives come from installers, browser extensions that bundle helper scripts, and developer tools. Check the command line and the signing status of the script host before escalating.
IPC artifact file access
Monitor file creation and modification in directories that IPC mechanisms use for sockets, named pipes, shared memory handles and runtime state. Alert when a process outside the expected owner writes to these locations, or when a new artifact is created by a process running under a different account than the service that owns it. Software updaters, language runtimes and desktop session managers create similar artifacts, so exclude their signed paths explicitly and review exclusions quarterly. Record the owning process for each artifact path during baselining.
Cross-account IPC invocation
Correlate process creation events where a process running under one account triggers activity in a process owned by a different account, particularly when the target runs with elevated rights. Set the rule to fire on account transitions that have no matching change ticket or service dependency. Administrative tooling, remote management agents and domain logon scripts are the main sources of legitimate transitions, so maintain an allowlist keyed by parent image, target image and account pair. Treat any transition into a privileged account from a user session as high priority.
Sigma rules with version tags
Write each detection as a Sigma rule that names the ATT&CK version it targets, so the mapping can be reviewed when MITRE renames, deprecates or revokes techniques in a later release. Tag the rule with the technique and sub-technique identifiers and record the data components it depends on, such as Process Creation and Script Execution. Test rules against your own log schema, because field names differ between Windows, Linux and macOS collectors. Pin each rule to one ATT&CK version and schedule a review at every release.
How to validate that T1559 detections fire
This sequence proves that each T1559 detection fires on the telemetry it depends on, with the expected fields, within a measured delay, and that every gap is recorded and assigned. It runs in a private cyber range or lab so that the emulation stays inside agreed boundaries and the results can be shared with the detection engineering and SOC teams.
Confirm the ATT&CK version and scope
Before any emulation, the detection lead records which Enterprise ATT&CK version the detection mappings target, because releases can rename, deprecate or revoke techniques. The test is then scoped to one T1559 sub-technique at a time, for one platform (Linux, macOS or Windows), so that a failed result points to a specific detection. The output is a scope sheet listing the sub-technique, the platform, the target hosts in the range and the ATT&CK version, signed off by the detection lead before the test window opens.
Agree rules of engagement in writing
The security testing lead, the range owner and the SOC manager agree the rules of engagement in writing. The document names the hosts in scope, the accounts that may be used, the points at which the test stops, who can halt it, and how the SOC is informed so that the exercise is not confused with a live incident. It also states that no production systems or real user data are involved. The output is a signed rules of engagement document stored with the test record.
Confirm log ingestion before emulation
Before running any emulation step, the platform team checks that the telemetry T1559 detections depend on reaches the SIEM. For this technique that typically means process creation events and the file or module data sources the analytics reference, collected from the test endpoints by the agents in use (for example, Wazuh agents or Sysmon on Windows). The check is a dated record per host showing that the expected event types arrived, with timestamps and fields intact. If any source is missing, the test is paused and the gap is logged before it proceeds.
Run the scoped emulation in the range
A named operator runs the agreed emulation for the single sub-technique in scope, following the written plan and without changing the scope mid-run. The plan describes the behavior in general terms and is kept in the test record; operators do not share ad hoc commands in chat channels. The observer records the start and end time of each step in a shared log. The output is that log, with each step matched to a time window on the range hosts.
Check that each alert fires with expected fields
The detection engineer checks the SIEM for the alert or Sigma-derived rule tied to the emulated step, then reviews the fields it carries, such as the host, user, parent and child process, command line where collected, and the ATT&CK technique and sub-technique tags. A detection that fires on the wrong sub-technique, or that drops key fields, is marked as a partial pass. The output is a per-rule result showing fired, partial or not fired, with the alert identifier as evidence.
Measure detection latency and record gaps
The detection engineer compares the emulation time window with the alert timestamp to measure detection latency, which covers ingestion delay, rule evaluation and alert creation. Each gap, whether a missing rule, a missing data source, a noisy false positive, or a late alert, is entered in a shared tracker with an owner, a severity and a retest date to be agreed. The tracker records the ATT&CK version, the scope, and the range build so that results can be compared across runs. The output is an updated tracker that the SOC and detection engineering teams both review.
Close the test and retest fixes
After the detection owners have made changes, the same sub-technique is retested under the same scope and rules of engagement, so that the before and after results can be compared. The test is closed only when every gap has either a passing result or a documented risk acceptance signed by the accountable owner. The closing record lists the final results per rule, the open items and the retest evidence, and it is retained with the scope sheet for later audit review.
Preventive controls mapped to T1559
T1559 Inter-process communication abuses legitimate channels between processes, so preventive controls focus on who can reach those channels and what endpoints are allowed to do with them. The two ATT&CK mitigations below address the account side and the endpoint behavior side, and each card names what the platform team configures and what evidence an assessor will ask for.
Privileged account management (M1026)
M1026 covers restricting, monitoring and reviewing privileged accounts so that only approved administrators can perform actions that involve sensitive inter-process interfaces. For T1559, the platform team should inventory which service accounts and administrators can start or attach to privileged processes, remove standing rights that are not needed, and log every elevation. Assessors usually ask for the privileged account register, the approval records for elevated access, and a sample of review sign-offs. Confirm with each vendor how its privilege model maps to these controls in your environment.
Behavior prevention on endpoint (M1040)
M1040 uses endpoint tooling to block or flag process behavior that does not match a known-good baseline, such as unexpected parent and child process relationships used for IPC-driven execution. The platform team must decide which behaviors are blocked outright, which are only alerted on, and where exceptions are approved. Assessors typically ask for the policy export, the list of blocked and alerted behaviors, the exception register, and test results showing the policy fires in a controlled exercise. Confirm which behaviors your endpoint product can enforce on Linux, macOS and Windows before writing the policy.
Connecting the controls to detection
Preventive controls fail silently unless their decisions are logged, so each block or exception should produce an event that reaches the SIEM. Map the Process Creation telemetry from the endpoint agent to the policy decisions, so a blocked IPC-driven launch appears next to the account that triggered it. Assessors ask whether the preventive decision is traceable to an identity and a time. Confirm log forwarding, retention and event schema with your vendor and your Wazuh or Security Onion deployment.
Evidence for assessors
A preventive control is only credible when it can be shown working. Keep a versioned copy of each policy, the change record that approved it, and the date it was last reviewed against ATT&CK version 20.0 or the version you target. Add the results of a cyber range exercise in which a controlled IPC-style action was attempted and the control responded. Ask your auditor which artifacts they accept and how often they expect re-testing.
Triage and response when a T1559 alert fires
The first decision on a T1559 Inter-process communication alert is whether the activity is a legitimate application using a local IPC channel or an adversary abusing one to pass work between processes. Start by confirming the parent and child process context in the Process Creation telemetry: which binary created the endpoint, which process it talked to, the command line and the integrity level of each side. A browser, office application or script host talking to an unexpected system service is a stronger escalation signal than a well-known management agent talking to its own helper. Check whether the same host and user have produced similar pairs in the past two to four weeks, and whether the account is a standard user, a service account or a privileged administrator. Confirm the exact fields your Wazuh or Security Onion pipeline normalizes, because a missing parent process field can make a benign pair look suspicious.
Next, pull related file and script events for the same host window. Look for File Creation or File Modification events in user profile, temp or application data paths that occur just before the IPC activity, and for Script Execution records that show a script host or interpreter spawned the initiating process. Collect Application Log Content from the involved services where it is available, and record the time, user and process identifiers in the case notes. Decide on containment based on what you find: isolate the host from the network only when there is a credible chain from an untrusted parent to a privileged target, and prefer disabling a single account or stopping a single service when the scope is narrow. Before any containment, preserve evidence with a collector such as Velociraptor, using an artifact set your team has tested in advance, and hash what you collect so the chain of custody holds. Escalate to incident response when the parent is an untrusted or unsigned binary, when the target is a privileged service or domain-joined asset, or when related alerts appear for lateral movement or credential access. Close the loop afterward: tune the rule by documenting the benign pairs you confirmed and adding exclusions that name the exact parent, child and account, not broad path wildcards. Record the ATT&CK version your rule targets, since releases can rename or deprecate techniques, and update the runbook with the decisions, evidence steps and owners so the next analyst repeats the same checks.
Rehearsing T1559 detection and response in a private cyber range
The Linux range should mirror the production Linux hosts in scope, including the distribution, audit configuration and any container runtime your teams use. Place one or two monitored hosts, a Wazuh manager and agents, and a Security Onion sensor on a segmented lab network with no route to production. Facilitators should confirm which process and file telemetry the host agents actually forward, because Linux process visibility depends on how auditing is configured on each host.
- Topology: Two or three Linux endpoints with Wazuh agents, a Wazuh manager, and a Security Onion sensor mirroring the lab switch span.
- Logging path: Confirm that process creation and file access events reach the Wazuh indexer and that Security Onion receives the matching network metadata for the same hosts.
- Injects: Schedule a benign IPC-style process chain on one host, then a second inject that changes the data a process exchanges with a peer, so analysts must correlate host and network evidence.
- Good detection: An alert reaches the analyst queue within a time window your team agrees before the exercise, and the alert names the host, parent process and user.
- Response quality: Case notes record the hypothesis, the evidence sources checked, the containment decision and the open questions.
Check that the alert threshold, the time to alert and the case note template were agreed before the first inject, so results can be compared across runs.
The macOS range covers a smaller set of endpoints, usually managed workstations with a different logging profile from Linux and Windows. Facilitators should confirm which macOS unified log categories, endpoint agent and file telemetry are available in the chosen Wazuh or Security Onion version, since coverage varies by platform and by agent release. The range should reflect the management tooling and privilege model used in your fleet.
- Topology: One or two managed macOS test endpoints with a Wazuh agent or another endpoint sensor, joined to the same lab network as the Security Onion sensor.
- Logging path: Document which events the endpoint sends to the manager, and which network metadata Security Onion sees, so analysts know the source of each finding.
- Injects: Run an inject where a user-level process hands work to a second process, followed by an inject that uses an elevated context granted through the lab management account.
- Good detection: The detection names the process lineage, the user context and any privilege change, and analysts can explain why the alert fired.
- Response quality: The case notes state which telemetry gaps were found on macOS, because those gaps usually drive the largest follow-up actions.
Confirm the macOS agent coverage gaps before scheduling the exercise, and record them as a known limitation in the range report.
The Windows range should include a domain controller, file or application servers and workstations so that inter-process activity can be seen across hosts. Enable the process creation auditing and command line logging your detection strategies depend on, and confirm the Wazuh agent or Sysmon-style event source delivers those events to the manager. Security Onion adds network context for traffic between lab hosts.
- Topology: A small Active Directory domain with one domain controller, one server and two workstations, each running a Wazuh agent, with a Security Onion sensor on the lab span.
- Logging path: Verify that process creation events and script or command execution events arrive in Wazuh, and that Security Onion records the relevant connections between hosts.
- Injects: Start with a legitimate administrative process exchange, then introduce an inject that uses a named pipe between processes on two hosts, so analysts must link endpoint and network data.
- Good detection: The alert identifies both processes, the account used and the target host, and it is raised within the time to alert agreed for the exercise.
- Response quality: Notes explain how the analyst scoped the activity to other hosts, and they record the decision to isolate or to keep monitoring.
Confirm that the domain controller telemetry is forwarded before the exercise, since gaps there change which containment steps are safe to rehearse.
Questions SOC leads ask about detecting T1559
How do we handle false positives from admin tooling that uses inter-process communication?
Build the allowlist from your own baseline of legitimate activity, and scope each exception narrowly. Record which parent and child process pairs, accounts and host groups use inter-process communication during patching, configuration management and help desk work. Limit each exception by host group, account and time window, so an unexpected call from an admin tool on a different host still alerts. Tie every exception to a named owner and a change ticket, and review the list on a fixed schedule. Test each exception in your cyber range first so you know exactly what it hides. Tuning should reduce noise without switching off the Process Creation and Script Execution signals for the whole estate.
How often should we re-validate T1559 detections after an ATT&CK version change?
Re-validate after every ATT&CK release that touches your mapped techniques, and read the release notes before you start. The pages in this series target ATT&CK version 20.0, and MITRE publishes release notes on its updates page. Recent releases arrived in October 2025, April 2026 and October 2026, so set your review cycle around those dates. Do not assume a detection still maps cleanly after an update. Check sub-technique IDs, data component references and mitigation links against the STIX bundle for the version you run. Keep a change log that names the ATT&CK version each rule targets, so auditors and engineers can see what changed and when.
How do we map our detections to ATT&CK version 20.0?
Map each rule to a technique ID, a sub-technique ID and, where ATT&CK provides one, a detection strategy ID. Since ATT&CK v18, technique pages express detections as detection strategies and analytics, so link your rules to those entries. Pull the technique, sub-technique and data component relationships from the enterprise-attack 20.0 bundle, which MITRE publishes in STIX 2.1 format. Record the ATT&CK version in each rule's metadata. Then produce a coverage matrix that shows which sub-techniques have a working rule and which rely only on raw telemetry. Gaps in that matrix become your next test scenarios.
What should we log on Linux and macOS hosts for T1559 detection?
Collect process creation events with the parent process, command arguments, user context and a file hash where the platform provides one. On Linux this usually means auditd or an EDR sensor, and on macOS it means unified logging together with endpoint agent telemetry. Add script execution logs wherever your interpreters record them, and file access events for the paths your inter-process communication mechanisms touch. Confirm with your agent vendor which events it emits on each platform, because coverage differs between operating systems and versions. Forward everything to your SIEM, such as Wazuh or Security Onion, and verify time synchronization so events correlate correctly. Before go-live, ask the team to show one sample event per data component.
Which mitigations apply to T1559, and how do we verify them?
ATT&CK maps two mitigations to T1559: Privileged Account Management and Behavior Prevention on Endpoint. Privileged Account Management limits which accounts can perform operations that use inter-process communication, so verify it with current privileged account inventories and periodic group reviews. Behavior Prevention on Endpoint depends on your EDR or host controls, so confirm which behaviors it blocks and whether it alerts only or actively blocks. Test each control in the range by attempting the behavior from a non-privileged account and checking what the logs show. Store the evidence for each control with its test date and ATT&CK version. DeployOpen prepares systems and evidence for compliance assessments, but independent auditors issue the reports.
Can our own team run T1559 detection validation, or do we need DeployOpen?
Your team can run it if it has access to endpoint logs, rule management in the SIEM and a non-production environment for controlled test activity. Outside help is most useful when you lack detection engineers, need a repeatable range or want an independent test of your rules. DeployOpen works through fixed-scope engagements, where scope, deliverables and timelines are agreed in writing before work starts. It also offers retainers for ongoing support and continuous testing. Whichever route you choose, ask any provider to state which hosts they will touch, which accounts they will use, how results are reported and who signs off on the test window.
What does a cyber range exercise for T1559 need to include?
A range exercise needs isolated hosts for Linux, macOS and Windows, representative admin tooling and a logging path that matches production. Build test scenarios from the three sub-techniques, document the telemetry you expect for each, and set pass criteria before the run starts. Include benign administrative activity so you measure false positives as well as detections. Record results against ATT&CK version 20.0 IDs so they remain traceable after future updates. Afterward, feed gaps into tuning and repeat the exercise to confirm the fix. Keep the range private so test activity never reaches production networks, and ask your provider how the range is isolated and where its logs are stored.
How DeployOpen builds T1559 detections and range scenarios
DeployOpen plans T1559 Inter-process communication work as a fixed-scope engagement, and the scope comes first. Before any telemetry is touched, the written scope should name the platforms in play (Linux, macOS and Windows endpoints), the three sub-techniques to cover, the ATT&CK version the mappings will target, and the data components the client's logging can actually supply, such as Process Creation, File Access and Script Execution. Because ATT&CK releases can rename or deprecate techniques, the engagement should record the version explicitly, and the client should confirm which version their detection content library already references. Deliverables, acceptance criteria and timelines are agreed in writing before work starts, and the client keeps the decision on which hosts and accounts are in scope.
The detection engineering phase works inside the client's own environment, against their own endpoint agents, Wazuh or Security Onion deployment and log pipeline. The team inventories which processes, handles or IPC-related events are logged today, then writes detection logic in plain terms and tests it against benign baseline activity from representative hosts. Findings typically include gaps in collection, not only missing rules, so the client should expect a list of telemetry changes alongside the rules. Purple team exercises then use the private cyber range or a controlled lab replica to confirm that each detection fires, that alerts reach the right queue and that responders can act on them. Results are documented against the ATT&CK version named in scope, and the client should ask for a clear statement of what was tested and what was not.
Retainers are the right model when the client needs continuous testing rather than a single engagement. A retainer can cover periodic re-validation of T1559 detections after platform upgrades, review of new ATT&CK releases for changes to this technique, and refreshed range scenarios as the environment changes. Clients should confirm with DeployOpen which parts are recurring and which are one-time, and what drives effort up, such as the number of platforms, the volume of logs, and the number of mitigations reviewed. DeployOpen prepares detections, exercises and evidence for compliance assessments, but independent auditors issue any assessment outcome. No outcome, certification or detection rate is implied by this work.
