Dynamic Linker Modification Detected via Defend for Containers

This rule detects the creation or modification of the dynamic linker preload shared object (ld.so.preload) inside a container. The Linux dynamic linker is used to load libraries needed by a program at runtime. Adversaries may hijack the dynamic linker by modifying the /etc/ld.so.preload file to point to malicious libraries. This behavior can be used to grant unauthorized access to system resources and has been used to evade detection of malicious processes in container environments.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2023/06/06"
  3integration = ["cloud_defend"]
  4maturity = "production"
  5min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
  6min_stack_version = "9.3.0"
  7updated_date = "2026/01/15"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the creation or modification of the dynamic linker preload shared object (ld.so.preload) inside a
 13container. The Linux dynamic linker is used to load libraries needed by a program at runtime. Adversaries may hijack the
 14dynamic linker by modifying the /etc/ld.so.preload file to point to malicious libraries. This behavior can be used to
 15grant unauthorized access to system resources and has been used to evade detection of malicious processes in container
 16environments.
 17"""
 18from = "now-6m"
 19index = ["logs-cloud_defend.file*"]
 20interval = "5m"
 21language = "eql"
 22license = "Elastic License v2"
 23name = "Dynamic Linker Modification Detected via Defend for Containers"
 24note = """## Setup
 25
 26## Triage and analysis
 27
 28> **Disclaimer**:
 29> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 30
 31### Investigating Dynamic Linker Modification Detected via Defend for Containers
 32
 33The dynamic linker in Linux loads necessary libraries for programs at runtime, with the `ld.so.preload` file specifying libraries to load first. Adversaries exploit this by redirecting it to malicious libraries, gaining unauthorized access and evading detection. The detection rule identifies suspicious modifications to this file within containers, signaling potential hijacking attempts.
 34
 35### Possible investigation steps
 36
 37- Review the alert details to confirm the file path involved is "/etc/ld.so.preload", "/etc/ld.so.conf.d/*", or "/etc/ld.so.conf" and the event type is not "deletion", as specified in the query.
 38- Examine the container's metadata and context to identify the specific container where the modification occurred, including container ID, image, and host details.
 39- Investigate recent changes to the "/etc/ld.so.preload" file within the container by checking the file's modification history and identifying the user or process responsible for the change.
 40- Analyze the contents of the modified "/etc/ld.so.preload" file to determine if it references any suspicious or unauthorized libraries.
 41- Correlate the event with other security logs and alerts to identify any related suspicious activities or patterns, such as unauthorized access attempts or execution of unknown processes within the container.
 42- Assess the potential impact of the modification by evaluating the libraries listed in the preload file and their potential to grant unauthorized access or evade detection.
 43- Consider isolating the affected container to prevent further unauthorized access or malicious activity while the investigation is ongoing.
 44
 45### False positive analysis
 46
 47- Routine system updates or maintenance activities may modify the ld.so.preload file. Users should verify if the changes coincide with scheduled updates and consider excluding these events if they are confirmed to be benign.
 48- Some containerized applications might legitimately modify the ld.so.preload file to optimize performance or load specific libraries. Users should identify these applications and create exceptions for their known behaviors to prevent false alerts.
 49- Automated configuration management tools might alter the ld.so.preload file as part of their normal operations. Users should review the tool's activity logs and whitelist these actions if they are consistent with expected behavior.
 50- Development or testing environments often involve frequent changes to system files, including ld.so.preload. Users should differentiate between production and non-production environments and apply more lenient rules to the latter to reduce false positives.
 51
 52### Response and remediation
 53
 54- Immediately isolate the affected container to prevent further unauthorized access or execution of malicious code. This can be done by stopping the container or disconnecting it from the network.
 55- Conduct a thorough review of the `/etc/ld.so.preload`, `/etc/ld.so.conf.d/*`, or `/etc/ld.so.conf` files within the container to identify any unauthorized or malicious entries. Remove any entries that are not recognized or are confirmed to be malicious.
 56- Verify the integrity of the container's base image and all installed libraries to ensure no other components have been tampered with. Rebuild the container from a trusted image if necessary.
 57- Implement monitoring and alerting for any future modifications to the `/etc/ld.so.preload`, `/etc/ld.so.conf.d/*`, or `/etc/ld.so.conf` file across all containers to detect similar threats promptly.
 58- Review and tighten access controls and permissions for container environments to minimize the risk of unauthorized modifications to critical system files.
 59- Escalate the incident to the security operations team for further investigation and to determine if the threat has spread to other parts of the infrastructure.
 60- Document the incident, including the steps taken for containment and remediation, to improve response strategies and update incident response plans for future reference."""
 61references = [
 62    "https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/",
 63    "https://www.anomali.com/blog/rocke-evolves-its-arsenal-with-a-new-malware-family-written-in-golang/",
 64    "https://sysdig.com/blog/threat-detection-aws-cloud-containers/",
 65]
 66risk_score = 73
 67rule_id = "342f834b-21a6-41bf-878c-87d116eba3ee"
 68severity = "high"
 69tags = [
 70    "Data Source: Elastic Defend for Containers",
 71    "Domain: Container",
 72    "OS: Linux",
 73    "Use Case: Threat Detection",
 74    "Tactic: Defense Evasion",
 75    "Resources: Investigation Guide",
 76]
 77timestamp_override = "event.ingested"
 78type = "eql"
 79query = '''
 80file where host.os.type == "linux" and event.type != "deletion" and
 81file.path like ("/etc/ld.so.preload", "/etc/ld.so.conf.d/*", "/etc/ld.so.conf") and
 82process.interactive == true and container.id like "*" 
 83'''
 84
 85[[rule.threat]]
 86framework = "MITRE ATT&CK"
 87
 88[[rule.threat.technique]]
 89id = "T1574"
 90name = "Hijack Execution Flow"
 91reference = "https://attack.mitre.org/techniques/T1574/"
 92
 93[[rule.threat.technique.subtechnique]]
 94id = "T1574.006"
 95name = "Dynamic Linker Hijacking"
 96reference = "https://attack.mitre.org/techniques/T1574/006/"
 97
 98[rule.threat.tactic]
 99id = "TA0005"
100name = "Defense Evasion"
101reference = "https://attack.mitre.org/tactics/TA0005/"

Setup

Triage and analysis

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

Investigating Dynamic Linker Modification Detected via Defend for Containers

The dynamic linker in Linux loads necessary libraries for programs at runtime, with the ld.so.preload file specifying libraries to load first. Adversaries exploit this by redirecting it to malicious libraries, gaining unauthorized access and evading detection. The detection rule identifies suspicious modifications to this file within containers, signaling potential hijacking attempts.

Possible investigation steps

  • Review the alert details to confirm the file path involved is "/etc/ld.so.preload", "/etc/ld.so.conf.d/*", or "/etc/ld.so.conf" and the event type is not "deletion", as specified in the query.
  • Examine the container's metadata and context to identify the specific container where the modification occurred, including container ID, image, and host details.
  • Investigate recent changes to the "/etc/ld.so.preload" file within the container by checking the file's modification history and identifying the user or process responsible for the change.
  • Analyze the contents of the modified "/etc/ld.so.preload" file to determine if it references any suspicious or unauthorized libraries.
  • Correlate the event with other security logs and alerts to identify any related suspicious activities or patterns, such as unauthorized access attempts or execution of unknown processes within the container.
  • Assess the potential impact of the modification by evaluating the libraries listed in the preload file and their potential to grant unauthorized access or evade detection.
  • Consider isolating the affected container to prevent further unauthorized access or malicious activity while the investigation is ongoing.

False positive analysis

  • Routine system updates or maintenance activities may modify the ld.so.preload file. Users should verify if the changes coincide with scheduled updates and consider excluding these events if they are confirmed to be benign.
  • Some containerized applications might legitimately modify the ld.so.preload file to optimize performance or load specific libraries. Users should identify these applications and create exceptions for their known behaviors to prevent false alerts.
  • Automated configuration management tools might alter the ld.so.preload file as part of their normal operations. Users should review the tool's activity logs and whitelist these actions if they are consistent with expected behavior.
  • Development or testing environments often involve frequent changes to system files, including ld.so.preload. Users should differentiate between production and non-production environments and apply more lenient rules to the latter to reduce false positives.

Response and remediation

  • Immediately isolate the affected container to prevent further unauthorized access or execution of malicious code. This can be done by stopping the container or disconnecting it from the network.
  • Conduct a thorough review of the /etc/ld.so.preload, /etc/ld.so.conf.d/*, or /etc/ld.so.conf files within the container to identify any unauthorized or malicious entries. Remove any entries that are not recognized or are confirmed to be malicious.
  • Verify the integrity of the container's base image and all installed libraries to ensure no other components have been tampered with. Rebuild the container from a trusted image if necessary.
  • Implement monitoring and alerting for any future modifications to the /etc/ld.so.preload, /etc/ld.so.conf.d/*, or /etc/ld.so.conf file across all containers to detect similar threats promptly.
  • Review and tighten access controls and permissions for container environments to minimize the risk of unauthorized modifications to critical system files.
  • Escalate the incident to the security operations team for further investigation and to determine if the threat has spread to other parts of the infrastructure.
  • Document the incident, including the steps taken for containment and remediation, to improve response strategies and update incident response plans for future reference.

References

Related rules

to-top