Attackers use code inclusion in an existing process to run malicious code inside a trusted process and inherit its privileges, network access, or user context. That can hide activity from simple process-based controls. Defenders should watch for unusual module loads, script execution, process injection behaviour, and mismatches between a process’s normal function and its actions.
Why code inclusion in a running process works
Attackers use code inclusion in an existing process to borrow a legitimate process’s trust. By executing inside that process, malicious code can inherit its permissions, network reach, and user context, which often makes it harder for basic tooling to distinguish abuse from normal activity. The technique is effective because the process itself is still “known good” to many controls.
That trust relationship is the whole point. Instead of launching an obviously suspicious standalone binary, the attacker tries to blend malicious activity into a process that already has a valid business purpose, which can reduce visibility and delay detection.
How the technique changes detection and response
Once code runs inside another process, defenders often lose the simple signal of “bad executable in bad place.” Monitoring needs to shift to behavioural clues such as unexpected module loads, suspicious script execution, abnormal child processes, remote thread creation, and other forms of process manipulation. Controls that only whitelist process names or paths can miss this class of abuse.
Code inclusion also complicates response because the trusted process may be doing both legitimate and malicious work at the same time. That makes it important to distinguish the process’s normal baseline from the attacker’s injected activity, rather than treating every action by that process as equally trustworthy.
For defenders building analytics around process behaviour, the most useful evidence is often the mismatch between the process’s expected function and the actions it is performing. A browser spawning PowerShell, an office application loading unusual libraries, or a service process reaching out in a way it never normally does are all examples of that mismatch.
What defenders should verify in practice
When investigating suspected process abuse, start by confirming whether the process should ever load the module, script engine, or child process you observed. If not, treat the activity as suspicious even if the parent process name looks familiar.
Then look for the surrounding tradecraft: memory modification, injected threads, tampered script blocks, hollowed or suspended processes, and signs that telemetry may be incomplete because the attacker is running inside a trusted boundary. That helps separate benign automation from covert execution.
EDR Evasion and Defence Guide is useful here because the same process manipulation patterns that enable code inclusion are also used to blind or confuse defensive tooling.
Risk and Threat Considerations
Code inclusion in an existing process is risky because it turns a trusted execution container into an attack vehicle. The technique is attractive to attackers precisely because it can inherit permissions, evade simple allowlists, and operate with less obvious telemetry than a separate malicious process.
Failure mechanism: The attacker injects or loads code into a legitimate process, then uses that process’s trust, privileges, and normal network paths to conceal execution and expand access.
Impact: Defenders may miss the malicious activity, misattribute it to a trusted application, and respond too late to prevent credential theft, lateral movement, or deeper compromise.
MITRE D3FEND Guide helps map this problem to defensive techniques such as process lineage analysis, process self-modification detection, and script execution analysis.
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 NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1055 — Process Injection | This technique directly describes running code inside another process. |
| T1218 — System Binary Proxy Execution | Abuse often rides trusted executables to disguise malicious code execution. | |
| Recommendation — Map injected execution to T1055 and hunt for process manipulation and memory tampering. Inspect trusted binaries for unusual child processes, modules, and command lines. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Process inclusion demands behavioural monitoring of modules, scripts, and process anomalies. |
| AU-6 — Audit Review, Analysis, and Reporting | Reviewing logs and correlating process behaviour is essential for confirming abuse. | |
| CM-7 — Least Functionality | Reducing unnecessary process capabilities limits the value of code inclusion attacks. | |
| Recommendation — Tune SI-4 monitoring to alert on abnormal process behaviour and injected execution. Correlate audit evidence across process, module, and network events to confirm compromise. Remove unneeded process privileges and scripting paths to shrink abuse opportunities. | ||
Practitioner Guidance
What to prioritise: Focus first on processes that should be stable and predictable, such as core services, admin tools, browsers, and scripting hosts. Those are common abuse targets because small deviations in their behaviour can carry outsized risk.
What to verify: Confirm whether the suspicious action is normal for that process, not just whether the process exists on an approved host. Process identity alone is a weak trust signal when the payload can run in memory or inside another executable’s context.
What good looks like: Your detections should correlate process ancestry, module load behaviour, script execution, and network activity so a trusted process cannot quietly act like an attacker without producing an alertable mismatch.
Practitioner takeaway: The core defence is not to trust the process name, but to trust the process only when its behaviour still matches its expected role.