In-memory process injection is an attack technique where malicious code is placed into a running process’s memory instead of being launched as a separate file. It is used to hide execution, reuse a trusted process context, and bypass controls that focus on files rather than live process activity.
What this technique does in practice
In-memory process injection is a post-compromise execution technique, not a standalone payload type. Attackers use it to place code inside an existing process so execution blends with normal activity and can bypass controls that rely on file creation, file hashing, or simple allowlists.
This matters because the security boundary shifts from the file system to live process behaviour. Once code runs inside another process, defenders often need telemetry from process access, thread creation, module loading, memory scans, and tamper signals rather than only endpoint file events.
Common injection patterns and what they change
The broad technique includes several families, such as DLL injection, process hollowing, APC or thread hijacking, reflective loading, and related memory-only execution methods. The exact path determines what traces remain, but the defensive challenge is the same: malicious code borrows the context of a trusted process.
That borrowing can change what security tools see, what identity the action appears to come from, and which process is blamed in logs. It also means defenders should think in terms of process lineage, memory artefacts, and cross-process operations, not just whether a suspicious file landed on disk.
For a practical defensive overview of how these behaviours are hunted and blocked, T1055 Process Injection Defensive Guide maps the technique to concrete detection paths.
Why memory-only execution is hard to catch
Memory-only execution is attractive because it reduces the obvious indicators many endpoint controls were built around. A process can be started legitimately, then altered after launch, which makes the malicious portion harder to distinguish from ordinary runtime behaviour unless the defender watches for memory tampering and suspicious inter-process access.
This is also why response teams often pair host telemetry with memory inspection. If a process was hollowed, injected, or used as a host for shellcode, the decisive evidence may live only in volatile memory and related runtime artefacts.
When defenders need to reconstruct what actually ran, Memory Forensics Guide explains how to capture and analyse volatile evidence safely.
Defensive priorities for detection and response
The strongest detections usually combine process-access events, suspicious remote-thread or memory-write activity, unexpected module loads, and tamper or injection indicators from EDR telemetry. Single signals are often noisy; correlated signals are what turn a generic anomaly into a credible injection hypothesis.
After detection, responders should review the host for persistence, credential access, lateral movement, and any security tools that may have been blinded or bypassed. Injection is often one step in a larger intrusion chain, not the end of the story.
EDR Evasion and Defence Guide is useful when process injection is paired with sensor blinding or defence impairment, and Defence Evasion Techniques Guide helps place it inside the wider stealth toolkit. Where the activity resembles commodity post-exploitation tooling, Sliver, Havoc and Brute Ratel C2 Frameworks Detection Guide gives a useful hunt-oriented context.
How organisations reduce exposure
Reducing exposure means hardening both the endpoint and the monitoring model. Controls that inspect only executable files miss an important part of the attack surface, so organisations need telemetry for process creation, cross-process memory access, and suspicious runtime modification, plus prevention rules that restrict common injection primitives where feasible.
Because injected code lives in memory, compromise review should not stop at the obvious parent process. Investigators should look for the host process, the origin of the injection, any disabled protections, and whether the activity was used to stage additional malware, harvest secrets, or manipulate trusted tooling.
For triage and sweep-style validation after suspicious activity, IOC Scanners Guide can help with broad compromise assessment, while Volatility 3 Guide supports deeper memory investigation on infected hosts.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1055 — Process Injection | Process injection is the exact ATT&CK technique described by this term. |
| Recommendation — Map runtime injection telemetry to T1055 and hunt for cross-process memory tampering, hollowing, and remote-thread activity. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Runtime injection is a malware delivery and execution problem addressed by malware defence safeguards. |
| Recommendation — Apply CIS-10 to detect and block malicious in-memory execution and related endpoint tampering. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Injected code is malicious code executed through a host process and falls under code protection controls. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Injection detection depends on correlating audit and EDR events that reveal process abuse. | |
| Recommendation — Use SI-3 to detect, block, and contain malicious code that executes inside trusted processes. Correlate process, thread, and memory telemetry under AU-6 to surface injection chains. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | Applications and services should log and surface suspicious runtime behaviour and tampering signals. |
| Recommendation — Instrument runtime logging so abnormal process manipulation and tampering are visible to defenders. | ||
Related resources from NHI Mgmt Group
- What are the signs that endpoint malware is hiding through process injection or memory-only execution?
- How should teams respond if an AI runtime may have leaked process memory?
- What should teams do before an in-memory injection chain completes?
- What breaks when a worker-process memory corruption issue is exposed through crafted HTTP requests?