Detect LC_LOAD_DYLIB Addition by checking macOS binaries and related build artefacts for added dynamic library load commands that redirect execution to unauthorised code. Compare signed binaries against known-good baselines, review modified packages, and watch for unexpected library paths in newly installed or altered applications. Treat changes to load commands as potential tampering.
What LC_LOAD_DYLIB addition changes in a macOS binary
LC_LOAD_DYLIB is the Mach-O load command that tells the dynamic linker which libraries to load at runtime. When an attacker adds or rewrites that command, the binary can be made to load attacker-controlled code before or alongside the expected library set. Detection starts with knowing the expected load-command layout for the file family you trust.
A useful baseline is the binary as it was signed, packaged, or originally shipped. If the load-command list now includes a different library path, an unexpected relative path, or a dependency that points outside the normal application bundle or system location, treat that as a potential tamper signal. The question is not only whether the file runs, but whether its runtime dependency chain has been quietly redirected.
How to inspect binaries and packages for tampering
Compare the current Mach-O metadata against a known-good copy from the same build, vendor package, or release artefact. That comparison should include the load commands, the embedded library paths, code-signing state, and any package contents that may have been modified after installation. For a broader persistence and binary-tampering view, see the Persistence Techniques Guide, which covers shared-library injection and dylib hijacking patterns that often accompany this type of change.
Look for added libraries that point to writable locations such as user-writable directories, temporary paths, hidden subdirectories, or locations that do not match the product’s normal layout. Also inspect whether the modified binary is still correctly signed, because a changed load command often breaks the signature or forces a re-sign that itself may be suspicious. Package diffing matters here: an attacker may alter an app bundle, installer payload, or post-install artefact so the load command change persists across launches.
Use the file system and package boundary as part of the detection logic. If the application was installed from a signed vendor package, but the binary now references a library that was not present in that package or is not part of the approved application bundle, that mismatch is a strong indicator of compromise or unauthorized modification.
What to verify before you treat the change as malicious
Not every change to a load command is automatically hostile. Legitimate software updates, vendor rebuilds, and developer tooling can alter library references. The practical test is whether the change is expected for that specific build lineage and whether the new dependency is consistent with the product’s normal signing, packaging, and update process. If you cannot tie the change to an approved release, treat it as suspicious until proven otherwise.
When the system contains multiple copies of the same application, compare them to find the point where the change first appears. That helps separate a supply-chain issue from a local post-install tamper. If the altered binary is paired with new persistence artifacts, unusual parent-child process chains, or other signs of execution redirection, escalate the finding as likely active compromise rather than an isolated file anomaly.
Risk and Threat Considerations
Added load commands can convert a legitimate macOS binary into a loader for untrusted code, which creates both execution redirection risk and persistence risk. The main concern is that the file still looks like the trusted application, while its runtime behavior has been changed to pull in an attacker-controlled library.
Failure mechanism: An attacker or installer-level modification inserts an unexpected LC_LOAD_DYLIB entry, then places the referenced library where the binary can reach it at runtime, often in a path that bypasses normal trust expectations.
Impact: The application may launch malicious code under the trust and context of the original binary, which can lead to credential theft, surveillance, data access, or durable persistence that survives ordinary process monitoring.
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 surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1036 — Masquerading | Load-command tampering disguises modified binaries as trusted software. |
| Recommendation — Hunt for binaries whose load commands or library paths diverge from the trusted baseline. | ||
| NIST CSF 2.0 | DE.CM-08 — Vulnerability scans are performed | Binary and package comparison is a detection activity for unauthorized change. |
| Recommendation — Monitor application artefacts for unauthorized modification and dependency drift. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Verifying signed binaries and package artefacts directly supports integrity checking. |
| Recommendation — Validate file integrity and investigate unexpected changes to executable load commands. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Detecting altered application artefacts depends on knowing approved software baselines. |
| Recommendation — Maintain approved software baselines so altered binaries and packages stand out quickly. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Unexpected load-command changes are a configuration drift problem in software artefacts. |
| Recommendation — Control and review application configuration changes, including binary and package artefacts. | ||
Practitioner Guidance
What to verify: Confirm the load-command diff against a known-good baseline, then verify code signature status, bundle membership, and whether the new library path is writable or user-controlled. If the binary is signed but the dependency path is not expected for that release, treat that as a high-confidence anomaly.
Decision rule: If the modified binary is executing from an approved location but now loads a library from an unexpected path, prioritize containment and artefact preservation before allowing normal use to continue. If the change is confined to a development build or sanctioned hotfix, document the approval trail and the exact release lineage that explains it.
Practitioner takeaway: Detecting LC_LOAD_DYLIB addition is less about spotting a single bad path and more about proving that the binary’s runtime dependency chain still matches the trusted release you think you deployed.