Attackers replace binaries by swapping a legitimate executable or library with a malicious one so the system launches the attacker’s code instead of the trusted file. This can persist across reboots and bypass weak trust assumptions. Defenders should protect write access to system directories, verify file integrity, and alert on unexpected changes to signed or privileged binaries.
How binary replacement becomes code execution
replace binaries works because the operating system trusts a file path, name, or service reference more than it verifies the file’s contents at launch time. If an attacker can overwrite a trusted executable, shared library, or helper component, the system will start the attacker’s version in the same execution path as the legitimate one.
That makes the technique especially useful where software runs at startup, as a service, or with elevated privileges. A small file swap can turn ordinary execution into reliable code launch, and if the replaced file is restored only rarely, the malicious version can survive reboots and routine user logons.
Attackers usually need some form of write access to a location the system will later load from, such as a program directory, a library search path, or a privileged service location. They often prefer a target that is noisy enough to blend in, but stable enough to be invoked repeatedly without further interaction.
What makes replace binaries effective for persistence and stealth?
The value of this technique is not just execution, it is trusted execution. A replaced binary can inherit the permissions, startup timing, and operational role of the original file, which lets malicious code appear normal to users and sometimes to weak monitoring tools.
It is also attractive when defenders rely on file names or allowlists without checking file integrity. If the security model assumes “known filename equals trusted code,” the attacker only has to preserve the name and location while changing the payload underneath.
On Windows and Unix-like systems alike, the same general pattern appears in different forms: service executables, DLL search order abuse, startup scripts, scheduled task targets, and other launch points where an application loads something it expects to be benign. The mechanism changes, but the core weakness is the same, a trusted launch path without strong integrity enforcement.
Internal persistence and execution patterns are often discussed together with broader Persistence Techniques Guide, because binary replacement is usually one option inside a larger post-compromise playbook.
How defenders should validate and contain it
The first question is whether the attacker could still write to the target location. If the answer is yes, the problem is bigger than a single file, because any trusted binary in that path may be replaceable until permissions, ownership, or service configuration are corrected.
Good detection focuses on changes that should almost never happen: unsigned replacements, file hash drift, unexpected modification timestamps, and new executables or libraries in privileged directories. Alerting should be tuned around sensitive launch points, not just around generic file creation.
When the integrity of the original binary matters, reinstallation alone is not enough if the attacker still has the same write path. The better fix is to close the write path, restore the trusted file from a clean source, and confirm that the replacement did not also alter neighboring scripts, service definitions, or load-order dependencies.
Attackers who use file replacement frequently rely on persistence and repeated launch opportunities, so compromise review should include startup locations, service wrappers, and any component that automatically loads code from disk before or during authentication. That is where the hidden execution path usually lives.
Risk and Threat Considerations
Replace binaries is risky because it turns a normal software trust relationship into an execution channel for an attacker. The same weakness can also be used to keep access after a reboot, replace defensive tooling, or redirect a privileged service into hostile code.
Failure mechanism: The attacker gains write access to a trusted executable or library path, swaps in malicious code, and waits for the operating system or a service to launch it under trusted conditions.
Impact: The result can be persistence, stealthy code execution, privilege abuse, and delayed detection, especially when defenders rely on filenames or signatures without continuous integrity checks.
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1574 — Hijack Execution Flow | Binary replacement is an execution-flow hijack technique. |
| Recommendation — Map file swap paths to execution-hijack telemetry and hunt for unexpected replacement of trusted binaries. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Privileged file paths and launch points need hardened configuration and integrity control. |
| Recommendation — Harden writable software paths and verify privileged files against approved baselines. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | File replacement is directly addressed by integrity checking and tamper detection. |
| CM-5 — Access Restrictions for Change | Attackers succeed when they can modify protected binaries or directories. | |
| Recommendation — Enforce integrity monitoring on trusted executables and alert on unauthorized changes. Restrict who can modify system binaries, libraries, and service launch files. | ||
Practitioner Guidance
What to verify: Confirm which binaries, libraries, and service targets are writable by non-admin principals, and treat any such path as a candidate for abuse. A trusted binary that can be modified is not a hard control, it is an exploitable dependency.
Common mistake: Teams often check only the replaced file itself and miss the surrounding launch chain, service configuration, path precedence, scheduled execution, or sibling files that can recreate the same compromise after cleanup.
Practitioner takeaway: If an attacker can change what a trusted process loads, they can often control when and how code runs, so the real control objective is to remove write access and prove integrity continuously, not just to restore a single file.