File System Debugger Launched Inside a Container

This rule detects the use of the built-in Linux DebugFS utility from inside a container. DebugFS is a special file system debugging utility which supports reading and writing directly from a hard drive device. 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.

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 built-in Linux DebugFS utility from inside a container. DebugFS is a special
 11file system debugging utility which supports reading and writing directly from a hard drive device. When launched inside
 12a privileged container, a container deployed with all the capabilities of the host machine, an attacker can access
 13sensitive host level files which could be used for further privilege escalation and container escapes to the host
 14machine.
 15"""
 16from = "now-9m"
 17index = ["logs-endpoint.events.process*"]
 18language = "eql"
 19license = "Elastic License v2"
 20name = "File System Debugger Launched Inside a Container"
 21references = [
 22    "https://cyberark.wistia.com/medias/ygbzkzx93q?wvideo=ygbzkzx93q",
 23    "https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation#privileged",
 24]
 25risk_score = 47
 26rule_id = "35c029c3-090e-4a25-b613-0b8099970fc1"
 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 == "debugfs" and
 67process.command_line like~ "/dev/sd*" and not process.args == "-R"
 68'''
 69note = """## Triage and analysis
 70
 71> **Disclaimer**:
 72> 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.
 73
 74### Investigating File System Debugger Launched Inside a Container
 75
 76DebugFS is a Linux utility for direct file system manipulation, often used for debugging. In a privileged container, which has extensive access to the host, adversaries can exploit DebugFS to access sensitive host files, potentially leading to privilege escalation or container escape. The detection rule identifies suspicious DebugFS usage by monitoring process initiation with specific arguments in containers, flagging potential misuse.
 77
 78### Possible investigation steps
 79
 80- Review the alert details to confirm the process name is "debugfs" and check the specific arguments used, particularly looking for "/dev/sd*" to identify potential access to host file systems.
 81- Verify the container's security context to ensure it is indeed privileged, as this increases the risk of host-level access.
 82- Investigate the origin of the container image and deployment configuration to determine if the use of a privileged container was intentional or necessary.
 83- Check the user or service account that initiated the process to assess if it aligns with expected behavior or if it indicates potential unauthorized access.
 84- Examine recent logs and events from the container and host to identify any unusual activities or patterns that coincide with the alert.
 85- Assess the potential impact by identifying any sensitive files or directories that may have been accessed or modified by the debugfs process.
 86
 87### False positive analysis
 88
 89- Routine maintenance tasks using DebugFS in privileged containers can trigger alerts. To manage this, identify and document regular maintenance processes and create exceptions for these specific processes.
 90- Automated scripts or tools that utilize DebugFS for legitimate monitoring or debugging purposes may cause false positives. Review these scripts and whitelist them by excluding their specific process arguments or execution contexts.
 91- Development and testing environments often run privileged containers with DebugFS for debugging purposes. Establish a separate set of rules or exceptions for these environments to prevent unnecessary alerts.
 92- Backup or recovery operations that involve direct disk access might use DebugFS. Ensure these operations are well-documented and create exceptions based on their unique process signatures or execution schedules.
 93
 94### Response and remediation
 95
 96- Immediately isolate the affected container to prevent further access to sensitive host files. This can be done by stopping the container or removing its network access.
 97- Conduct a thorough review of the container's security context and capabilities to ensure it does not have unnecessary privileges. Adjust the container's configuration to remove privileged access if not required.
 98- Analyze the container's logs and process history to identify any unauthorized access or actions taken by the DebugFS utility. This will help determine the extent of the potential breach.
 99- If unauthorized access to host files is confirmed, perform a security assessment of the host system to identify any changes or breaches. This may include checking for new user accounts, modified files, or unexpected network connections.
100- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. Provide them with all relevant logs and findings.
101- Implement additional monitoring and alerting for similar activities across other containers and hosts to detect any recurrence of this threat.
102- Review and update container deployment policies to enforce the principle of least privilege, ensuring containers only have the necessary permissions to perform their intended functions."""
103
104[[rule.threat]]
105framework = "MITRE ATT&CK"
106
107[[rule.threat.technique]]
108id = "T1611"
109name = "Escape to Host"
110reference = "https://attack.mitre.org/techniques/T1611/"
111
112[rule.threat.tactic]
113id = "TA0004"
114name = "Privilege Escalation"
115reference = "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.

DebugFS is a Linux utility for direct file system manipulation, often used for debugging. In a privileged container, which has extensive access to the host, adversaries can exploit DebugFS to access sensitive host files, potentially leading to privilege escalation or container escape. The detection rule identifies suspicious DebugFS usage by monitoring process initiation with specific arguments in containers, flagging potential misuse.

  • Review the alert details to confirm the process name is "debugfs" and check the specific arguments used, particularly looking for "/dev/sd*" to identify potential access to host file systems.
  • Verify the container's security context to ensure it is indeed privileged, as this increases the risk of host-level access.
  • Investigate the origin of the container image and deployment configuration to determine if the use of a privileged container was intentional or necessary.
  • Check the user or service account that initiated the process to assess if it aligns with expected behavior or if it indicates potential unauthorized access.
  • Examine recent logs and events from the container and host to identify any unusual activities or patterns that coincide with the alert.
  • Assess the potential impact by identifying any sensitive files or directories that may have been accessed or modified by the debugfs process.
  • Routine maintenance tasks using DebugFS in privileged containers can trigger alerts. To manage this, identify and document regular maintenance processes and create exceptions for these specific processes.
  • Automated scripts or tools that utilize DebugFS for legitimate monitoring or debugging purposes may cause false positives. Review these scripts and whitelist them by excluding their specific process arguments or execution contexts.
  • Development and testing environments often run privileged containers with DebugFS for debugging purposes. Establish a separate set of rules or exceptions for these environments to prevent unnecessary alerts.
  • Backup or recovery operations that involve direct disk access might use DebugFS. Ensure these operations are well-documented and create exceptions based on their unique process signatures or execution schedules.
  • Immediately isolate the affected container to prevent further access to sensitive host files. This can be done by stopping the container or removing its network access.
  • Conduct a thorough review of the container's security context and capabilities to ensure it does not have unnecessary privileges. Adjust the container's configuration to remove privileged access if not required.
  • Analyze the container's logs and process history to identify any unauthorized access or actions taken by the DebugFS utility. This will help determine the extent of the potential breach.
  • If unauthorized access to host files is confirmed, perform a security assessment of the host system to identify any changes or breaches. This may include checking for new user accounts, modified files, or unexpected network connections.
  • Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. Provide them with all relevant logs and findings.
  • Implement additional monitoring and alerting for similar activities across other containers and hosts to detect any recurrence of this threat.
  • Review and update container deployment policies to enforce the principle of least privilege, ensuring containers only have the necessary permissions to perform their intended functions.

References

Related rules

to-top