Mount Launched Inside a Container

This rule detects the use of the mount utility from inside a container. The mount command is used to make a device or file system accessible to the system, and then to connect its root directory to a specified mount point on the local file system. When launched inside a privileged container--a container deployed with all the capabilities of the host machine-- an attacker can access sensitive host level files which could be used for further privilege escalation and container escapes to the host machine. Any usage of mount inside a running privileged container should be further investigated.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/03/12"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/03/12"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects the use of the mount utility from inside a container. The mount command is used to make a
 11device or file system accessible to the system, and then to connect its root directory to a specified mount point on the
 12local file system. When launched inside a privileged container--a container deployed with all the capabilities of the
 13host machine-- an attacker can access sensitive host level files which could be used for further privilege escalation
 14and container escapes to the host machine. Any usage of mount inside a running privileged container should be further
 15investigated.
 16"""
 17from = "now-9m"
 18index = ["logs-endpoint.events.process*"]
 19language = "eql"
 20license = "Elastic License v2"
 21name = "Mount Launched Inside a Container"
 22references = [
 23    "https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation#privileged",
 24]
 25risk_score = 47
 26rule_id = "c73cc6ab-b30e-46bf-b5f2-29d9ab4caf7b"
 27setup = """## Setup
 28
 29This rule requires data coming in from Elastic Defend.
 30
 31### Elastic Defend Integration Setup
 32Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
 33
 34#### Prerequisite Requirements:
 35- Fleet is required for Elastic Defend.
 36- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 37
 38#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 39- Go to the Kibana home page and click "Add integrations".
 40- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 41- Click "Add Elastic Defend".
 42- Configure the integration name and optionally add a description.
 43- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 44- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
 45- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 46- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
 47
 48For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 49- Click "Save and Continue".
 50- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
 51For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 52"""
 53severity = "medium"
 54tags = [
 55    "Domain: Container",
 56    "OS: Linux",
 57    "Use Case: Threat Detection",
 58    "Tactic: Privilege Escalation",
 59    "Data Source: Elastic Defend",
 60    "Resources: Investigation Guide",
 61]
 62timestamp_override = "event.ingested"
 63type = "eql"
 64query = '''
 65process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
 66process.entry_leader.entry_meta.type == "container" and process.name == "mount"
 67'''
 68note = """## Triage and analysis
 69
 70> **Disclaimer**:
 71> 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.
 72
 73### Investigating Mount Launched Inside a Container
 74
 75In containerized environments, the `mount` utility is crucial for attaching file systems to the system's directory tree. When executed within a privileged container, which has extensive host capabilities, it can be exploited by adversaries to access sensitive host files, potentially leading to privilege escalation or container escapes. The detection rule identifies such misuse by monitoring the execution of `mount` in containers, flagging potential security threats for further investigation.
 76
 77### Possible investigation steps
 78
 79- Review the alert details to confirm that the process name or arguments include "mount" and that the container's security context is marked as privileged.
 80- Check the container's deployment configuration to verify if it was intentionally set as privileged and assess whether this level of privilege is necessary for its function.
 81- Investigate the user or process that initiated the mount command within the container to determine if it aligns with expected behavior or if it indicates potential malicious activity.
 82- Examine the mounted file systems and directories to identify any sensitive host files that may have been accessed or exposed.
 83- Review logs and historical data for any previous suspicious activities associated with the same container or user to identify patterns or repeated attempts at privilege escalation.
 84
 85### False positive analysis
 86
 87- Routine maintenance tasks within privileged containers may trigger the rule. Exclude known maintenance scripts or processes by adding them to an exception list based on their unique identifiers or command patterns.
 88- Backup operations that require mounting file systems might be flagged. Identify and exclude these operations by specifying the backup process names or arguments in the rule exceptions.
 89- Development or testing environments often use privileged containers for convenience. If these environments are known and controlled, consider excluding them by container IDs or labels to reduce noise.
 90- Automated deployment tools that use mount commands in privileged containers can be mistaken for threats. Review and whitelist these tools by their process names or specific arguments to prevent false alerts.
 91- Certain monitoring or logging solutions may use mount operations for data collection. Verify these solutions and exclude their processes if they are legitimate and necessary for system operations.
 92
 93### Response and remediation
 94
 95- Immediately isolate the affected container to prevent further access to sensitive host files. This can be done by stopping the container or disconnecting it from the network.
 96- Review and revoke any unnecessary privileges from the container's security context to prevent similar incidents. Ensure that containers run with the least privileges necessary.
 97- Conduct a thorough analysis of the container's file system and logs to identify any unauthorized access or modifications to host files.
 98- If unauthorized access is confirmed, perform a comprehensive audit of the host system to check for any signs of compromise or privilege escalation attempts.
 99- Patch and update the container image and host system to address any vulnerabilities that may have been exploited.
100- Implement stricter access controls and monitoring for privileged containers, ensuring that only trusted users and processes can execute sensitive commands like `mount`.
101- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions."""
102
103[[rule.threat]]
104framework = "MITRE ATT&CK"
105
106[[rule.threat.technique]]
107id = "T1611"
108name = "Escape to Host"
109reference = "https://attack.mitre.org/techniques/T1611/"
110
111[rule.threat.tactic]
112id = "TA0004"
113name = "Privilege Escalation"
114reference = "https://attack.mitre.org/tactics/TA0004/"
...
toml

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.

In containerized environments, the mount utility is crucial for attaching file systems to the system's directory tree. When executed within a privileged container, which has extensive host capabilities, it can be exploited by adversaries to access sensitive host files, potentially leading to privilege escalation or container escapes. The detection rule identifies such misuse by monitoring the execution of mount in containers, flagging potential security threats for further investigation.

  • Review the alert details to confirm that the process name or arguments include "mount" and that the container's security context is marked as privileged.
  • Check the container's deployment configuration to verify if it was intentionally set as privileged and assess whether this level of privilege is necessary for its function.
  • Investigate the user or process that initiated the mount command within the container to determine if it aligns with expected behavior or if it indicates potential malicious activity.
  • Examine the mounted file systems and directories to identify any sensitive host files that may have been accessed or exposed.
  • Review logs and historical data for any previous suspicious activities associated with the same container or user to identify patterns or repeated attempts at privilege escalation.
  • Routine maintenance tasks within privileged containers may trigger the rule. Exclude known maintenance scripts or processes by adding them to an exception list based on their unique identifiers or command patterns.
  • Backup operations that require mounting file systems might be flagged. Identify and exclude these operations by specifying the backup process names or arguments in the rule exceptions.
  • Development or testing environments often use privileged containers for convenience. If these environments are known and controlled, consider excluding them by container IDs or labels to reduce noise.
  • Automated deployment tools that use mount commands in privileged containers can be mistaken for threats. Review and whitelist these tools by their process names or specific arguments to prevent false alerts.
  • Certain monitoring or logging solutions may use mount operations for data collection. Verify these solutions and exclude their processes if they are legitimate and necessary for system operations.
  • Immediately isolate the affected container to prevent further access to sensitive host files. This can be done by stopping the container or disconnecting it from the network.
  • Review and revoke any unnecessary privileges from the container's security context to prevent similar incidents. Ensure that containers run with the least privileges necessary.
  • Conduct a thorough analysis of the container's file system and logs to identify any unauthorized access or modifications to host files.
  • If unauthorized access is confirmed, perform a comprehensive audit of the host system to check for any signs of compromise or privilege escalation attempts.
  • Patch and update the container image and host system to address any vulnerabilities that may have been exploited.
  • Implement stricter access controls and monitoring for privileged containers, ensuring that only trusted users and processes can execute sensitive commands like mount.
  • Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions.

References

Related rules

to-top