LD_PRELOAD injection
A process was launched with LD_PRELOAD set on the command line, forcing a shared library into that process ahead of its own.
What it detects
A process was launched with LD_PRELOAD set on the command line, forcing a shared library into that process ahead of its own. Unlike a change to /etc/ld.so.preload, this affects one invocation, which is what makes it useful for a single act rather than for persistence: hooking a function to steal what passes through it, bypassing a check inside a setuid-adjacent helper, or running attacker code inside a trusted binary's process so the process tree looks normal.
This is the transient half of T1574.006 — the file-based half is linux.persistence.ld_preload_file_modified.
MITRE ATT&CK mapping
- T1574.006Hijack Execution Flow: Dynamic Linker Hijacking· Persistence
False positives and triage
LD_PRELOAD is a supported, documented mechanism and developers use it on purpose: running a binary under a debugging or leak-checking library, forcing a specific allocator, faking time in a test, or shimming a missing symbol. On a developer machine or a CI runner this is routine.
What matters is the library and the host. Check where the .so lives — a path in /tmp, /dev/shm, a home directory, or a filename mimicking a system library is the finding; a package-installed library under /usr/lib is usually not. Then check what it was preloaded into: a shim in front of a test binary is development, a shim in front of sudo, ssh, su or a service is not.
Note that the loader IGNORES LD_PRELOAD for setuid binaries, so an attempt against one of those failed — but the attempt is still evidence of intent and worth reading alongside whatever they tried next.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 60%. Source: rules/linux/ld_preload_injection.yaml, licensed under the Apache License 2.0.
id: linux.execution.ld_preload_injection
version: 1.0.0
status: stable
severity: medium
confidence: 0.6
platforms: [linux]
mitre_techniques: [T1574.006]
description: |
A process was launched with `LD_PRELOAD` set on the command line, forcing a shared
library into that process ahead of its own. Unlike a change to
`/etc/ld.so.preload`, this affects one invocation, which is what makes it useful
for a single act rather than for persistence: hooking a function to steal what
passes through it, bypassing a check inside a setuid-adjacent helper, or running
attacker code inside a trusted binary's process so the process tree looks normal.
This is the transient half of T1574.006 — the file-based half is
`linux.persistence.ld_preload_file_modified`.
match:
command_line_contains_any:
- "LD_PRELOAD="
false_positive_guidance: |
`LD_PRELOAD` is a supported, documented mechanism and developers use it on purpose:
running a binary under a debugging or leak-checking library, forcing a specific
allocator, faking time in a test, or shimming a missing symbol. On a developer
machine or a CI runner this is routine.
What matters is the library and the host. Check where the `.so` lives — a path in
/tmp, /dev/shm, a home directory, or a filename mimicking a system library is the
finding; a package-installed library under /usr/lib is usually not. Then check what
it was preloaded into: a shim in front of a test binary is development, a shim in
front of `sudo`, `ssh`, `su` or a service is not.
Note that the loader IGNORES `LD_PRELOAD` for setuid binaries, so an attempt
against one of those failed — but the attempt is still evidence of intent and
worth reading alongside whatever they tried next.
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.