Prevent binary replacement with strong file permissions, integrity checking, signed code enforcement, and protected update mechanisms. Detect unexpected changes to executables, libraries, and scheduled tasks, especially in paths writable by standard users or service accounts. If an attacker can swap a binary, they can often inherit its trust and execution path.
How do you stop attackers from swapping a binary?
The core defence is to make the executable path hard to tamper with and easy to verify. That means locking down file ownership and write access, enforcing code signing, and making update paths trustworthy. If a binary can be replaced, the attacker often gets the original trust relationship, not just a new file.
File permissions matter most where standard users, service accounts, or automation can write into paths that later execute code. The same applies to libraries and helper components, because binary replacement often succeeds through adjacent files rather than the main executable alone. A protected path without protected dependencies still leaves a practical replacement route.
Signed code enforcement and integrity checking reduce the chance that an altered binary is silently accepted. That includes verifying executables at load time, watching for unexpected hash changes, and treating unsigned or newly signed replacements as suspicious until they are validated against the release process. Protected update mechanisms are equally important, because a weak updater can become the easiest way to distribute a malicious replacement at scale.
Where binary replacement usually succeeds
Replacement attempts usually target locations that already have execution value, such as application directories, scheduled task targets, service binaries, startup locations, or shared libraries loaded by trusted processes. The attacker does not need to own the whole system if they can modify just one file that is later executed with elevated or trusted context.
Paths that look operationally ordinary are often the highest risk. Shared folders, writable deployment directories, permissive service accounts, and weakly protected task definitions can all create the conditions for a swap. Monitoring should therefore cover not only the main executable, but also the components that determine what runs next, when it runs, and under which account.
Defenders should also remember that binary replacement is often part of a persistence chain, not a one-off event. A swapped binary can preserve attacker access across reboots, maintenance windows, and normal admin activity, especially when the replacement blends into expected software behaviour.
What good detection and hardening look like
Good hardening starts with shrinking write access to executables, libraries, service definitions, and scheduled task targets to only the systems and principals that truly need it. It then adds a verification layer so that an unexpected change produces a security signal before the modified binary is trusted in production.
On the detection side, the most useful signals are change events that affect executable content, startup mechanisms, and trust-bearing paths. A file modification alone may be benign, but a modification followed by execution from a privileged or long-lived trust path deserves immediate review. The key question is not only whether the file changed, but whether the change alters what the environment will execute next.
Update integrity deserves special attention because many organisations trust signed or centrally delivered software more than local binaries. If the update channel is not protected, an attacker may not need to defeat endpoint controls at all, only the mechanism that is supposed to deliver safe code.
Risk and Threat Considerations
Binary replacement is attractive because it turns a trusted execution path into a delivery mechanism for malicious code. When the file, library, or task target is writable by a lower-privilege principal, the attacker can often preserve the expected process name, location, and launch behaviour while changing the underlying content.
Failure mechanism: Weak permissions, unsafe update paths, or unmonitored changes let an attacker overwrite a trusted binary or its supporting component, then execute the replacement through a legitimate service, task, or user workflow.
Impact: The attacker may gain persistence, privilege escalation, or stealthy execution under a trusted identity path, and the modified binary can keep working until integrity or behaviour monitoring catches the change.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1036 — Masquerading | Binary replacement relies on trusted execution paths being altered to run malicious code. |
| Recommendation — Map suspicious file swaps to T1036 and hunt for altered trusted binaries and launch paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | Writable execution paths often stem from excessive account and service permissions. |
| Recommendation — Tighten account and service write access to executable and update paths. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Integrity controls directly address unauthorized binary changes and trust in software content. |
| CM-5 — Access Restrictions for Change | Restricting who can change executables and service definitions reduces replacement opportunities. | |
| Recommendation — Apply SI-7 to verify software integrity before execution and after updates. Restrict modification rights on executables, libraries, and scheduled task definitions. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Protected deployment and update mechanisms are a control pattern for preventing unauthorized replacement. |
| Recommendation — Harden deployment paths so only trusted pipelines can replace production binaries. | ||
Practitioner Guidance
What to verify: Confirm which principals can write to executable directories, service binaries, scheduled task targets, startup locations, and library search paths. If a standard user or service account can modify something that later runs with more trust, treat it as an actionable exposure.
Decision rule: If you cannot prevent a path from being writable, compensate with integrity monitoring, signed code validation, and tighter control over how updates are published and approved. If the path is both writable and executable, prioritise remediation there before expanding hunting elsewhere.
Common mistake: Teams often watch for malware in the main executable but ignore the supporting files, update mechanism, and task or service definition that make replacement possible in the first place.
Practitioner takeaway: The most reliable control is to make replacement both difficult and visible, because once an attacker can swap a trusted binary, they can usually inherit the trust already attached to it.
Related resources from NHI Mgmt Group
- Guide: Persistence Techniques Guide
- How should teams reduce the risk of exposed AI credentials being abused?
- How should teams reduce risk from malicious npm package installs?
- What mitigations reduce the risk of replacing file extension handlers?
- What mitigations reduce the risk of replacing a trusted executable?