← Back to Explore
elasticmediumTTP
Potential notify_on_release Container Escape Detected via Defend for Containers
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.
Detection Query
file where host.os.type == "linux" and event.type == "change" and event.action == "open" and
file.name == "notify_on_release" and process.interactive == true and container.id like "*"
Author
Elastic
Created
2023/10/26
Data Sources
Elastic Defend for Containerslogs-cloud_defend.file*
References
Tags
Data Source: Elastic Defend for ContainersDomain: ContainerOS: LinuxUse Case: Threat DetectionTactic: Privilege EscalationResources: Investigation Guide
Raw Content
[metadata]
creation_date = "2023/10/26"
integration = ["cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/01/15"
[rule]
author = ["Elastic"]
description = """
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.
"""
from = "now-6m"
index = ["logs-cloud_defend.file*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Potential notify_on_release Container Escape Detected via Defend for Containers"
note = """## 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 Potential notify_on_release Container Escape Detected via Defend for Containers
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
- 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 = [
"https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/",
"https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/",
]
risk_score = 47
rule_id = "ef65e82c-d8b4-4895-9824-5f6bc6166804"
severity = "medium"
tags = [
"Data Source: Elastic Defend for Containers",
"Domain: Container",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Privilege Escalation",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.type == "change" and event.action == "open" and
file.name == "notify_on_release" and process.interactive == true and container.id like "*"
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1611"
name = "Escape to Host"
reference = "https://attack.mitre.org/techniques/T1611/"
[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"