Adversaries may use an ld_preload backdoor to inject malicious code into legitimate processes, allowing persistence and privilege escalation. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify potential stealthy persistence mechanisms that evade traditional detection methods.
YARA Rule
rule ld_preload_backdoor {
strings: $ = "killall -9 \".basename(\"/usr/bin/host"
condition: any of them
}
This YARA rule can be deployed in the following contexts:
Scenario: System update or package installation using ld_preload for compatibility or debugging purposes.
Filter/Exclusion: Check for known legitimate tools like gdb or valgrind in the command line or process tree. Exclude processes where ld_preload is used in conjunction with known debugging or profiling tools.
Scenario: Scheduled job using ld_preload to load a shared library for performance monitoring or logging.
Filter/Exclusion: Exclude processes initiated by cron or systemd timers that are known to use ld_preload for monitoring tools like perf or ltrace.
Scenario: Admin task involving dynamic linking configuration for a custom application or service.
Filter/Exclusion: Exclude processes where ld_preload is set in /etc/ld.so.preload or environment variables for system services like nginx, apache, or postgresql.
Scenario: Security tool or IDS using ld_preload to inject monitoring code for runtime analysis.
Filter/Exclusion: Exclude processes associated with known security tools like gosec, checksec, or ptrace-based analysis tools.
Scenario: Development environment using ld_preload to intercept system calls for testing or fuzzing.
Filter/Exclusion: Exclude processes running under development tools like gdb, valgrind, or fuzzers such as afl-fuzz or libfuzzer.