File Execution Permission Modification Detected via Defend for Containers

  1[metadata]
  2creation_date = "2023/04/26"
  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 when chmod is used to add the execute permission to a file inside a container. Modifying file
 13permissions to make a file executable could indicate malicious activity, as an attacker may attempt to run unauthorized
 14or malicious code inside the container.
 15"""
 16from = "now-6m"
 17index = ["logs-cloud_defend.file*"]
 18interval = "5m"
 19language = "eql"
 20license = "Elastic License v2"
 21name = "File Execution Permission Modification Detected via Defend for Containers"
 22note = """## Setup
 23
 24## Triage and analysis
 25
 26> **Disclaimer**:
 27> 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.
 28
 29### Investigating File Execution Permission Modification Detected via Defend for Containers
 30
 31Containers provide isolated environments for running applications, often on Linux systems. The `chmod` command is used to change file permissions, including making files executable. Adversaries may exploit this by altering permissions to execute unauthorized scripts or binaries, potentially leading to malicious activity. The detection rule identifies such actions by monitoring for `chmod` usage that grants execute permissions, focusing on specific permission patterns, and excluding benign cases. This helps in identifying potential threats where attackers attempt to execute unauthorized code within containers.
 32
 33### Possible investigation steps
 34
 35- Review the container ID associated with the alert to identify the specific container where the `chmod` command was executed.
 36- Examine the process arguments to determine the exact permissions that were set and identify the file that was made executable.
 37- Investigate the origin of the `chmod` command by reviewing the process tree to understand which parent process initiated it and whether it aligns with expected behavior.
 38- Check the user account or service account that executed the `chmod` command to assess if it has legitimate access and reason to modify file permissions.
 39- Analyze the file that was made executable to determine its contents and origin, checking for any signs of unauthorized or malicious code.
 40- Correlate this event with other logs or alerts from the same container to identify any patterns or additional suspicious activities that might indicate a broader attack.
 41
 42### False positive analysis
 43
 44- Routine maintenance scripts or automated processes may use chmod to set execute permissions on files within containers. To handle these, identify and whitelist specific scripts or processes that are known to be safe and necessary for operations.
 45- Development environments often involve frequent changes to file permissions as developers test and deploy code. Consider excluding specific container IDs or paths associated with development environments to reduce noise.
 46- Some container orchestration tools might use chmod as part of their normal operation. Review the processes and arguments associated with these tools and create exceptions for known benign activities.
 47- System updates or package installations within containers might trigger this rule. Monitor and document regular update schedules and processes, and exclude these from triggering alerts if they are verified as non-threatening.
 48- If certain users or roles are responsible for legitimate permission changes, consider excluding their activities by user ID or role, ensuring that these exclusions are well-documented and reviewed regularly.
 49
 50### Response and remediation
 51
 52- Immediately isolate the affected container to prevent further execution of unauthorized code. This can be done by stopping the container or disconnecting it from the network.
 53- Conduct a thorough review of the container's file system to identify any unauthorized or suspicious files that have been made executable. Remove or quarantine these files as necessary.
 54- Analyze the container's logs to trace the source of the `chmod` command and determine if there are any other indicators of compromise or related malicious activities.
 55- If the unauthorized execution is confirmed, assess the potential impact on the host system and other containers. Implement additional security measures, such as enhanced monitoring or network segmentation, to protect other assets.
 56- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign.
 57- Review and update container security policies to prevent unauthorized permission changes, such as implementing stricter access controls and using security tools that enforce policy compliance.
 58- Enhance detection capabilities by configuring alerts for similar suspicious activities, ensuring that any future attempts to modify file permissions within containers are promptly identified and addressed."""
 59risk_score = 21
 60rule_id = "ec604672-bed9-43e1-8871-cf591c052550"
 61severity = "low"
 62tags = [
 63    "Data Source: Elastic Defend for Containers",
 64    "Domain: Container",
 65    "OS: Linux",
 66    "Use Case: Threat Detection",
 67    "Tactic: Execution",
 68    "Tactic: Defense Evasion",
 69    "Resources: Investigation Guide",
 70]
 71timestamp_override = "event.ingested"
 72type = "eql"
 73query = '''
 74file where host.os.type == "linux" and event.type in ("change", "creation") and (
 75  process.name == "chmod" or
 76  (
 77    /* account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
 78    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
 79    process.args in (
 80      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod"
 81    ) and
 82    /* default exclusion list to not FP on default multi-process commands */
 83    not process.args in (
 84      "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
 85      "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man"
 86    )
 87  )
 88) and process.args in ("4755", "755", "777", "0777", "444", "+x", "a+x") and
 89process.args like ("/dev/shm/*", "/tmp/*", "/var/tmp/*", "/run/*", "/var/run/*", "/mnt/*", "/media/*") and
 90process.interactive == true and container.id like "*" and not process.args == "-x"
 91'''
 92
 93[[rule.threat]]
 94framework = "MITRE ATT&CK"
 95
 96[[rule.threat.technique]]
 97id = "T1059"
 98name = "Command and Scripting Interpreter"
 99reference = "https://attack.mitre.org/techniques/T1059/"
100
101[rule.threat.tactic]
102id = "TA0002"
103name = "Execution"
104reference = "https://attack.mitre.org/tactics/TA0002/"
105
106[[rule.threat]]
107framework = "MITRE ATT&CK"
108
109[[rule.threat.technique]]
110id = "T1222"
111name = "File and Directory Permissions Modification"
112reference = "https://attack.mitre.org/techniques/T1222/"
113
114[[rule.threat.technique.subtechnique]]
115id = "T1222.002"
116name = "Linux and Mac File and Directory Permissions Modification"
117reference = "https://attack.mitre.org/techniques/T1222/002/"
118
119[rule.threat.tactic]
120id = "TA0005"
121name = "Defense Evasion"
122reference = "https://attack.mitre.org/tactics/TA0005/"