T1546.006No distinct observable

LC_LOAD_DYLIB Addition

Privilege Escalation · PersistencemacOS

Where this stands

A reviewer read the telemetry and concluded there is nothing here to detect that a sibling technique does not already cover.

The brief offers exactly one analytic, AN0607, and all three of its log sources are the same Sigma logsource: product macos, service unifiedlog. That logsource has no standardised Sigma field vocabulary anywhere — not in this brief, which gives prose notes ('Process memory maps new dylib (dylib_load event)', 'Mach-O binary modified or LC_LOAD_DYLIB segment inserted', 'Code signature validation fails or is absent post-binary modification') and no field names at all, and not in any rule already written in this corpus, where a grep for 'service: unifiedlog' across every rule.yml returns nothing. […]

Covered instead by T1546.004, T1574.006, T1027.013.

What the technique is

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. 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.

Read it on attack.mitre.org

What MITRE says you would watch

AN0607
Detection focuses on unauthorized modification of Mach-O binaries to include LC_LOAD_DYLIB headers pointing to malicious dylibs. Behavior is identified via a chain of file metadata changes, removal of code signatures, and subsequent anomalous dylib loads at runtime. Correlation of file changes with lack of authorized updates and process memory mapping of unrecognized or unsigned libraries is crucial.