How T1055 process injection hides malicious code inside trusted processes
When a SOC lead sees an alert that a trusted process, such as a system service, a browser or an administrative tool, has changed its memory or started threads it never normally creates, the first question is whether the process is running its own code or someone else's. T1055 Process injection is the ATT&CK technique that explains this pattern. Under the Stealth tactic (TA0005), an adversary places code into the address space of a legitimate running process so that the malicious activity appears to come from software the organization already trusts. Defenders most often meet it after an initial foothold, when the attacker needs to run code, reach credentials or persist without launching a new, suspicious binary. T1055 is a technique family rather than a single method. ATT&CK groups its 12 sub-techniques by how the code gets into the target process and how it is started, and different platforms, including Linux, macOS and Windows, expose different variants. Because the family is broad, a single alert rule rarely covers it. The mapping on this page targets Enterprise ATT&CK version 20.0, and the sub-technique list should be checked against that version before it is used to scope detection work, since releases can rename or deprecate entries.
The practical decision for the SOC lead is which trusted processes are expected to show memory or thread activity and which are not. Build that baseline from your own endpoint inventory, then confirm with the endpoint detection vendor and your Wazuh, Security Onion or Velociraptor deployment which telemetry each platform actually records, such as process access or module load events, before promising coverage for any sub-technique. Treat unexplained activity in a trusted process as an incident to triage rather than as noise, and record each finding against the ATT&CK version your rules target so later reviews can trace the mapping.
Which telemetry reveals process injection and which open-source tool collects it
This table maps the telemetry that reveals T1055 Process Injection to the signal to look for and the open-source collector that gathers it. Read each row as a detection input: the signal names what changed in a process, and the collector names where that change is recorded. Coverage varies by operating system, so confirm each collector in your own environment before relying on a row.
| Telemetry (data component) | Signal to look for | Open-source collector |
|---|---|---|
| Process Access (DC0035) | One process opening another with memory write or thread creation rights, especially where the source process is unusual for that role | Sysmon-style event collection on Windows forwarded to a Wazuh agent; Velociraptor for hunting process handles across hosts |
| Module Load (DC0016) | A library or image mapped into a process that does not match its normal module set, or a module loaded from an unexpected path | Sysmon-style image load events on Windows; auditd or eBPF-based collection on Linux; Wazuh agent for shipping events |
| Process Creation (DC0032) | A process started with a parent that does not match its expected lineage, or a child process spawned from a host process that normally does not create children | Sysmon-style process creation events on Windows; auditd execve records on Linux; Wazuh rules for parent and child matching |
| File Creation (DC0039) as supporting context | A file written to disk shortly before or after an injection-like event, such as a dropped payload or staging file in a temporary directory | Wazuh file integrity monitoring and Sysmon file create events; Velociraptor artifacts for collecting files on demand |
| Network Connection Creation context (Zeek or Suricata) | Outbound connections from a process that was recently involved in suspicious memory activity, used to link host and network evidence | Zeek connection logs or Suricata alerts in Security Onion, correlated with host events by time and host identity |
| Platform coverage | Windows exposes the richest process access and image load events; Linux and macOS coverage depends on kernel auditing and collector configuration | Confirm with the client which sub-technique platforms are in scope and which telemetry each endpoint actually produces |
| Sensor tuning and noise | Legitimate security, backup and debugging tools also open handles and load modules, so baselines per host role are needed | Wazuh rule tuning and Velociraptor hunts scoped by role; document exclusions and review them on a schedule |
Detection logic for process injection that SOC teams can tune
Process injection hides code inside processes that already have trust, so the useful signals come from what a process does to another process, what it loads, and how it was started. The four cards below pair each detection idea with a local threshold and the false positives that tend to flood the queue, and they should be written as Sigma rules that name ATT&CK v20.0 in their tags.
Cross-process memory writes into trusted processes
Process Access telemetry is the core signal for T1055. Alert when a process opens a handle to a higher-trust process such as a system service, a browser or an authentication process, with write or thread-creation rights requested. Set the threshold by counting how often each source image touches each target over two weeks of baseline, then alert only on pairs that never appear in that baseline. The main false positives are EDR agents, debuggers, crash reporters and backup agents, so allowlist them by signed publisher and install path, not by process name alone.
Remote thread creation into other processes
A thread created in a process by another process is a direct indicator of remote thread injection, and it is one of the highest-fidelity forms of this technique. Correlate Process Access and Process Creation events that show a thread start in a target that was not spawned by its parent. Tune the rule by excluding known just-in-time compilers, game anti-cheat and profiler agents, which create threads in other processes for legitimate reasons. Confirm locally which of these your endpoints run before you promote the rule from alerting to blocking.
Unsigned modules loaded into system processes
Module Load telemetry can show an unsigned or unexpectedly located DLL or shared object loaded into a system process such as a service host or a directory service. Alert when the loaded image path falls outside the vendor install directories you have baselined, or when the signer is missing or untrusted. Software updaters, language runtimes and endpoint agents are the usual sources of noise, so build the allowlist from observed signed publishers, and review any new entry against change records before accepting it.
Parent-child anomalies after process creation
After a process is created, the relationship between parent and child can reveal injection or a hollowed process. Flag system processes whose parent is unexpected, such as a service host launched by a user shell, or a trusted binary that starts with a parent it has never had in your baseline. Set the threshold per host role, since a domain controller and a developer workstation have very different normal trees. Scheduled tasks, installers and management tools cause most of the false positives, so document each accepted pattern with an owner and review date.
How to validate the process injection detection before trusting it
This sequence proves that the T1055 Process Injection detections fire on known-good emulated activity, that the telemetry they depend on actually reaches the SIEM, and that every gap is written down before the rules are relied on in production. It produces a dated record of each run that can be repeated after any rule or agent change.
Scope the test to named hosts
The detection owner and the platform lead agree in writing which Linux, macOS and Windows hosts in the cyber range take part, which operating system versions they run, and which agent versions and logging configurations they carry. Each host gets an asset identifier and a named owner, and the scope excludes any production system. The step is done when the scope document is approved and every host in it is listed with its agent and log sources. Confirm the range is isolated from production networks before any emulation is scheduled.
Confirm telemetry reaches the SIEM
Before any emulation, the team checks that Process Creation, Module Load and Process Access events from each scoped host arrive in the SIEM, with timestamps, process identifiers, parent process details and the user context present. Missing fields are logged as gaps, not silently accepted. Where the data source relies on an endpoint agent such as Wazuh, Velociraptor or a Sysmon-class collector, the team confirms the collector version and configuration on each host. The step closes when a sample event from every scoped host and data component is visible in the SIEM search.
Load the approved emulation plan
The team uses an emulation plan approved by the security lead and the system owners, mapped to T1055 and its sub-techniques for the platforms in scope. The plan lists each test case by ATT&CK technique and sub-technique ID, the target host, the expected detection, the expected data components and the stop conditions. Test cases are described as behaviors to be observed, and the actual execution steps stay in the controlled range runbook. The step is complete when the plan is signed off and the ATT&CK version it targets is named on the plan.
Fire each detection idea in order
A tester who is not the rule author runs each approved test case on its scoped host while a second person watches the SIEM and the endpoint console. Each case is run once under a clear label so its events can be matched to it later. The tester records the start and end time of each case and any unexpected side effects that would need to be cleaned up. The step closes when every planned case has been executed or formally marked as skipped with a reason.
Record alert timing and field completeness
For each case, the analyst records whether an alert fired, which rule or analytic produced it, the time from the emulated action to the alert, and whether the expected fields such as parent process, image path, command line context and target process are populated. Timing is measured from the event timestamp to the alert timestamp in the SIEM. A case with an alert but missing key fields is marked partial, not passed. The step is complete when each case has a result of detected, partial or missed, with the timing and field notes attached.
Document gaps and assign owners
Every missed or partial result becomes a gap record with the technique ID, the platform, the missing data component or rule logic, the likely cause and a named owner. Gaps are triaged into telemetry fixes, rule tuning and accepted risk, and accepted risk requires a sign-off from the risk owner. The team avoids describing gaps as false positives until the analyst has confirmed the benign cause. The step closes when every gap has an owner, a status and a linked ticket in the tracker.
Re-test after rule or agent changes
Any change to a detection rule, an analytic, an endpoint agent version or a logging configuration triggers a targeted re-run of the affected test cases and a check that the telemetry from Step 2 still arrives. The retest record names the change, the ATT&CK version and the cases re-run, and it compares results with the previous run. Changes to ATT&CK itself, such as a technique being renamed or deprecated in a later release, are reviewed against the detection mapping before the next run. The step is done when the comparison record is filed with the detection inventory.
Archive the run record for review
The team stores each run as a single record containing the scope, the emulation plan version, the host list with agent versions, the telemetry check results, the per-case outcomes, the timing and field notes, the gap register and the sign-off names. The record is kept in the change management system so that auditors and internal reviewers can trace which rules were trusted on which date. The step is complete when the record is filed, the detection owner has reviewed it and the next scheduled validation is recorded.
How endpoint telemetry, rules and alerts connect in a process injection pipeline
For T1055 Process injection, detection depends on a chain of four links: the endpoint agent that observes Process Access and Module Load events, the log pipeline that forwards them, the SIEM rule engine that evaluates them, and the analyst queue that receives the alert. A gap at any link looks identical to a quiet endpoint, so the first job is to confirm that each link is working before tuning rules. Process Access (DC0035) and Module Load (DC0016) are the data components that carry most of the signal for this technique, and they are also the events most often disabled or dropped by default. On Windows, check that the sensor collects handle-open events against sensitive target processes and that image load logging is enabled in the agent policy. On Linux, confirm that the agent's process and memory-related audit rules are loaded, because a missing rule produces no error in the SIEM.
Loss usually happens in configuration rather than in the attack path. Common failure points include an agent policy that was narrowed for performance, a forwarder that filters events by a channel or event ID list written before these data components were in scope, a parser that drops fields such as source process, target process or granted access, and a time-sync drift that breaks correlation between Process Creation and later Module Load events. The first checks are therefore: compare event counts per host against a known baseline over a fixed window, replay a benign test that is known to generate Process Access and Module Load events, and confirm that the target and source process fields survive parsing end to end. Record the agent version and policy identifier on every host so that a gap can be traced to a specific configuration.
Once the events arrive, the rule engine should be tuned to the ATT&CK version your rules target, since detection strategies and data component mappings change between releases. The MITRE ATT&CK updates page lists the current release history, and your rule metadata should name the version it was written against. Route alerts to an analyst queue with the telemetry fields needed for triage attached, and track how often a rule fires with no confirmed gap in the pipeline. Confirm these details with your SIEM and agent vendors, because event availability and field names differ by product and version.
Preventive controls mapped to ATT&CK mitigations for T1055
MITRE maps two mitigations to T1055 Process injection that matter most for prevention: Behavior Prevention on Endpoint (M1040) and Privileged Account Management (M1026). Each limits a different part of the attack path, so the controls below should be planned, owned and tested together rather than switched on in isolation.
Behavior Prevention on Endpoint
This mitigation (M1040) uses endpoint controls that watch behavior, not only file signatures, and can block or interrupt suspicious process activity. For T1055, the relevant question is whether your endpoint product can block or alert when one process writes into, allocates memory in, or starts a thread inside another process that it has no business touching. Confirm with the endpoint vendor which injection-related behaviors are blocked in prevention mode, which only alert, and which are covered on Linux and macOS as well as Windows.
Staged rollout of prevention rules
Prevention settings that block cross-process memory writes can break legitimate debuggers, profilers, accessibility tools, backup agents and other security products. Start in detect-only or audit mode, build an exception list from documented business software, and move to blocking one device group at a time. Keep a rollback path tested before each stage, and record who approves each exception.
Privileged Account Management
This mitigation (M1026) limits who holds the rights needed to open or modify other processes, which is a precondition for much injection activity on Windows and Linux. Review which accounts hold debug privileges, ptrace-style rights, or equivalent administrative access on servers and workstations. Confirm that privileged sessions are brokered, time-limited and logged, so that an injection attempt by a compromised user is harder to perform and easier to attribute.
Identity team review of debug rights
Ask the identity team to list accounts and service principals that hold rights to inspect or debug processes owned by other users, and to document why each one needs them. Remove standing grants where a just-in-time elevation process can replace them. Developers who need debugging on production hosts should use a separate, audited path, not shared administrator accounts.
Exception handling for security tools
Security agents themselves often inject into or read from other processes, so a blanket block can silence the defenses you rely on or trigger noisy false positives. Maintain a written inventory of approved products that perform cross-process access, pin them to specific signed binaries and versions, and review that list after every agent upgrade. Treat any exception as a documented risk decision.
Validate controls in the cyber range
Before relying on these controls in production, replay benign and simulated injection behaviors in a private cyber range and check whether the endpoint product blocks, alerts or stays silent. Record the outcome for each configuration and each operating system. Re-run the same tests after policy changes and agent updates so that the evidence reflects the current state of the fleet.
What to do in the first hour after a process injection alert fires
The first priority is to decide whether the alert describes a real injection into a trusted process or a benign pattern, such as an endpoint security agent or a debugger touching another process. Start with the target process: confirm which executable was written to or had code mapped into it, which user account it runs under, whether it is a system service, and whether its binary path and parent match what your build or asset inventory expects. A legitimate browser or Office process receiving remote thread creation from an unknown binary is a far stronger signal than the same event against a developer tool that the team uses daily. Record the target's trust level before anything else, because it determines how quickly you move to containment.
Next, examine the injecting process and its lineage. Trace its parent chain back to the logon session or to a remote session, and note whether the binary is signed, which signer issued the certificate, and whether the file was recently written or downloaded. Unsigned or recently created binaries that spawn into established processes should move up the queue. Then scope the pattern: search your Process Creation, Module Load and Process Access telemetry for the same injecting binary hash, signer, target image and command pattern across other hosts over the preceding days. Confirm the telemetry sources actually cover those hosts before you conclude that the pattern is isolated, since gaps in coverage are a common reason a single-host finding turns out to be broader.
Preserve evidence before you reboot, reimage or kill anything. Capture memory from the affected host using your approved tooling, export the relevant endpoint and EDR events, and keep a copy of the injecting binary and its hash. Decide on containment based on the target's role: isolating a workstation is usually proportionate, while a domain controller or a production database host may need a scoped network restriction and a named incident commander. Escalate to your incident response lead and, where the target handles regulated data, to privacy or compliance contacts as soon as the injection is confirmed or the scope crosses one host. Record decision times, who approved each containment step, the evidence hashes and every open question, because these notes become the basis of the post-incident review and of any detection tuning that follows.
Rehearsing process injection detection in a private cyber range
The range should mirror the estate you actually defend, so detections are tested against the telemetry your endpoints really produce. A minimal design includes Windows and Linux endpoints enrolled in the same SIEM, a Wazuh manager and indexer receiving agent events, and a network sensor such as Zeek or Suricata placed on the segment where the endpoints communicate. Keep the range isolated from production networks and build it from pinned images so every run starts from the same baseline.
- Endpoint telemetry: Confirm that process creation, module load and process access events are collected on Windows, and that the Linux and macOS hosts forward the process and file activity your Sigma rules depend on.
- Wazuh coverage: Verify agent versions, decoders and rule sets on the lab manager match the versions you run in production.
- Network sensor placement: Place the sensor so it sees east-west traffic between endpoints and the management plane, not only north-south traffic.
- Time and identity sync: Synchronize clocks across all nodes so events can be correlated across hosts.
- Isolation and snapshots: Snapshot each host before a run and restore it afterward, so results are repeatable.
Before the first run, ask your platform team to confirm which telemetry sources are enabled in the lab and which are missing compared with production.
Injects are the controlled events the facilitation team introduces to the blue team during the exercise. For process injection, describe each inject by the telemetry it should generate, not by the technique steps that produce it. This keeps the exercise focused on whether defenders can detect and interpret the evidence. Pace the scenario in phases so the team has time to triage, pivot and document before the next inject arrives.
- Telemetry-first briefs: Write each inject as an expected set of data components, such as Process Creation, Module Load or Process Access, with the host and time window where it should appear.
- Phased release: Start with a single low-noise event, then add correlating events on other hosts so analysts must link evidence across sources.
- Benign noise: Include routine administrative activity so analysts practice separating normal behavior from suspicious behavior.
- Decision checkpoints: Pause after each phase for the team to state its current hypothesis and the evidence behind it.
- Facilitator log: Record the exact time each inject was released so detection latency can be measured afterward.
Agree the inject list, pacing and stop conditions with the exercise sponsor in writing before the run, and confirm that no inject reaches production systems.
Good detection for process injection means the team raised an alert based on correlated evidence, classified it correctly and contained the affected process without disrupting unrelated services. Score the exercise on outcomes the team can act on, and record the ATT&CK version and detection strategy identifiers used so results stay comparable across reruns. Because the technique spans several sub-techniques and platforms, score each sub-technique family separately.
- Detection coverage: Record which injects produced an alert, which produced only raw telemetry, and which produced nothing.
- Time to detect: Compare the inject release time in the facilitator log with the alert time in Wazuh or the SIEM.
- Triage quality: Check whether analysts linked process, module and network evidence before escalating.
- Response actions: Score containment steps such as isolating the host, collecting process memory or artifacts, and documenting the timeline.
- False positive handling: Count benign activity flagged as malicious and note the tuning changes proposed.
Ask your security lead to confirm the scoring thresholds and the retest interval before the first exercise, so the results can feed back into detection engineering.
Practitioner questions about detecting T1055 process injection
How do I separate process injection from normal EDR and debugger activity?
Start by building an allowlist of known-good sources from your own estate, not from a generic baseline. EDR agents, debuggers, crash reporters, profilers and application runtimes all open handles into other processes, so a Process Access event alone says little. Look for combinations: a source process with no legitimate reason to touch a sensitive target, access rights that go beyond what the vendor documents for that agent, unsigned or recently written binaries, or a target that is a system process. Confirm the exact access masks and signing behavior for your agents with each vendor before you tune, because these details change between product versions. Record every exception with an owner and a review date so that tuning stays auditable.
Which telemetry matters most for process injection on Linux versus Windows?
On Windows, the highest-value sources are usually Process Access and Module Load, because injected code often requests a handle to another process and then brings in or maps code into it. On Linux, the equivalent signal is more often process tracing, memory mapping and dynamic library loading than a single Windows-style handle event, so you need to confirm what your auditing framework and kernel configuration actually record. Process Creation remains useful on both platforms as context for parent and child relationships. Map each data source you collect to the ATT&CK data components it supports, and check the sub-technique notes for the platforms you run. Whatever you choose, test that the events arrive in your SIEM with the fields your rules depend on.
How should I tune Process Access rules without missing real injection?
Tune by narrowing scope, not by suppressing whole categories. Begin with high-sensitivity targets such as authentication services, security agents and processes that hold credentials, then add rules for unusual source paths or sources that do not match their expected parent. Use allowlists with specific hashes, signers and paths rather than broad wildcards, and expire every exception on a schedule. Rehearse each tuning change in a private cyber range against replayed telemetry so you can measure what the change hides. Keep a record of rules disabled or adjusted, because reviewers will ask why an alert went quiet.
How do I keep detections aligned when ATT&CK changes versions?
Pin every detection mapping to a named ATT&CK version, and record that version in the rule metadata. MITRE released v18 on October 28, 2025, moved detections into detection strategies and analytics, and made major changes to data components. Later releases, v19 on April 28, 2026 and v20 on October 13, 2026, have also changed tactic and technique structure, including the split of Defense Evasion into Stealth and Defense Impairment. Review the release notes for each version, compare the Enterprise STIX bundle for your target version, and update mappings for T1055 and its sub-techniques in one controlled change. Confirm the current structure directly on the ATT&CK site before you publish a mapping.
How do I measure detection coverage for T1055 across the estate?
Measure coverage as the share of in-scope hosts and telemetry sources where each T1055 sub-technique has a tested analytic, not as a count of rules. Build a matrix that lists each sub-technique, the platforms you run, the data source feeding it, and the last date a cyber range exercise confirmed the alert fired. Gaps appear where a platform has no telemetry or where an analytic was never validated. Review the matrix after each ATT&CK version change and after major agent upgrades. Auditors and assessors usually ask for this evidence in a repeatable form, so store exercise results with timestamps and the rule versions tested.
Can my own team run these detections and exercises without outside help?
Yes, many teams do, provided they have the skills and time for it. The work splits into telemetry engineering, rule authoring, tuning, validation in a test environment and documentation, and each part recurs as platforms and ATT&CK versions change. An in-house team needs staff who understand both Windows internals and Linux process behavior, a lab that mirrors production closely enough to be useful, and a process for approving exceptions. If any of these are thin, a fixed-scope engagement can define deliverables in writing, such as a tested rule set for an agreed platform list, with ongoing support available as a retainer. Ask any provider to state in writing which telemetry sources, platforms and ATT&CK version are covered.
How DeployOpen builds process injection detections and range exercises
DeployOpen treats T1055 Process injection as a detection engineering and validation problem inside your own environment, not a generic monitoring rollout. Each engagement starts from the telemetry you already collect, the platforms you run, and the ATT&CK version your detections must target.
How we scope
- Confirm which operating systems (Linux, macOS, Windows) and sub-techniques of T1055 are in the written scope.
- Inventory Process Creation, Module Load and Process Access telemetry, and state which sources are missing or unreliable.
- Name the ATT&CK version the detections target, so mappings stay correct when techniques are renamed or revoked.
How we build
- Write detection logic for Wazuh, Sigma and Security Onion rules in plain language, tied to data components rather than single tools.
- Map each rule to the ATT&CK mitigations in scope, including Behavior Prevention on Endpoint and Privileged Account Management.
- Tune rules against benign admin and software activity from your own baseline to reduce noise before handover.
How we hand over
- Deliver a detection catalogue with rule logic, data source dependencies, known blind spots and validation steps.
- Document response runbooks for suspected injection, including evidence capture and escalation paths for your SOC.
- Run a rehearsal in a private cyber range so your analysts have seen the detections fire before go-live.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope delivery.
- Re-validate T1055 detections when your telemetry changes or when a new ATT&CK version is adopted.
- Ask any partner to confirm in writing what is included in the scope, deliverables and timeline before work starts.
