Attackers use dylib hijacking on macOS by placing a malicious dynamic library where an application will load it instead of the intended one. This can give code execution when the app starts. Defenders should verify library search paths, sign and integrity-check applications, remove writable load locations, and look for unexpected library loads by trusted processes.
How dylib hijacking turns startup into execution
On macOS, dylib hijacking works because an application can be tricked into loading a library from an attacker-controlled location before it reaches the intended one. The useful security question is not just “can this happen?”, but “which loading path, signing assumption, or writable directory lets it happen at process start?”
The attacker’s goal is usually early, trusted execution. If the hijacked library is loaded during launch, the malicious code runs inside the context of the legitimate process, which can make it harder to distinguish from normal application behaviour and easier to inherit the app’s permissions, network reach, and user trust.
That is why this technique is often treated as a persistence and execution primitive rather than a standalone library issue. It abuses application loading behaviour, not a weakness in the library format itself, so defenders need to understand where the process resolves dependencies and whether the runtime search order can be influenced.
Where the abuse comes from in practice
Dylib hijacking becomes viable when an application searches for a library in a path the attacker can write to, or when the process accepts a library name without sufficiently constraining where that library must come from. If the attacker can place a matching file earlier in the lookup path, the application may load the hostile version without any obvious user interaction.
This usually matters most when the targeted application is trusted, launched often, or granted elevated reach into other systems or data. A single successful placement can convert a normal application start into repeated code execution, which is why search-path hygiene and directory permissions matter more than the filename alone.
For defenders, the practical check is whether the application’s dependency resolution is predictable and tightly controlled. If a writable location, inherited environment setting, or loose search rule influences what gets loaded, the attacker has a path to execution. The same logic also applies to other loading-abuse patterns, which is why the broader persistence pattern matters.
For a wider view of how attackers chain launch-time abuse with other persistence mechanisms, the Persistence Techniques Guide is a useful companion reference.
What defenders should verify before they trust an app launch
Trusting an application binary is not enough if its load-time dependencies are not controlled. Practitioners should verify the library search path, remove writable load locations, and check whether the application can be made to resolve a malicious library before the intended one. Code signing helps, but it must be paired with integrity checks and path control, because signed software can still be undermined by unsafe loading behaviour.
At detection time, the key signal is an unexpected library load by a trusted process. That is especially relevant when the loaded file lives in a user-writable or unusual directory, or when the load occurs during startup rather than after a normal feature call. Correlating process start, library path, and parent-child execution often gives the clearest picture.
When the question is how attackers use this technique, the most important defensive implication is that prevention and monitoring have to cover both sides of the abuse: the filesystem location that hosts the rogue library and the application logic that decides what to load. If either side stays loose, hijacking remains viable.
Risk and Threat Considerations
Dylib hijacking is risky because it converts a path-control problem into code execution inside a trusted process. That can bypass user expectations, weaken application trust, and give an attacker a foothold that is easier to miss than a separate dropped binary.
Failure mechanism: The application resolves a dynamic library from a location the attacker can influence, such as an unsafe search path or writable directory, and loads the hostile library instead of the intended one.
Impact: The attacker gains code execution in the context of the legitimate process, which can support persistence, local privilege abuse, credential exposure, or further lateral movement depending on the process’s reach.
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, OWASP ASVS 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.006 — Dynamic Linker Hijacking | Directly maps to library load-order abuse used in dylib hijacking. |
| Recommendation — Hunt for dynamic-linker hijacking indicators and validate dependency resolution paths. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Library search paths and writable load locations are configuration weaknesses. |
| Recommendation — Harden application loading paths and remove writable dependency locations. | ||
| OWASP ASVS | V13 — Configuration | Secure configuration of application runtime and dependency loading affects this abuse path. |
| Recommendation — Verify runtime configuration prevents attacker-influenced library loading. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Restricting unnecessary load paths reduces hijack opportunities. |
| SI-7 — Software, Firmware, and Information Integrity | Integrity checking and tamper detection help detect malicious replacement libraries. | |
| Recommendation — Restrict applications to only the libraries and paths they truly require. Apply integrity checks to detect unauthorized library replacement or tampering. | ||
Practitioner Guidance
What to verify: Confirm that every production app has deterministic library resolution, with no writable directory in the effective search path and no dependence on user-controlled path inheritance.
What good looks like: Trusted processes only load libraries from controlled, signed, and integrity-checked locations, and unexpected loads are visible in telemetry quickly enough to support containment before the process is reused for persistence.
Practitioner takeaway: Treat dylib hijacking as a launch-time trust problem, not just a malware placement problem, because the real control point is whether the app can be steered into loading attacker code at startup.