Potential Docker Escape via Nsenter

ELASTIC detection rule by Elastic · Elastic License v2

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.

[metadata]
creation_date = "2024/07/10"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/23"

[rule]
author = ["Elastic"]
description = """
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.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Docker Escape via Nsenter"
note = """## 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 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 = ["https://www.cyberark.com/resources/threat-research-blog/the-route-to-root-container-escape-using-kernel-exploitation"]
risk_score = 47
rule_id = "5f3ab3ce-7b41-4168-a06a-68d2af8ebc88"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "change" and event.action == "uid_change" and
process.entry_leader.entry_meta.type == "container" and process.args == "nsenter" and
process.args in ("-t", "--target") and process.args_count >= 4 and
not process.parent.args == "/opt/teleport/system/bin/teleport"
'''

[[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/"

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

ca66825d-8b37-4ec5-8fe4-7ffeb8ddb086

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion