ldpreload

Hunt Hypothesis

The ldpreload rule detects potential adversary attempts to load malicious shared libraries into the address space of a process to evade detection. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify and mitigate stealthy persistence techniques that may bypass traditional security controls.

YARA Rule

rule ldpreload
{
        meta:
                author="xorseed"
                reference= "https://stuff.rop.io/"
	strings:
		$a = "dlopen" nocase ascii wide
		$b = "dlsym" nocase ascii wide
		$c = "fopen" nocase ascii wide
		$d = "fopen64" nocase ascii wide
		$e = "__fxstat" nocase ascii wide
		$f = "__fxstat64" nocase ascii wide
		$g = "accept" nocase ascii wide
		$h = "__lxstat" nocase ascii wide
		$i = "__lxstat64" nocase ascii wide
		$j = "open" nocase ascii wide
		$k = "rmdir" nocase ascii wide
		$l = "__xstat" nocase ascii wide
		$m = "__xstat64" nocase ascii wide
		$n = "unlink" nocase ascii wide
		$o = "unlikat" nocase ascii wide
		$p = "fdopendir" nocase ascii wide
		$q = "opendir" nocase ascii wide
		$r = "readdir" nocase ascii wide
		$s = "readdir64" nocase ascii wide
	condition:
		($a or $b) and 5 of them
}

Deployment Notes

This YARA rule can be deployed in the following contexts:

• Microsoft Defender for Endpoint — Custom indicators / advanced hunting
• Email Gateway — Attachment scanning
• File Share Monitoring — Periodic scanning of shared drives
• YARA CLI — Manual threat hunting on endpoints

This rule contains 19 string patterns in its detection logic.

References

• https://stuff.rop.io/
• Source Rule

False Positive Guidance

• Scenario: Systemd service configuration
  Description: A legitimate systemd service may use ldpreload to load a shared library for performance or compatibility reasons.
  Filter/Exclusion: Check for systemd service files (/etc/systemd/system/*.service) and ensure the ldpreload directive is used in a known, approved context.

• Scenario: Admin task using ldd or ldconfig
  Description: System administrators may run ldd or ldconfig to manage shared libraries, which can temporarily trigger ldpreload in logs.
  Filter/Exclusion: Filter out processes with ldd or ldconfig in their command line, or check for user IDs associated with admin accounts.

• Scenario: Scheduled job for library updates
  Description: A scheduled job (e.g., via cron or systemd-timer) may update shared libraries, causing ldpreload to be referenced in logs.
  Filter/Exclusion: Exclude processes with cron or systemd-timer in their parent process or command line.

• Scenario: Security tool or IDS integration
  Description: Some security tools or intrusion detection systems (e.g., OSSEC, Snort, or Suricata) may use ldpreload for runtime monitoring or hooking.
  Filter/Exclusion: Check for known security tool binaries or process names (e.g., ossec or snort) and exclude them from alerts.

• Scenario: Container runtime or virtualization tools
  Description: Tools like Docker, Kubernetes, or LXC may use ldpreload for container isolation or monitoring.
  Filter/Exclusion: Exclude processes with container-related command-line arguments (e.g., --cgroup, `