Attackers use Compile After Delivery to compile source code on the target system after they have delivered it. That helps evade simple file-based detection and can delay analysis until the code is built. Defenders should inspect build tools on endpoints, unexpected compiler activity, and scripts that fetch or generate source before compilation.
What Compile After Delivery changes in the attack path
compile after delivery shifts malicious code execution from the delivery stage to the target environment. That matters because static inspection of the dropped file may reveal little until the payload is built, and the compilation step can blend into normal developer or build activity. The technique is especially useful when the attacker wants the delivered source to look harmless until runtime artifacts appear on the endpoint.
For defenders, the key analytical question is not just “what was delivered?” but “what tooling touched it, what generated it, and what ran immediately before compilation?” That often means correlating file creation, source retrieval, compiler invocation, and post-build execution rather than relying on a one-time scan of the original artifact.
For broader context on malware delivery and evasion patterns, Malware Guide covers common malware behaviors, including compile after delivery and other techniques that delay detection.
Why defenders should treat compilation as a security event
Compile After Delivery is not dangerous because compilation itself is suspicious in every environment, it is dangerous because it can transform source into an executable only after the payload reaches a trusted endpoint. That gives attackers a way to hide intent from simple file reputation checks, AV signatures aimed at known binaries, and pre-execution analysis that never sees the final artifact. It also creates a window where scripts can fetch dependencies, alter the source, or inject environment-specific logic before build time.
Endpoint builds become higher risk when the system is not supposed to compile code, when the compiler is unusual for the user or host role, or when the source arrives from an untrusted location such as a script, archive, or remote fetch. Those are the moments when compilation is part of the kill chain, not just part of normal operations.
Real-world breach patterns around payload delivery, secret abuse, and post-delivery execution are well captured in The State of NHI & AI Agent Breach Report 2026, which shows how attackers often combine delivery with delayed execution paths.
What to inspect on endpoints and build hosts
Look for compiler activity that does not match the system’s usual role, especially compilers launched from scripts, temp directories, downloads, or user-writable paths. Also inspect command lines, parent-child process chains, and any evidence that source was staged immediately before build time. If a host compiles code after receiving a file from email, chat, browser download, or automation script, the compilation step itself is part of the investigation.
- Check for build tools installed where they are not normally needed.
- Review recent source fetches, generated scripts, and temporary build directories.
- Correlate compiler execution with outbound connections, persistence changes, and follow-on process launches.
- Preserve source, build logs, and output artifacts for triage before cleanup alters evidence.
Risk and Threat Considerations
Compile After Delivery increases the chance that malicious code will bypass controls designed around pre-built binaries. It also raises the odds that defenders will miss the first stage of compromise, because the delivered source may appear inert until the local build step creates the operational payload.
Failure mechanism: The attacker relies on the target to perform the final transformation from source into executable, which can sidestep file-based detection and delay static analysis until after the payload has already been built and possibly executed.
Impact: Security teams may lose visibility into the real artifact, the build-time dependencies, and any malicious changes introduced during compilation, which can slow containment and widen the blast radius if the built output is reused elsewhere.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1027 — Obfuscated Files or Information | Compile-after-delivery helps hide malicious code until build time. |
| T1106 — Native API | Compiled payloads often execute locally after the build step completes. | |
| Recommendation — Hunt for delayed build chains and inspect source that only becomes executable after compilation. Correlate compilation with immediate local execution and post-build process launches. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | The technique evades simple file-based detection and requires malware-oriented monitoring. |
| CIS-8 — Audit Log Management | Investigating compile-after-delivery depends on reconstructing build activity from logs. | |
| Recommendation — Monitor build artifacts, compiler launches, and suspicious source-generation activity on endpoints. Retain process, command-line, and build logs needed to reconstruct compilation events. | ||
Practitioner Guidance
What to verify: Confirm whether compilation is expected on that host at all. If it is, verify the parent process, source origin, compiler path, and output destination before treating the activity as routine.
Decision rule: If a delivered source file is followed by an unexpected compiler invocation, treat the build chain as suspicious even if the original source looked harmless. Prioritise triage of the build artifacts and command history over the dropped file alone.
What good looks like: Build activity is tied to approved tooling, approved directories, and approved users or service accounts, with logs that let you reconstruct exactly what was compiled and why.
Practitioner takeaway: The security boundary is the build step, not just the delivered file, so response should focus on provenance, execution context, and the resulting artifact.