LC_MAIN Hijacking is a macOS process injection technique that alters a Mach-O binary’s LC_MAIN entry point so attacker-controlled code runs when the program starts. It can bypass normal execution flow and hide payload launch. Defenders watch for binary tampering, unsigned changes, and unexpected launch behaviour.
How LC_MAIN hijacking works
LC_MAIN hijacking targets the launch path of a macOS Mach-O binary by changing the LC_MAIN load command so attacker-controlled code executes when the program starts. Because the modification sits in the binary itself, execution can look like a normal app launch rather than an obvious drop-and-run event.
The technique matters because startup is a trusted moment in the process lifecycle. If an adversary can alter what runs first, they can redirect control before the application’s own logic, user interface, or security checks meaningfully begin.
Why it is dangerous on macOS
Binary tampering at launch time is especially useful for stealth, persistence, and execution control. The altered entry path can hide the original launch sequence, make code execution look legitimate, and reduce the chance that simple process-based monitoring spots the initial compromise.
The danger is not only that malicious code runs, but that it runs inside a trusted application context. That can make downstream activity blend in with normal application behaviour, complicating incident triage and attribution.
How defenders look for LC_MAIN hijacking
Defence focuses on integrity and launch behaviour. Watch for unexpected changes to signed or notarised binaries, altered file hashes, modified Mach-O load commands, and execution patterns that do not match the known application start flow.
Review the surrounding system context as well. Unexpected parent-child process relationships, fresh binaries appearing in application directories, and unsigned or newly modified executables are all signals that the launch path may have been manipulated rather than merely abused at runtime.
What good response and hardening look like
Teams should treat this as a binary integrity problem first and a process problem second. Preserve the suspicious binary, compare it against a trusted copy, and validate whether the LC_MAIN structure or other load commands were changed before the incident was contained.
Preventive hardening is strongest when file integrity, code-signing validation, application allowlisting, and tight control over software distribution all work together. The fewer places an attacker can write to a launchable binary, the less room they have to turn startup control into execution control.
Risk and Threat Considerations
LC_MAIN hijacking is dangerous because it turns a trusted startup mechanism into a stealthy execution path. The result can be persistent code execution that looks like ordinary application launch activity, which makes early detection harder and increases the chance of follow-on compromise.
Failure mechanism: An attacker modifies the Mach-O entry-point metadata so their code runs before the intended program logic, bypassing normal execution flow and hiding the payload launch inside a legitimate binary.
Impact: The compromise can lead to persistence, deceptive execution, and broader trust abuse, especially when defenders rely on process names or expected launch behaviour instead of binary integrity.
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 | T1055 — Process Injection | LC_MAIN hijacking alters program launch to run attacker code inside a process. |
| Recommendation — Map modified launch behaviour to process-injection detections and hunt for tampered binaries. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Defenders must know which macOS binaries are approved and monitor for tampering. |
| CIS-10 — Malware Defenses | Runtime tampering and hidden payload launch fit malware-prevention and detection controls. | |
| Recommendation — Inventory trusted executables and alert on unexpected changes to launchable software. Use malware-defence telemetry to flag unsigned or altered binaries at execution time. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Launch-path integrity and code tampering are software integrity concerns relevant to secure architecture. |
| Recommendation — Design builds and release checks to reject altered binaries before deployment. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | The attack changes executable integrity and launch behaviour, which SI-7 addresses directly. |
| Recommendation — Validate executable integrity and detect unauthorized changes to application binaries. | ||
Practitioner Guidance
What to watch for: Treat unexpected launch behaviour as an integrity signal, not just an application bug. A binary that starts differently from its known-good baseline, especially after a recent file change, deserves immediate comparison against a trusted copy.
Governance implication: Make executable integrity, signing verification, and software provenance part of release and incident workflows. If a launchable binary can be altered without control, startup trust becomes an attack surface rather than a control.