Replace Binaries is the replacement of a legitimate executable or script with a malicious one, or the substitution of one trusted binary for another. Attackers use it to hijack execution paths and persist through updates or user launches. Defenders should protect file integrity, constrain write permissions, and verify hashes for critical binaries.
How Replace Binaries Works
Replace Binaries is an execution-path abuse pattern, not just file tampering. The attacker’s goal is to put a malicious executable or script where a trusted one is expected, so normal launches, update workflows, or administrative actions execute the attacker’s code instead.
This works because many systems trust the file path, name, or location of a binary more than the contents behind it. If an attacker can write to that location, they can redirect execution without needing to change the surrounding application logic. The technique is closely related to binary replacement, file substitution, and execution-path hijacking.
Why It Is Dangerous
Replacing a binary is effective because it turns an ordinary trust relationship into an execution primitive. A user, service, scheduled task, or updater may continue to invoke the same path while silently running attacker-controlled code.
The danger is not limited to one-time compromise. If the replaced binary is launched repeatedly, the malicious code can persist, reestablish access after reboot, and survive routine use until the tampered file is discovered and restored. That makes the technique attractive for stealthy footholds and long-lived intrusion.
Common Execution Paths and Abuse Conditions
Attackers usually need two ingredients: a writable location and a trusted execution event. That can be a directory with weak permissions, a shared application path, a startup location, or a maintenance process that runs binaries on a schedule.
The abuse becomes more reliable when defenders assume the name of the executable is enough. In practice, integrity matters more than identity of filename, so a benign-looking path can still be dangerous if the file behind it has changed. The concept often overlaps with trusted binary hijacking, path interception, and other persistence techniques described in Persistence Techniques Guide.
Defensive Meaning of Integrity and Verification
Defending against binary replacement depends on making trusted files hard to alter and easy to verify. File integrity monitoring, restrictive write permissions, and strong change control all reduce the chance that a legitimate executable can be swapped without detection.
Hash verification is especially important for critical binaries because it provides a content check, not just a path check. If the file changes unexpectedly, defenders should treat that as a sign of tampering and review whether the altered binary was executed, how it was introduced, and whether related persistence or loader changes were also made. NIST guidance on system integrity and configuration control is covered in NIST SP 800-53 Rev 5 Security and Privacy Controls, while NIST Cybersecurity Framework 2.0 frames the broader protect, detect, and recover lifecycle around integrity loss.
Risk and Threat Considerations
Binary replacement is dangerous because it lets an attacker inherit trust from a legitimate execution path. Once a trusted binary is swapped, the malicious version can blend into ordinary operations, evade casual inspection, and survive as long as the surrounding process continues to invoke it.
Failure mechanism: The defender trusts the file name or location, but not the file contents or ownership history, so a writable path becomes a launch point for malicious code.
Impact: The attacker can gain persistence, execute under the privileges of the launching process, and potentially maintain access even after partial cleanup if the altered binary is not discovered and restored.
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 |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Binary replacement directly concerns integrity validation for trusted executables. |
| CM-5 — Access Restrictions for Change | Preventing unauthorized modification of executable files depends on restricting who can change them. | |
| CM-6 — Configuration Settings | Baseline configuration helps preserve trusted file locations, permissions, and executable integrity. | |
| Recommendation — Use SI-7 to verify critical binaries and alert on unexpected file changes. Use CM-5 to restrict who can modify trusted binaries and scripts. Use CM-6 to enforce hardened file and permission settings for executable paths. | ||
| NIST CSF 2.0 | PR.DS-06 — Data is protected from unauthorized access, disclosure, modification, and deletion | Trusted binaries are integrity-sensitive assets that must not be modified without authorization. |
| Recommendation — Protect executable files from unauthorized modification and replacement. | ||
| MITRE ATT&CK | T1574 — Hijack Execution Flow | Replacing a binary is a direct execution-flow hijacking technique. |
| Recommendation — Map binary replacement activity to T1574 and hunt for compromised execution paths. | ||
Practitioner Guidance
What to watch for: Prioritise critical binaries, service executables, scripts, and update targets that sit in writable directories or are launched automatically. Unexpected timestamp changes, permission drift, hash mismatches, and unsigned replacements deserve immediate review.
Practitioner takeaway: Treat binary integrity as an access-control problem as much as a malware problem, because the main failure is often unauthorised write access to a trusted execution path.