How do you detect ld.so.preload code injection on Linux?

What changes when you look for ld.so.preload abuse instead of generic Linux malware

Detection is strongest when you treat /etc/ld.so.preload as a high-impact execution control, not just another configuration file. The main question is whether something has altered the dynamic loader’s trust path so that a library is injected into processes at startup. That means you should look for file changes, process startup anomalies, and evidence that a new shared object is being loaded before normal application code.

The file is especially sensitive because a successful preload changes behaviour broadly and early in execution. A small edit can affect many programs at once, so the signal is not just “file changed” but “unexpected library is now on the startup path.” That is why endpoint telemetry and integrity monitoring need to be paired, rather than relying on one control alone.

For Linux response and hunting patterns, the most useful anchor is the broader Linux Detection and Response Guide, because ld.so.preload abuse sits inside the same runtime and telemetry questions as persistence, rootkit behaviour, and unusual library loading.

What evidence usually distinguishes benign preload usage from injection

Benign preload configurations are usually stable, narrowly justified, and tied to a known operational need. Suspicious cases tend to show one or more of the following: a new or modified preload entry without a change record, a library path that points to an unexpected location, a library name that does not match approved software inventory, or processes that begin loading the same non-standard object across multiple startups.

Process visibility matters because the loader executes before many application-level protections have a chance to run. If you only inspect the file after the fact, you may miss the wider pattern of process launches that were already altered. A good hunt therefore correlates file integrity alerts with endpoint events showing module load order, command line context, parent process, and first-seen path for the shared object.

For common adversary techniques around persistence and startup abuse, the MITRE ATT&CK Enterprise Matrix is useful for mapping preload abuse to loader-based persistence and execution behaviour, while the SANS Security Resources collection is a practical reference for building the kind of telemetry review process this detection requires.

How to reduce blind spots without overfitting the alert

Detection works best when you baseline the file and the libraries it points to, then alert on meaningful drift. A change in ownership, permissions, checksum, or referenced library path should matter more than a simple timestamp change. On hosts that legitimately use preload mechanisms, tune alerts to known good paths and approved packages so you do not drown in noise.

Where possible, pair file integrity monitoring with startup telemetry from EDR, audit logs, or eBPF-based sensors. That gives you both the configuration change and the runtime effect. If a new preload entry appears and the associated shared object was never deployed by your software supply process, treat the event as a likely code injection path until proven otherwise.

Controls for integrity, auditability, and secure configuration are directly reinforced by NIST SP 800-53 Rev 5 Security and Privacy Controls, especially the families that govern configuration management, system integrity, and audit logging.

Risk and Threat Considerations

ld.so.preload abuse is high risk because it can turn one file edit into system-wide code execution across many processes. That makes it attractive for persistence, stealthy interception, and defensive bypass, especially when the injected library is placed where operators are unlikely to inspect startup behaviour closely.

Failure mechanism: An attacker or unauthorized actor modifies the preload file or swaps in a malicious shared object, causing the dynamic loader to inject code into processes at start-up before normal application controls can intervene.

Impact: The result can be broad compromise of host integrity, credential exposure inside running processes, tampering with security tools, and long-lived persistence that survives ordinary application restarts.

Practitioner Guidance

What to verify: Confirm whether the preload entry exists for an approved operational reason, whether the referenced library is signed or inventory-backed, and whether the path is writable by anything other than tightly controlled administrative processes. If the answer to any of those is unclear, treat the host as suspicious rather than assuming the file is legitimate.

Decision rule: If the preload file changed and the new library was not part of a planned deployment, prioritize containment and credential review on that host before assuming the issue is only a local configuration mistake. If the file is legitimate but the library path is unusual, investigate the package provenance and recent process activity together, not separately.

Practitioner takeaway: The key judgement is whether the preload entry is both expected and attributable, because any unauthorised loader path can convert a single file modification into broad, early-process code injection.

Related resources from NHI Mgmt Group

• What is the difference between prompt injection risk and identity abuse in agents?
• What happens when a Linux backdoor patches the loader instead of relying only on LD_PRELOAD?
• How should security teams respond when Linux malware uses LD_PRELOAD and rootkit hooks to stay hidden?
• How should security teams detect and contain FormBook infections that use process hollowing and code injection to hide in legitimate processes?