Attackers use Download New Code at Runtime to fetch additional malicious code after the app or process has started, which lets them change behaviour and evade static inspection. This can enable modular payloads, updated commands, or targeted abuse. Defenders should inspect runtime network fetches, restrict code-loading sources, and monitor for execution of newly delivered content.
Why Download New Code at Runtime Helps Attackers
Attackers use this technique to separate the initial foothold from the final payload. The first stage only needs to survive long enough to make a network request, then it can pull down code that matches the target environment, timing, or defender response. That makes the behaviour more flexible than shipping all malicious logic in one static binary or script.
This pattern is especially useful when the attacker wants to keep the initial sample small, avoid a fixed signature, or change functionality after launch. The same loader can fetch different modules for reconnaissance, credential theft, persistence, or follow-on execution, depending on what the compromised host exposes at runtime.
A practical implication is that the malicious behaviour may not be fully visible in the original file, so static review alone is often incomplete. Defenders need to inspect what the process retrieves after launch, which sources it trusts, and whether the fetched content is later executed, imported, or interpreted as code.
How the Runtime Fetch Changes the Attack Path
Runtime download shifts the attack path from a single dropper to a modular delivery chain. The initial process can act as a loader, an updater, or a staged launcher, while the downloaded code carries the higher-risk behaviour. That separation helps attackers iterate quickly, swap components, and keep the early-stage artefact relatively generic.
It also lets attackers adapt to environment checks. If the target has stronger monitoring, the loader can retrieve a quieter payload; if it has valuable access, the loader can pull a more aggressive module. This makes the technique attractive for campaigns that rely on conditional execution, region-specific content, or targeted abuse of a known host.
In practice, the risk is not just malicious code delivery, but trust in the delivery channel itself. If the application or process is allowed to fetch executable content from a remote source, the attacker only needs to influence that fetch path once to change what runs on the system later.
What Defenders Should Watch for in the Fetch-and-Execute Pattern
Runtime download is easiest to spot when teams correlate network activity with process behaviour. A process that starts normally, contacts an unusual host, retrieves script or binary content, and then creates new execution activity is a strong indicator that code is being staged after launch. That pattern matters even when the original executable looks benign.
Defenders should also pay attention to the source of the download. Remote code retrieval from unsigned, user-writable, or otherwise untrusted locations is much riskier than fetching from controlled update infrastructure. If the process is meant to update itself, the update path should still be tightly bounded, observable, and resistant to tampering.
For teams that need a deeper reference on runtime exposure in application containers, NIST SP 800-190 Container Security is useful because it covers image, registry, orchestrator, and runtime risk. For adversary behaviour more broadly, MITRE ATT&CK Enterprise Matrix helps map the loader, delivery, and execution sequence into detection work.
Risk and Threat Considerations
Runtime code download increases exposure because it moves critical malicious logic outside the original artefact and into a live trust relationship. That can weaken static inspection, complicate sandboxing, and give attackers a way to alter payloads after the initial compromise without changing the first-stage file.
Failure mechanism: The attacker controls, influences, or impersonates the remote source that supplies the additional code, then relies on the target process to trust and execute the new content.
Impact: The compromise can expand from a limited foothold into modular execution, enabling new capabilities, rapid payload replacement, and follow-on abuse that is harder to detect from the original file alone.
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 CSF 2.0, 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 | T1105 — Ingress Tool Transfer | Runtime download is the transfer step attackers use to stage additional code. |
| Recommendation — Detect and restrict inbound code transfers that precede execution. | ||
| NIST CSF 2.0 | PR.DS-10 — Data-in-Transit is Protected | Remote code fetches depend on protecting content while it is transmitted. |
| Recommendation — Protect runtime downloads with authenticated, integrity-checked transport. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Loaded payloads are malware delivery and execution activity that malware defenses should catch. |
| Recommendation — Monitor for and block suspicious downloaded executables and scripts. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Runtime fetch-and-execute behaviour is best detected through monitoring of process and network activity. |
| Recommendation — Monitor process-network correlations to identify newly delivered code. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Applications that load code at runtime need architectural controls to bound that behaviour. |
| Recommendation — Design runtime loading so only trusted, bounded sources can supply executable content. | ||
Practitioner Guidance
What to verify: Confirm which processes are allowed to fetch executable content, which domains or endpoints they contact, and whether the retrieved material is ever executed, imported, or interpreted. If the answer is unclear, treat that path as a high-priority review item rather than a benign application update.
Decision rule: If the downloaded content can influence code execution, apply stricter control than you would for ordinary data retrieval. Restrict code-loading sources, require integrity checks where possible, and separate content delivery from execution authority so a remote fetch cannot silently become a runtime control channel.
Practitioner takeaway: The key question is not whether a program can download content, but whether that download can change what the program is allowed to run. When that is true, the fetch path becomes part of the attack surface and must be governed like an execution path.