Docker Escape via Nsenter
This rule identifies a UID change event via nsenter
. The nsenter
command is used to enter a namespace, which is a
way to isolate processes and resources. Attackers can use nsenter
to escape from a container to the host, which can
lead to privilege escalation and lateral movement.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/07/10"
3integration = ["endpoint"]
4maturity = "production"
5updated_date = "2025/01/15"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule identifies a UID change event via `nsenter`. The `nsenter` command is used to enter a namespace, which is a
11way to isolate processes and resources. Attackers can use `nsenter` to escape from a container to the host, which can
12lead to privilege escalation and lateral movement.
13"""
14from = "now-9m"
15index = ["logs-endpoint.events.process*"]
16language = "eql"
17license = "Elastic License v2"
18name = "Docker Escape via Nsenter"
19references = ["https://www.cyberark.com/resources/threat-research-blog/the-route-to-root-container-escape-using-kernel-exploitation"]
20risk_score = 47
21rule_id = "5f3ab3ce-7b41-4168-a06a-68d2af8ebc88"
22severity = "medium"
23tags = [
24 "Domain: Endpoint",
25 "Domain: Container",
26 "OS: Linux",
27 "Use Case: Threat Detection",
28 "Tactic: Privilege Escalation",
29 "Data Source: Elastic Defend",
30 "Resources: Investigation Guide",
31]
32timestamp_override = "event.ingested"
33type = "eql"
34query = '''
35process where host.os.type == "linux" and event.type == "change" and event.action == "uid_change" and
36process.entry_leader.entry_meta.type == "container" and process.args == "nsenter" and
37process.args in ("-t", "--target") and process.args_count >= 4
38'''
39note = """## Triage and analysis
40
41> **Disclaimer**:
42> 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.
43
44### Investigating Docker Escape via Nsenter
45
46Docker containers use namespaces to isolate processes, ensuring they operate independently from the host system. The `nsenter` command allows users to access these namespaces, which is essential for managing containerized environments. However, adversaries can exploit `nsenter` to break out of a container, gaining unauthorized access to the host system. The detection rule identifies suspicious UID changes involving `nsenter`, signaling potential container escapes and privilege escalation attempts.
47
48### Possible investigation steps
49
50- Review the alert details to confirm the presence of a UID change event involving the nsenter command, as indicated by the query fields.
51- Identify the container from which the nsenter command was executed by examining the process.entry_leader.entry_meta.type field.
52- Investigate the process arguments to verify the use of nsenter with the -t or --target options, ensuring the process.args_count is 4 or more, which may indicate an attempt to target a specific namespace.
53- Check the user and process context before and after the UID change to understand the potential impact and scope of the privilege escalation.
54- Analyze the container's logs and any associated host logs around the time of the event to gather additional context and identify any suspicious activities or patterns.
55- Assess the container's configuration and security settings to determine if there are any vulnerabilities or misconfigurations that could have been exploited.
56- If unauthorized access is confirmed, initiate incident response procedures to contain and remediate the threat, including reviewing other containers and systems for similar activities.
57
58### False positive analysis
59
60- Routine administrative tasks using nsenter can trigger false positives, especially when system administrators use it for legitimate container management. To mitigate this, create exceptions for known administrative scripts or processes that frequently use nsenter.
61- Automated monitoring tools or scripts that perform health checks or maintenance on containers might use nsenter, leading to false alerts. Identify these tools and whitelist their specific processes or user accounts to reduce noise.
62- Development environments where developers frequently enter containers for debugging purposes can cause false positives. Consider excluding specific development user accounts or container IDs from the rule to prevent unnecessary alerts.
63- Continuous integration and deployment pipelines that interact with containers might use nsenter as part of their operations. Review these pipelines and exclude their associated processes or user accounts to avoid false detections.
64
65### Response and remediation
66
67- Immediately isolate the affected container to prevent further unauthorized access to the host system. This can be done by stopping the container or disconnecting it from the network.
68- Conduct a thorough review of the container's logs and processes to identify any unauthorized changes or suspicious activities that occurred before and after the UID change event.
69- Revoke any unauthorized access or credentials that may have been compromised during the container escape attempt. Ensure that all access keys and passwords are rotated.
70- Patch and update the container image and host system to address any vulnerabilities that may have been exploited. Ensure that the latest security updates are applied.
71- Implement stricter namespace and capability restrictions for containers to minimize the risk of privilege escalation. Consider using security tools like AppArmor or SELinux to enforce these restrictions.
72- Monitor for any further suspicious activity on the host system and other containers, focusing on similar UID change events or unauthorized use of `nsenter`.
73- Escalate the incident to the security operations team for a comprehensive investigation and to assess the potential impact on the broader network and systems."""
74
75[[rule.threat]]
76framework = "MITRE ATT&CK"
77
78[[rule.threat.technique]]
79id = "T1611"
80name = "Escape to Host"
81reference = "https://attack.mitre.org/techniques/T1611/"
82
83[rule.threat.tactic]
84id = "TA0004"
85name = "Privilege Escalation"
86reference = "https://attack.mitre.org/tactics/TA0004/"
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 Docker Escape via Nsenter
Docker containers use namespaces to isolate processes, ensuring they operate independently from the host system. The nsenter
command allows users to access these namespaces, which is essential for managing containerized environments. However, adversaries can exploit nsenter
to break out of a container, gaining unauthorized access to the host system. The detection rule identifies suspicious UID changes involving nsenter
, signaling potential container escapes and privilege escalation attempts.
Possible investigation steps
- Review the alert details to confirm the presence of a UID change event involving the nsenter command, as indicated by the query fields.
- Identify the container from which the nsenter command was executed by examining the process.entry_leader.entry_meta.type field.
- Investigate the process arguments to verify the use of nsenter with the -t or --target options, ensuring the process.args_count is 4 or more, which may indicate an attempt to target a specific namespace.
- Check the user and process context before and after the UID change to understand the potential impact and scope of the privilege escalation.
- Analyze the container's logs and any associated host logs around the time of the event to gather additional context and identify any suspicious activities or patterns.
- Assess the container's configuration and security settings to determine if there are any vulnerabilities or misconfigurations that could have been exploited.
- If unauthorized access is confirmed, initiate incident response procedures to contain and remediate the threat, including reviewing other containers and systems for similar activities.
False positive analysis
- Routine administrative tasks using nsenter can trigger false positives, especially when system administrators use it for legitimate container management. To mitigate this, create exceptions for known administrative scripts or processes that frequently use nsenter.
- Automated monitoring tools or scripts that perform health checks or maintenance on containers might use nsenter, leading to false alerts. Identify these tools and whitelist their specific processes or user accounts to reduce noise.
- Development environments where developers frequently enter containers for debugging purposes can cause false positives. Consider excluding specific development user accounts or container IDs from the rule to prevent unnecessary alerts.
- Continuous integration and deployment pipelines that interact with containers might use nsenter as part of their operations. Review these pipelines and exclude their associated processes or user accounts to avoid false detections.
Response and remediation
- Immediately isolate the affected container to prevent further unauthorized access to the host system. This can be done by stopping the container or disconnecting it from the network.
- Conduct a thorough review of the container's logs and processes to identify any unauthorized changes or suspicious activities that occurred before and after the UID change event.
- Revoke any unauthorized access or credentials that may have been compromised during the container escape attempt. Ensure that all access keys and passwords are rotated.
- Patch and update the container image and host system to address any vulnerabilities that may have been exploited. Ensure that the latest security updates are applied.
- Implement stricter namespace and capability restrictions for containers to minimize the risk of privilege escalation. Consider using security tools like AppArmor or SELinux to enforce these restrictions.
- Monitor for any further suspicious activity on the host system and other containers, focusing on similar UID change events or unauthorized use of
nsenter
. - Escalate the incident to the security operations team for a comprehensive investigation and to assess the potential impact on the broader network and systems.
References
Related rules
- Potential Chroot Container Escape via Mount
- Potential Privilege Escalation through Writable Docker Socket
- Potential Privilege Escalation via Container Misconfiguration
- At Job Created or Modified
- Cron Job Created or Modified