Deprecated - Potential Container Escape via Modified notify_on_release File
This rule detects modification of the cgroup notify_on_release file from inside a container. When the notify_on_release flag is enabled (1) in a cgroup, then whenever the last task in the cgroup exits or attaches to another cgroup, the command specified in the release_agent file is run and invoked from the host. A privileged container with SYS_ADMIN capabilities, enables a threat actor to mount a cgroup directory and modify the notify_on_release flag in order to take advantage of this feature, which could be used for further privilege escalation and container escapes to the host machine.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2023/10/26"
3integration = ["cloud_defend"]
4deprecation_date = "2025/03/14"
5maturity = "deprecated"
6updated_date = "2025/03/14"
7
8[rule]
9author = ["Elastic"]
10description = """
11This rule detects modification of the cgroup notify_on_release file from inside a container. When the notify_on_release
12flag is enabled (1) in a cgroup, then whenever the last task in the cgroup exits or attaches to another cgroup, the
13command specified in the release_agent file is run and invoked from the host. A privileged container with SYS_ADMIN
14capabilities, enables a threat actor to mount a cgroup directory and modify the notify_on_release flag in order to take
15advantage of this feature, which could be used for further privilege escalation and container escapes to the host
16machine.
17"""
18from = "now-6m"
19index = ["logs-cloud_defend*"]
20interval = "5m"
21language = "eql"
22license = "Elastic License v2"
23name = "Deprecated - Potential Container Escape via Modified notify_on_release File"
24references = [
25 "https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/",
26 "https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/",
27]
28risk_score = 73
29rule_id = "ef65e82c-d8b4-4895-9824-5f6bc6166804"
30severity = "high"
31tags = [
32 "Data Source: Elastic Defend for Containers",
33 "Domain: Container",
34 "OS: Linux",
35 "Use Case: Threat Detection",
36 "Tactic: Privilege Escalation",
37 "Resources: Investigation Guide",
38]
39timestamp_override = "event.ingested"
40type = "eql"
41
42query = '''
43file where event.module == "cloud_defend" and event.action == "open" and
44event.type == "change" and file.name : "notify_on_release"
45'''
46note = """## Setup
47
48This rule was deprecated in the 8.18 and 9.0 versions of the Elastic Stack due to deprecation of the 'Defend For Containers' integration. Users using 8.18+ versions should disable this rule and enable linux-based rules tagged "Domain: Container".
49
50## Triage and analysis
51
52> **Disclaimer**:
53> 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.
54
55### Investigating Deprecated - Potential Container Escape via Modified notify_on_release File
56
57In containerized environments, the `notify_on_release` file in cgroups can trigger host-level commands when a cgroup becomes empty. Adversaries exploit this by modifying the file from privileged containers, potentially executing unauthorized commands on the host. The detection rule monitors changes to `notify_on_release` files, flagging suspicious modifications indicative of privilege escalation attempts.
58
59### Possible investigation steps
60
61- Review the alert details to confirm the file involved is indeed the "notify_on_release" file and verify the event.module is "cloud_defend" with event.action as "open" and event.type as "change".
62- Identify the container from which the modification attempt originated by examining the associated metadata, such as container ID or name, to understand the context of the alert.
63- Check the privileges and capabilities assigned to the container, specifically looking for SYS_ADMIN capabilities, which could allow modification of cgroup settings.
64- Investigate the release_agent file associated with the cgroup to determine if any unauthorized or suspicious commands are configured to execute upon cgroup release.
65- Review recent activity logs and command history within the container to identify any anomalous behavior or commands that could indicate an attempt to exploit the notify_on_release mechanism.
66- Assess the potential impact on the host system by determining if any unauthorized commands have been executed as a result of the modification, and evaluate the need for containment or remediation actions.
67
68### False positive analysis
69
70- Routine maintenance tasks in containerized environments may involve legitimate modifications to the notify_on_release file. Users should verify if such changes align with scheduled maintenance activities.
71- Automated container orchestration tools might modify cgroup settings, including the notify_on_release file, as part of their normal operations. Users can create exceptions for known orchestration tools by identifying their specific process IDs or user accounts.
72- Some containerized applications may require modifications to cgroup settings for performance tuning or resource management. Users should document these applications and exclude their expected behavior from triggering alerts.
73- Development and testing environments often involve frequent changes to container configurations, including cgroup files. Users can reduce noise by applying the rule only to production environments or by setting up separate monitoring profiles for non-production systems.
74- If a specific container consistently triggers alerts without malicious intent, users can whitelist the container by its unique identifier or image name, ensuring that only unexpected changes are flagged.
75
76### Response and remediation
77
78- Immediately isolate the affected container to prevent further unauthorized actions. This can be done by stopping the container or disconnecting it from the network.
79- Review and revoke any unnecessary privileges or capabilities, such as SYS_ADMIN, from the container to minimize the risk of exploitation.
80- Inspect the release_agent file associated with the cgroup to identify any unauthorized commands or scripts that may have been set for execution.
81- Remove or reset any malicious or unauthorized entries in the release_agent file to prevent further execution of host-level commands.
82- Conduct a thorough audit of the host system for any signs of compromise or unauthorized access, focusing on logs and system changes around the time of the alert.
83- Patch and update the container runtime and host operating system to address any known vulnerabilities that could facilitate container escapes.
84- Enhance monitoring and alerting for similar activities by ensuring that all cgroup modifications are logged and reviewed regularly, and consider implementing additional security controls such as AppArmor or SELinux to restrict container capabilities."""
85
86
87[[rule.threat]]
88framework = "MITRE ATT&CK"
89[[rule.threat.technique]]
90id = "T1611"
91name = "Escape to Host"
92reference = "https://attack.mitre.org/techniques/T1611/"
93
94
95[rule.threat.tactic]
96id = "TA0004"
97name = "Privilege Escalation"
98reference = "https://attack.mitre.org/tactics/TA0004/"
Setup
This rule was deprecated in the 8.18 and 9.0 versions of the Elastic Stack due to deprecation of the 'Defend For Containers' integration. Users using 8.18+ versions should disable this rule and enable linux-based rules tagged "Domain: Container".
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 Deprecated - Potential Container Escape via Modified notify_on_release File
In containerized environments, the notify_on_release
file in cgroups can trigger host-level commands when a cgroup becomes empty. Adversaries exploit this by modifying the file from privileged containers, potentially executing unauthorized commands on the host. The detection rule monitors changes to notify_on_release
files, flagging suspicious modifications indicative of privilege escalation attempts.
Possible investigation steps
- Review the alert details to confirm the file involved is indeed the "notify_on_release" file and verify the event.module is "cloud_defend" with event.action as "open" and event.type as "change".
- Identify the container from which the modification attempt originated by examining the associated metadata, such as container ID or name, to understand the context of the alert.
- Check the privileges and capabilities assigned to the container, specifically looking for SYS_ADMIN capabilities, which could allow modification of cgroup settings.
- Investigate the release_agent file associated with the cgroup to determine if any unauthorized or suspicious commands are configured to execute upon cgroup release.
- Review recent activity logs and command history within the container to identify any anomalous behavior or commands that could indicate an attempt to exploit the notify_on_release mechanism.
- Assess the potential impact on the host system by determining if any unauthorized commands have been executed as a result of the modification, and evaluate the need for containment or remediation actions.
False positive analysis
- Routine maintenance tasks in containerized environments may involve legitimate modifications to the notify_on_release file. Users should verify if such changes align with scheduled maintenance activities.
- Automated container orchestration tools might modify cgroup settings, including the notify_on_release file, as part of their normal operations. Users can create exceptions for known orchestration tools by identifying their specific process IDs or user accounts.
- Some containerized applications may require modifications to cgroup settings for performance tuning or resource management. Users should document these applications and exclude their expected behavior from triggering alerts.
- Development and testing environments often involve frequent changes to container configurations, including cgroup files. Users can reduce noise by applying the rule only to production environments or by setting up separate monitoring profiles for non-production systems.
- If a specific container consistently triggers alerts without malicious intent, users can whitelist the container by its unique identifier or image name, ensuring that only unexpected changes are flagged.
Response and remediation
- Immediately isolate the affected container to prevent further unauthorized actions. This can be done by stopping the container or disconnecting it from the network.
- Review and revoke any unnecessary privileges or capabilities, such as SYS_ADMIN, from the container to minimize the risk of exploitation.
- Inspect the release_agent file associated with the cgroup to identify any unauthorized commands or scripts that may have been set for execution.
- Remove or reset any malicious or unauthorized entries in the release_agent file to prevent further execution of host-level commands.
- Conduct a thorough audit of the host system for any signs of compromise or unauthorized access, focusing on logs and system changes around the time of the alert.
- Patch and update the container runtime and host operating system to address any known vulnerabilities that could facilitate container escapes.
- Enhance monitoring and alerting for similar activities by ensuring that all cgroup modifications are logged and reviewed regularly, and consider implementing additional security controls such as AppArmor or SELinux to restrict container capabilities.
References
Related rules
- Deprecated - File System Debugger Launched Inside a Privileged Container
- Deprecated - Mount Launched Inside a Privileged Container
- Deprecated - Potential Container Escape via Modified release_agent File
- Deprecated - AWS Credentials Searched For Inside A Container
- Deprecated - Container Management Utility Run Inside A Container