---
{
  "title": "Process Injection",
  "summary": "Process injection executes code inside another running process.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1055"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1055: Process Injection",
      "url": "https://attack.mitre.org/techniques/T1055"
    }
  ],
  "editorialVersion": 2
}
---

## Code can execute inside another running process

Process injection places or executes code in the address space of another live process. The behavior can make activity appear under a familiar process context and may expose resources available to that context. Implementations and required permissions vary across operating systems and methods.

Not every cross-process operation is malicious. Debuggers, security products, accessibility software, and other legitimate tools may interact deeply with processes. Investigators need the source and target, provenance, authority, operation sequence, and resulting effects.

## A familiar application makes an unfamiliar connection

In a fictional endpoint case, a trusted application begins communicating with an unexplained destination after an unknown program interacts with its process. The analyst reviews endpoint alerts, process identities, memory-related telemetry where available, module information, and network timing.

A legitimate extension or diagnostic tool could explain the interaction. The team checks installed software, approved work, and expected application behavior. A familiar target process name does not establish that every action performed in its context originated from its normal code.

The sensor may report a high-level injection detection without exposing every underlying operation. Inspect supporting evidence and avoid naming a specific injection method unless the records or controlled analysis support it.

## Preserve volatile context

Memory and process state can disappear when processes terminate or devices restart. Collect relevant volatile evidence through an authorized process where practical, balancing preservation against ongoing harm. Record response actions that change the state.

[[memory-forensics]] can support deeper examination, subject to acquisition quality and tool limitations. [[inter-process-communication]] describes another relationship between programs but does not necessarily involve injected code. [[shared-modules]] concerns code loading and should not automatically be treated as injection.

A suspicious memory region or cross-process access event is a lead. Establish its relationship to actual execution and harmful behavior before making a stronger conclusion about the incident.

## Contain the source and resulting access

Stopping the target process may interrupt activity but also remove useful evidence. Restrict the affected host or process as justified and investigate the program or access path that initiated the interaction. Review related credentials and resources according to what the resulting context could reach.

Removing one injected process does not necessarily remove a recurring launcher or compromised account. Recovery should address those enabling conditions and verify expected application behavior.

For practice, compare an approved debugger with a fictional unknown process interacting with a browser before an unexplained connection. Identify provenance, identity, memory, sequence, and network evidence needed for a decision. [[incident-reporting]] should distinguish sensor observations, analytical interpretation, and confirmed effects.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[incident-response]]