Loading AttackTrace...
Loading AttackTrace...
LC LOAD DYLIB Addition (T1546.006) is a MITRE ATT&CK technique associated with Privilege Escalation, Persistence . Adversaries may establish persistence by executing malicious content triggered by the execution of tainted binaries.
LC_LOAD_DYLIB Addition (T1546.006) is a MITRE ATT&CK technique associated with Privilege Escalation, Persistence. Adversaries may establish persistence by executing malicious content triggered by the execution of tainted binaries.
Attackers use LC_LOAD_DYLIB Addition because it provides a reliable way to advance their objective within the Privilege Escalation, Persistence tactic, often with a favorable balance of impact versus detectability on macOS environments. Defenders should assess this behavior in the context of the affected platform and adjacent activity rather than treating it as a standalone indicator.
Adversaries may establish persistence by executing malicious content triggered by the execution of tainted binaries. Mach-O binaries have a series of headers that are used to perform certain operations when a binary is loaded. The LC_LOAD_DYLIB header in a Mach-O binary tells macOS and OS X which dynamic libraries (dylibs) to load during execution time. These can be added ad-hoc to the compiled binary as long as adjustments are made to the rest of the fields and dependencies.(Citation: Writing Bad Malware for OSX) There are tools available to perform these changes.
Adversaries may modify Mach-O binary headers to load and execute malicious dylibs every time the binary is executed. Although any changes will invalidate digital signatures on binaries because the binary is being modified, this can be remediated by simply removing the LC_CODE_SIGNATURE command from the binary so that the signature isn’t checked at load time.(Citation: Malware Persistence on OS X)
No universal command represents LC_LOAD_DYLIB Addition. Capture the exact command line, arguments, parent process, account, host, and execution time from the investigated environment; do not operationalize unverified examples.
| Event ID | Log Channel | What It Indicates |
|---|---|---|
| Not universally applicable | Validate platform coverage | This technique may not produce a Windows event; use telemetry native to the affected platform. |
| Sysmon Event ID | Name | Why It's Relevant Here |
|---|---|---|
| Environment-specific | Validate configured telemetry | Use process, network, file, registry, DNS, or image-load telemetry only when relevant and enabled. |
No MITRE detection guidance published for this technique.
Relevant ATT&CK Data Sources: N/A
A universal Sigma rule would create unreliable results because this technique has no single guaranteed observable. Build detection logic from a documented behavior and supported data source, scope it to the affected platform, and validate it against benign administrative activity before deployment.
Start with the data sources named in the detection section. Scope searches by asset, identity, and time window; correlate the primary behavior with preceding access and subsequent actions. A portable query is intentionally not provided where the technique lacks a universal schema or observable.