Compile After Delivery is a code execution technique where source code is delivered first and compiled on the target system later. Attackers use it to delay detection and avoid static inspection of a finished binary, so defenders should monitor build tools, temporary source files, and unexpected compilation activity on endpoints.
What Compile After Delivery Means in Practice
Compile After Delivery is a code execution technique in which source code is delivered first and compiled later on the target system. That timing gap matters because it can delay detection, complicate sandboxing, and let malicious code avoid static inspection as a finished binary.
The technique is not just about compilation as a build step, it is about shifting execution into a later and often less-visible moment. Defenders should treat any endpoint or build environment that can compile untrusted input as a potential execution surface, especially when source files arrive from outside normal software delivery channels.
Why Attackers Use This Technique
Compile After Delivery helps an attacker separate delivery from execution. If defenders only inspect binaries, they may miss the malicious intent until the code is compiled locally, at which point the resulting artifact can look fresh, environment-specific, or short-lived.
This technique is often paired with obfuscation, temporary source placement, or unusual use of developer tools. For a broader view of malware tradecraft and evasion patterns, see Malware Guide, which covers loaders, evasion techniques, and compile after delivery among other malware behaviours.
Where Organisations Become Exposed
Exposure usually appears wherever build tools, compilers, interpreters, or developer utilities are present on endpoints that are not supposed to compile code. It also appears when temporary source files, staging directories, or user-writable locations can be turned into execution paths without strong review or monitoring.
The practical question is whether your inventory can distinguish approved development systems from ordinary user devices, jump hosts, or servers that should never perform local compilation. Build telemetry, file creation events, and process lineage become important because the malicious action is often normal compilation machinery used in an abnormal place. In that sense, the technique overlaps with supply-chain and build-integrity concerns discussed in SLSA, which focuses on provenance and trustworthy software build paths.
Detection and Response After Compilation
Detection should focus on the full chain, not only the final executable. Watch for source files arriving shortly before compiler invocations, compilation in unusual directories, unexpected child processes from build tools, and binaries that appear only briefly before execution or deletion.
When compile-after-delivery activity is suspected, responders should review recent source artifacts, command histories, temporary files, and endpoint process trees to determine whether local compilation produced a weaponised payload. Endpoint telemetry is especially valuable because this technique may evade classic static scanning until after compilation. Defensive monitoring and logging guidance from NIST Cybersecurity Framework 2.0 and system integrity controls in NIST SP 800-53 Rev 5 Security and Privacy Controls are both relevant when you need to verify what ran, where, and under whose control.
Risk and Threat Considerations
Compile After Delivery creates risk because it shifts malicious logic into a later stage that many defensive tools treat as ordinary development activity. That makes it useful for evasion, persistence on developer workstations, and abuse of trusted build utilities.
Failure mechanism: The attacker delivers source code or source-like material first, then uses local compilation to generate an executable after the initial inspection window has passed. Static controls that depend on file reputation or binary scanning can miss the threat until the code is already active.
Impact: Organisations can end up with endpoint compromise, hidden execution, and poor attribution of where the malicious artifact came from, especially if build artifacts are temporary and compilation occurs outside approved development workflows.
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 SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Compile-after-delivery often uses scripting or local execution to turn delivered code into running payloads. |
| Recommendation — Correlate unusual compiler or script execution with endpoint telemetry to identify post-delivery code execution. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Compilation on endpoints is best detected through process and file telemetry retained in logs. |
| CIS-10 — Malware Defenses | This technique is a malware evasion pattern that benefits from layered anti-malware and behavior detection. | |
| Recommendation — Retain endpoint process and file logs so unexpected compilation activity can be investigated quickly. Use behavior-based malware defenses to flag suspicious source delivery and local compilation patterns. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | The technique depends on observable events such as source file creation and compiler execution. |
| SI-4 — System Monitoring | System monitoring is needed to spot unauthorized build activity and post-delivery execution chains. | |
| Recommendation — Log compiler launches, source-file creation, and related process activity on endpoints. Monitor endpoints for unexpected compilation, staging, and execution patterns. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Compile-after-delivery is an artifact integrity and provenance concern in software build paths. |
| Recommendation — Verify artifact provenance so locally compiled payloads cannot silently enter trusted software paths. | ||
Practitioner Guidance
What to watch for: Treat compilation on non-development systems as a high-signal event. In practice, the strongest indicators are source drops, temporary file creation, and compiler or build-tool processes that appear on hosts with no business reason to compile code.
Practitioner takeaway: The control objective is not to ban compilers everywhere, it is to make unexpected compilation visible, attributable, and reviewable before the resulting code can run.
Related resources from NHI Mgmt Group
- What breaks when Teams messages are only scanned after delivery?
- How should security teams protect F5 configuration so application delivery can recover quickly after a change error or attack?
- Who is accountable when a campaign is only visible after endpoint execution rather than at message delivery?
- Why do verified emails still end up in spam or disappear after an ESP reports delivery?