How do attackers use LC_LOAD_DYLIB Addition?

How LC_LOAD_DYLIB Addition turns a macOS binary into an execution trap

LC_LOAD_DYLIB Addition is an attack path that changes the binary’s load instructions, not its visible user-facing behavior. The goal is to make a trusted macOS executable load an attacker-controlled dynamic library at startup, so the malicious code runs in the context of that program. That is why file integrity and load-path review matter as much as malware scanning.

On macOS, this technique is most effective when the attacker can modify a legitimate executable or place a library where the loader will find it. The visible application may still open normally, which means defenders have to inspect the binary metadata, not just the process name or icon. A clean-looking launch can still hide a hijacked execution path.

The technique sits in the same family of persistence and execution-hijacking patterns as DLL side loading and dynamic linker hijacking. A useful reference for the broader technique landscape is Persistence Techniques Guide, which helps teams recognise how attackers preserve execution through trusted software rather than introducing obviously new binaries.

Where defenders should look first

Start by checking whether the executable is signed, whether the signature still matches the on-disk file, and whether the binary has unexpected load commands. LC_LOAD_DYLIB entries that point to unusual paths, writable directories, or recently modified locations deserve immediate scrutiny. The important question is not just “does the app run?” but “what additional code does it pull in when it runs?”

Review the surrounding filesystem context as well. A modified executable in a trusted path, or a library dropped beside a popular application, can be enough to make the load succeed without further privilege abuse. If the path is outside the normal bundle structure or appears to rely on search-order behaviour, treat that as a strong indicator of tampering.

Because this is an execution-hijack technique, the attacker’s objective is often stealthy persistence or staged post-compromise execution. NHI Management Group’s The State of NHI & AI Agent Breach Report 2026 is broader than macOS malware, but it reinforces a practical point that applies here too: once an attacker can run code through a trusted identity or trusted process, the blast radius usually expands faster than teams expect.

How to contain the damage when patching is not enough

If you cannot immediately remove the modified binary, treat the host as potentially compromised and contain it before you rely on application logs. Preserve the original file, the altered file, and the surrounding library paths for analysis. Then look for follow-on activity such as new persistence items, unusual outbound connections, or additional binaries launched by the same parent process.

When the library path or binary can be restored safely, replace the file from a trusted source rather than “cleaning” it in place. That matters because this technique may survive superficial remediation if the altered load command or the malicious library remains available. If the affected application uses privileged helpers, also check whether the same tampering has been replicated into sibling components.

For deeper threat-hunting around how attackers turn trusted software into a launch point, CISA’s cyber threat advisories can help you correlate the local tampering with broader attacker tradecraft and campaign indicators.

Practitioner Guidance

What to verify: Verify the binary’s code signature, load commands, and on-disk library paths before trusting a macOS application after an alert. If the executable is in a privileged or widely trusted location, assume impact is higher even when the process behaves normally.

Decision rule: If the modified binary can load a library from a path an attacker can influence, treat it as active execution control, not a low-severity file change. Prioritise isolation and restore from a known-good source over cosmetic cleanup.

Practitioner takeaway: The main risk is not the added library itself, but the fact that a trusted program becomes an unwitting loader for attacker code, so integrity and path validation must drive the response.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?