DYLD insert libraries
DYLD_INSERT_LIBRARIES set, forcing the dynamic linker to load an attacker's dylib into processes it launches — macOS's equivalent of LD_PRELOAD on…
What it detects
DYLD_INSERT_LIBRARIES set, forcing the dynamic linker to load an attacker's dylib into processes it launches — macOS's equivalent of LD_PRELOAD on Linux, and the same technique this pack already detects there as linux.execution.ld_preload_injection.
Two forms carry different weight and both match. Setting it inline for one command affects that process. Setting it through launchctl setenv puts it in the user's launchd environment, so it is inherited by everything launched afterwards — that is persistence and injection in one command.
Written against a real attacker command line from sbousseaden/macOS-ATTACK-DATASET (launchctl setenv DYLD_INSERT_LIBRARIES /Volumes/Image Volume/HaxDoNotSeal.dylib). The Linux half of this technique was already covered; the macOS half had no rule, which is the kind of asymmetry a per-platform corpus surfaces and a technique list does not.
MITRE ATT&CK mapping
- T1574.006Hijack Execution Flow: Dynamic Linker Hijacking· Persistence
False positives and triage
Debuggers, profilers and some instrumentation frameworks legitimately inject via DYLD. Judge by the dylib's path: one under a developer's project or Xcode is ordinary, one under /tmp, /Volumes (a mounted DMG — as in the source capture), a hidden directory, or a user's Downloads is not.
Escalate on: launchctl setenv, which makes it apply to future processes rather than one command; a dylib on a removable or mounted volume; and any pairing with a quarantine-attribute removal on the same host.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 75%. Source: rules/macos/dyld_insert_libraries.yaml, licensed under the Apache License 2.0.
id: macos.execution.dyld_insert_libraries
version: 1.0.0
status: stable
severity: high
confidence: 0.75
platforms: [macos]
mitre_techniques: [T1574.006]
description: |
`DYLD_INSERT_LIBRARIES` set, forcing the dynamic linker to load an attacker's
dylib into processes it launches — macOS's equivalent of `LD_PRELOAD` on Linux,
and the same technique this pack already detects there as
`linux.execution.ld_preload_injection`.
Two forms carry different weight and both match. Setting it inline for one
command affects that process. Setting it through `launchctl setenv` puts it in
the user's launchd environment, so it is inherited by everything launched
afterwards — that is persistence and injection in one command.
Written against a real attacker command line from sbousseaden/macOS-ATTACK-DATASET
(`launchctl setenv DYLD_INSERT_LIBRARIES /Volumes/Image Volume/HaxDoNotSeal.dylib`).
The Linux half of this technique has been covered since FEAT-015; the macOS half
had no rule, which is the kind of asymmetry a per-platform corpus surfaces and a
technique list does not.
match:
raw_message_contains_any:
- "DYLD_INSERT_LIBRARIES"
- "DYLD_FRAMEWORK_PATH"
- "DYLD_LIBRARY_PATH"
false_positive_guidance: |
Debuggers, profilers and some instrumentation frameworks legitimately inject via
DYLD. Judge by the dylib's path: one under a developer's project or Xcode is
ordinary, one under `/tmp`, `/Volumes` (a mounted DMG — as in the source capture),
a hidden directory, or a user's Downloads is not.
Escalate on: `launchctl setenv`, which makes it apply to future processes rather
than one command; a dylib on a removable or mounted volume; and any pairing with
a quarantine-attribute removal on the same host.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.