Process Injection

Attackers run their code inside another, legitimate process instead of in a program of their own. It is a technique that serves two tactics at once: hiding the attacker's activity under a trusted process's name, and sometimes gaining that process's privileges. To most tools, the work then appears to come from the trusted process.

The attacker's program opens a running process, writes code into its memory and starts a thread there, or replaces a newly started process's code before it runs. The host process keeps its normal name and path, so process lists look ordinary, while network connections and file activity now come from it. Many attack frameworks do this automatically after they first run.

Data source: Sysmon events; Elastic Defend alerts

{
  "host": {
    "name": "ws-529.corp.example"
  },
  "event": {
    "code": "8"
  },
  "winlog": {
    "event_data": {
      "TargetImage": "C:\\Windows\\System32\\notepad.exe"
    }
  },
  "process": {
    "executable": "E:\\Depot\\upd7.exe"
  },
  "@timestamp": "2026-06-16T13:20:37.502Z"
}

Prebuilt Elastic rule: Process Injection by the Microsoft Build Engine

Sysmon records event 8 only when its configuration includes it, and Elastic Defend's memory alerts need that protection turned on. Start with remote thread creation: event.code: 8, grouped by process.executable and the target program. Then set aside the known sources in your environment, such as security tools and accessibility software. Look for sources running from user-writable folders, ordinary programs such as text editors receiving threads, and target processes that start making network connections they never made before. The prebuilt rule named on this page fires only when the Microsoft Build Engine starts the thread, so for any other source this hunt is the detection.

Security products, debuggers, accessibility tools and some system components start threads in other processes as part of normal work. Check the source program's path and signer, whether it is installed software, and what the target did afterward. A thread started from a program in a temporary folder, followed by new network activity, is the case to chase.

The log events that help detect this technique, from the Telemetry reference: which log source to collect, which event in it, and how to enable each one.

• Linux audit framework (auditd)
  • SYSCALL:mmap SYSCALL record for mmap
  • SYSCALL:open SYSCALL record for open
  • SYSCALL:process_vm_writev SYSCALL record for process_vm_writev
  • SYSCALL:ptrace SYSCALL record for ptrace
• Other Linux sources (procfs, FIM, package logs, shell history) (the log as a whole)
• macOS Endpoint Security framework events
  • ES_EVENT_TYPE_NOTIFY_EXEC
  • ES_EVENT_TYPE_NOTIFY_MMAP
• macOS unified log (the log as a whole)
• ETW providers (not persisted to a log by default) (the log as a whole)
• Sysmon
  • 1 Process creation
  • 10 ProcessAccess
  • 7 Image loaded

• MITRE ATT&CK, Process Injection

No range covers this technique yet; the write-up above landed first. Ranges are added continuously; the ones live today are on the training ladder.