Detect it by monitoring applications that fetch executable code, scripts or libraries after installation or launch. Look for network requests followed by code loading, reflective loading, scripting engine use, unsigned or unexpected modules and changes in behaviour after retrieval. Restrict where code may be downloaded from, and alert on applications that pull content from unapproved domains or storage locations.
How runtime code downloading shows up in practice
Download new code at runtime is a behaviour pattern, not a product feature. The key signal is that an application reaches out for executable content after it has already started or been installed, then loads that content into memory or a scripting engine. Security teams should treat the download event and the subsequent code execution as a single chain, because either step alone may look benign.
The most useful detections combine network telemetry with process and module visibility. A request to a new domain, object store or paste-like hosting location becomes more interesting when it is followed by library loading, reflective loading, script evaluation, packer-like unpacking or a new child process that did not appear in the baseline. That pattern is especially valuable when the code is unsigned, newly seen, or loaded from an unexpected path.
In containerised and cloud-native environments, the same pattern can appear as a workload fetching extra components at startup, then executing them inside the runtime boundary. That is why runtime inspection matters as much as network inspection. NIST’s SP 800-190 Container Security is a useful reference for thinking about image, registry and runtime risk as one control surface rather than three separate problems.
What to monitor and what to baseline
Detection is strongest when teams baseline the application’s normal update pattern, its usual domains, and the types of modules or scripts it legitimately loads. Without that baseline, legitimate feature delivery can look identical to malicious staging. The practical goal is to distinguish expected update channels from opportunistic retrieval of new executable code.
Watch for behaviours that create a high-confidence sequence: an outbound request, a successful fetch, then immediate code materialisation in memory, a scripting runtime, or a newly loaded module. Also watch for obfuscation around the fetch path, such as encoded URLs, temporary files, renamed DLLs, in-memory assemblies, or execution from writable user locations. These are strong indicators because they reduce transparency and often accompany evasion.
Teams should also log the provenance of what was downloaded, not just that something was downloaded. If a package, script, or shared object appears from a domain, bucket, or repository the application has never used before, the risk rises sharply. The same is true when the retrieved content is not consistent with the software’s declared update mechanism, such as a browser process loading a script engine module from an analytics endpoint.
Control points that reduce exposure
Detection works better when the environment makes runtime code retrieval harder in the first place. Constrain where applications may download executable content, and prefer allow-listed repositories, package sources and signed update channels. If a program must retrieve code dynamically, make that source predictable, authenticated and auditable rather than open-ended.
Integrity controls matter because runtime download behaviour often turns trust in the network into trust in the code itself. Code signing, package verification, module allow-listing and application control can reduce the chance that a fetched object becomes executable simply because it arrived from an allowed path. The most resilient setups treat unsigned or unverified code as suspect even when the network request succeeded normally. NHIMG’s Code Signing Security Guide is a useful companion for teams that need to connect retrieval detection with code integrity decisions.
For teams already using security automation, route these events into a triage workflow that preserves context. A download event by itself may be low priority, but download plus immediate module load, download plus reflection, or download plus a new high-privilege process deserves faster review. If the application is business-critical, alerting should distinguish between expected self-updates and unsanctioned retrieval of code from external infrastructure. NHIMG’s SOAR and Security Automation Guide helps structure that kind of event-driven response.
Risk and Threat Considerations
Runtime code downloading increases the attack surface because it lets trust decisions happen after launch, often outside normal build and release controls. That creates room for malicious payload delivery, dependency poisoning, covert feature activation and staged intrusion activity that may never appear in the original installation package.
Failure mechanism: An attacker compromises a retrieval path, abuses an untrusted domain, or exploits a legitimate application update mechanism so that fetched content is accepted as executable code. The dangerous part is not just the download, but the transition from downloaded object to trusted runtime behaviour.
Impact: Successful abuse can produce remote code execution, persistence, lateral movement, unauthorized data access or hidden functionality changes. It can also blur the boundary between software maintenance and active compromise, which makes detection and forensics harder.
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 OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Runtime code download detection depends on monitoring network and execution events. |
| CM-7 — Least Functionality | Restricting executable downloads reduces the attack surface for runtime code retrieval. | |
| SA-10 — Developer Configuration Management | Trusted update and module sources need controlled provenance to prevent tampering. | |
| Recommendation — Correlate fetch-and-execute telemetry and alert on unexpected runtime code loading. Limit applications to approved code sources and disable unnecessary dynamic loading paths. Verify update channels and enforce approved software source controls. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Applications should avoid unsafe dynamic loading and unbounded runtime extensibility. |
| Recommendation — Design runtime extension points to require explicit trust and integrity checks. | ||
| MITRE ATT&CK | T1105 — Ingress Tool Transfer | Fetching executable content at runtime matches the attacker pattern of bringing in code after initial access. |
| Recommendation — Map download-and-execute telemetry to T1105 and hunt for follow-on execution. | ||
Practitioner Guidance
What to verify: Confirm that your telemetry can correlate network fetches with immediate code loading, not just one or the other. If you cannot tie those events together, your detections will miss the most important part of the technique.
What to prioritise: Start with applications that can execute downloaded content, such as browsers, updaters, automation tools, script hosts and agent-style runtimes. They are the most likely to combine legitimate retrieval with malicious abuse.
Decision rule: If the retrieved code comes from an unapproved source, treat it as a potential compromise of execution trust, even when the application owner says the behaviour is “expected.” If the source is approved but the loading pattern is unusual, investigate for abuse of a legitimate channel.
Practitioner takeaway: The best detections focus on the handoff from retrieval to execution, because that is where benign download activity becomes a security event.