LD_PRELOAD file modified
/etc/ld.so.preload was created or replaced.
What it detects
/etc/ld.so.preload was created or replaced. Every shared library listed in that file is loaded into every dynamically linked process on the host, before the program's own libraries — which means a single line in it gives an attacker code running inside ls, ps, sshd and everything else. Userland rootkits use exactly this to hook readdir and open so their own files stop appearing, and to hook authentication so a magic password always works.
The file does not exist on a default installation. Its creation is the event.
Matches CREATE and DELETE because an in-place edit surfaces in auditd as an editor writing ld.so.preload~ and renaming over the original — a create and a delete, not a write. A read is NORMAL and does not fire.
MITRE ATT&CK mapping
- T1574.006Hijack Execution Flow: Dynamic Linker Hijacking· Persistence
False positives and triage
Legitimate uses are rare and specific: some memory allocators (jemalloc, tcmalloc), profilers, and licensing or APM agents install themselves through /etc/ld.so.preload. Snapshot the file's expected contents on a known-good host — if you have one, this rule is a change-detection alarm on a file that should never change outside a deployment.
Read the file before deciding. A path under /usr/lib belonging to a package you installed is one thing; a .so in /tmp, /dev/shm, a home directory, or with a name designed to look like a system library is a rootkit. Also check whether the library named is present on disk at all: a preload entry pointing at a deleted file leaves every process logging a loader error, which is often how this is noticed at all.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 75%. Source: rules/linux/ld_preload_persistence.yaml, licensed under the Apache License 2.0.
id: linux.persistence.ld_preload_file_modified
version: 1.0.0
status: stable
severity: high
confidence: 0.75
platforms: [linux]
mitre_techniques: [T1574.006]
description: |
`/etc/ld.so.preload` was created or replaced. Every shared library listed in that
file is loaded into every dynamically linked process on the host, before the
program's own libraries — which means a single line in it gives an attacker code
running inside `ls`, `ps`, `sshd` and everything else. Userland rootkits use
exactly this to hook `readdir` and `open` so their own files stop appearing, and to
hook authentication so a magic password always works.
The file does not exist on a default installation. Its creation is the event.
Matches CREATE and DELETE because an in-place edit surfaces in auditd as an editor
writing `ld.so.preload~` and renaming over the original — a create and a delete,
not a write. A read is `NORMAL` and does not fire.
match:
file_path_regex: '^/etc/ld\.so\.preload~?$'
event_action_any:
- file_created
- file_deleted
false_positive_guidance: |
Legitimate uses are rare and specific: some memory allocators (jemalloc,
tcmalloc), profilers, and licensing or APM agents install themselves through
`/etc/ld.so.preload`. Snapshot the file's expected contents on a known-good host —
if you have one, this rule is a change-detection alarm on a file that should never
change outside a deployment.
Read the file before deciding. A path under /usr/lib belonging to a package you
installed is one thing; a `.so` in /tmp, /dev/shm, a home directory, or with a name
designed to look like a system library is a rootkit. Also check whether the library
named is present on disk at all: a preload entry pointing at a deleted file leaves
every process logging a loader error, which is often how this is noticed at all.
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.