Inclusion of Code in Existing Process is a technique where malicious code is loaded or run inside a legitimate process. Attackers use it to hide activity, inherit trust, and interfere with detection that watches only new processes. Defenders should monitor unexpected modules, remote thread creation, and process injection patterns.
What Inclusion of Code in Existing Process Means
Inclusion of code in an existing process is a stealth technique, not a standalone exploit result. The attacker places malicious code inside a legitimate running process so the activity appears to belong to trusted software instead of launching a visibly separate program.
This matters because many detection rules and operator workflows still rely on process creation as a primary boundary. Once code is executing in a trusted process, the malicious activity can blend into expected telemetry, reuse the process’s privileges, and complicate simple allowlist or parent-child process analysis.
How the Technique Works
The core idea is to move execution into a process the system already trusts. That can happen through process injection, remote thread creation, module loading, or other methods that alter the behavior of an already-running process without starting a new obvious one.
In practice, defenders look for anomalies such as unexpected memory changes, suspicious module loads, unusual thread activity, and process trees that do not match the software’s normal behavior. Process-level deception often works best when defenders only inspect new executables and ignore what happens after a process starts.
Why Attackers Use It
Attackers use this technique to reduce visibility and make malicious activity harder to separate from legitimate application behavior. It is especially useful when the goal is persistence, lateral movement, credential abuse, or payload staging inside a long-lived service process.
The trust the host assigns to the process can also become a defensive blind spot. Security tools may treat the process as benign, or may miss the malicious code because the parent process, image name, or signer looks normal even while its runtime behavior is not.
For defenders mapping process behavior to established hunting patterns, the MITRE ATT&CK Enterprise Matrix helps connect this technique to broader adversary tradecraft, while the MITRE D3FEND Guide is useful for understanding defensive artefacts and countermeasures around process analysis.
Detection and Defensive Controls
Detection should focus on runtime behavior, not just process starts. That means watching for remote thread creation, suspicious memory permissions, unexpected DLL or module loads, anomalous child activity, and code paths that do not match the process’s normal role.
Useful controls include stronger application control, tighter process and module monitoring, memory inspection, and baselining of normal service behavior. Where available, combine endpoint telemetry with process lineage analysis and artifact-level inspection so a trusted process cannot hide malicious execution simply by inheriting a familiar name.
The NIST SP 800-53 Rev 5 Security and Privacy Controls is a strong control-catalog reference for process monitoring, auditability, and system integrity, and NIST Cybersecurity Framework 2.0 provides the broader governance structure for detect, respond, and recover activities. For organisations hardening trust boundaries around execution, NIST SP 800-207 Zero Trust Architecture reinforces the principle that a running process should not be trusted simply because it already exists.
Risk and Threat Considerations
Code hidden inside an existing process can bypass naive monitoring, preserve access longer, and make containment harder because responders may initially trust the host process. The technique becomes especially dangerous when it is used inside privileged services, security tooling, or long-lived enterprise applications.
Failure mechanism: The attacker gains execution inside a process that already carries legitimacy, privileges, or monitoring exemptions, which reduces visibility and can let malicious activity blend into normal operations.
Impact: Organizations can miss active compromise, misattribute malicious behavior to trusted software, and lose time during containment while the attacker expands access or exfiltrates data.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1055 — Process Injection | Covers malicious code running inside another process to evade detection. |
| Recommendation — Map injected execution to T1055 and hunt for process hollowing, remote threads, and memory tampering. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Supports monitoring runtime process behavior and suspicious code activity. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Supports reviewing telemetry needed to spot hidden execution inside trusted processes. | |
| SI-7 — Software, Firmware, and Information Integrity | Addresses integrity of running code and detection of unauthorized modification. | |
| Recommendation — Tune SI-4 to alert on abnormal module loads, remote thread creation, and process tampering. Correlate audit data with process baselines to identify injected or disguised code execution. Apply SI-7 to detect unauthorized code changes inside trusted processes and services. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for anomalies and events | Directly aligns to detecting abnormal process activity and hidden execution. |
| Recommendation — Monitor process behavior continuously and alert on deviations from the established baseline. | ||
Practitioner Guidance
What to watch for: Treat unexpected process behavior as an investigation trigger, especially when a stable process suddenly loads unfamiliar modules, creates remote threads, changes memory protections, or communicates in ways that do not fit its baseline role.
Practitioner takeaway: The key control is not just blocking suspicious executables, it is proving that trusted processes are still behaving like the software you expect.
Related resources from NHI Mgmt Group
- How do you know if your code analysis process is actually working?
- Who is accountable when a build process loads malicious code and exposes credentials?
- Who is accountable when schema-driven code generation exposes process credentials?
- How should security teams reduce remote code execution risk in publicly exposed analytics platforms that process user-uploaded reports?