Suspicious Path Mounted
This rule detects suspicious paths mounted on Linux systems. The mount command is used to attach filesystems to the system, and attackers may use it to mount malicious filesystems or directories for data exfiltration or persistence.
Elastic rule (View on GitHub)
1
2[metadata]
3creation_date = "2025/04/25"
4integration = ["endpoint"]
5maturity = "production"
6updated_date = "2025/07/07"
7
8[rule]
9author = ["Elastic"]
10description = """
11This rule detects suspicious paths mounted on Linux systems. The mount command is used to attach filesystems to
12the system, and attackers may use it to mount malicious filesystems or directories for data exfiltration or
13persistence.
14"""
15from = "now-9m"
16index = ["logs-endpoint.events.process*"]
17language = "eql"
18license = "Elastic License v2"
19name = "Suspicious Path Mounted"
20note = """ ## Triage and analysis
21
22> **Disclaimer**:
23> 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.
24
25### Investigating Suspicious Path Mounted
26
27In Linux environments, the mount command integrates filesystems, enabling access to storage devices. Adversaries exploit this by mounting malicious filesystems in sensitive directories like /tmp or /dev/shm to exfiltrate data or maintain persistence. The detection rule identifies such activities by monitoring the execution of the mount command in unusual paths, excluding legitimate parent processes, thus highlighting potential threats.
28
29### Possible investigation steps
30
31- Review the process details to confirm the execution of the mount command, focusing on the process.name and process.args fields to identify the specific path being mounted.
32- Examine the process.parent.executable field to determine the parent process that initiated the mount command, ensuring it is not a known legitimate process.
33- Investigate the user account associated with the process to determine if it is a privileged account or if there are any signs of compromise.
34- Check for any recent changes or anomalies in the mounted directories, such as unexpected files or modifications, to assess potential data exfiltration or persistence activities.
35- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack.
36
37### False positive analysis
38
39- System maintenance scripts may trigger the rule if they mount filesystems in monitored paths. Review and whitelist these scripts by adding their parent executable paths to the exclusion list.
40- Backup processes that temporarily mount directories for data transfer can be mistaken for suspicious activity. Identify these processes and exclude their parent executables to prevent false alerts.
41- Software installations or updates that require mounting filesystems in user directories might be flagged. Verify these activities and add the responsible parent executables to the exclusion criteria.
42- Development tools that use temporary mounts for testing purposes can generate false positives. Recognize these tools and exclude their parent executables to reduce noise.
43- Custom administrative scripts that perform legitimate mounting operations should be reviewed and, if deemed safe, their parent executables should be added to the exclusion list.
44
45### Response and remediation
46
47- Immediately isolate the affected system to prevent further data exfiltration or persistence by disconnecting it from the network.
48- Terminate any suspicious mount processes identified in the alert to halt potential malicious activity.
49- Conduct a thorough review of mounted filesystems and directories to identify and unmount any unauthorized or suspicious mounts.
50- Restore any compromised files or directories from backups, ensuring they are clean and free from malicious modifications.
51- Implement stricter access controls and permissions on sensitive directories like /tmp, /var/tmp, /dev/shm, /home, and /root to prevent unauthorized mounting.
52- Escalate the incident to the security operations team for further investigation and to assess the scope of the threat, including potential lateral movement or additional compromised systems.
53- Enhance monitoring and detection capabilities by configuring alerts for unusual mount activities and integrating threat intelligence feeds to identify similar tactics used by adversaries.
54"""
55risk_score = 21
56rule_id = "68e90a9b-0eab-425e-be3b-902b0cd1fe9c"
57setup = """## Setup
58
59This rule requires data coming in from Elastic Defend.
60
61### Elastic Defend Integration Setup
62Elastic 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.
63
64#### Prerequisite Requirements:
65- Fleet is required for Elastic Defend.
66- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
67
68#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
69- Go to the Kibana home page and click "Add integrations".
70- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
71- Click "Add Elastic Defend".
72- Configure the integration name and optionally add a description.
73- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
74- 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).
75- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
76- 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.
77For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
78- Click "Save and Continue".
79- 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.
80For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
81"""
82severity = "low"
83tags = [
84 "Domain: Endpoint",
85 "OS: Linux",
86 "Use Case: Threat Detection",
87 "Tactic: Defense Evasion",
88 "Data Source: Elastic Defend",
89 "Resources: Investigation Guide",
90]
91timestamp_override = "event.ingested"
92type = "eql"
93query = '''
94process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "mount" and
95process.args like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/home/*", "/root/*", "/mount") and process.parent.executable != null and
96not (
97 process.parent.executable like ("/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*", "/usr/libexec/*") or
98 process.parent.name == "snapd"
99)
100'''
101
102[[rule.threat]]
103framework = "MITRE ATT&CK"
104
105[[rule.threat.technique]]
106id = "T1564"
107name = "Hide Artifacts"
108reference = "https://attack.mitre.org/techniques/T1564/"
109
110[rule.threat.tactic]
111id = "TA0005"
112name = "Defense Evasion"
113reference = "https://attack.mitre.org/tactics/TA0005/"
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 Suspicious Path Mounted
In Linux environments, the mount command integrates filesystems, enabling access to storage devices. Adversaries exploit this by mounting malicious filesystems in sensitive directories like /tmp or /dev/shm to exfiltrate data or maintain persistence. The detection rule identifies such activities by monitoring the execution of the mount command in unusual paths, excluding legitimate parent processes, thus highlighting potential threats.
Possible investigation steps
- Review the process details to confirm the execution of the mount command, focusing on the process.name and process.args fields to identify the specific path being mounted.
- Examine the process.parent.executable field to determine the parent process that initiated the mount command, ensuring it is not a known legitimate process.
- Investigate the user account associated with the process to determine if it is a privileged account or if there are any signs of compromise.
- Check for any recent changes or anomalies in the mounted directories, such as unexpected files or modifications, to assess potential data exfiltration or persistence activities.
- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack.
False positive analysis
- System maintenance scripts may trigger the rule if they mount filesystems in monitored paths. Review and whitelist these scripts by adding their parent executable paths to the exclusion list.
- Backup processes that temporarily mount directories for data transfer can be mistaken for suspicious activity. Identify these processes and exclude their parent executables to prevent false alerts.
- Software installations or updates that require mounting filesystems in user directories might be flagged. Verify these activities and add the responsible parent executables to the exclusion criteria.
- Development tools that use temporary mounts for testing purposes can generate false positives. Recognize these tools and exclude their parent executables to reduce noise.
- Custom administrative scripts that perform legitimate mounting operations should be reviewed and, if deemed safe, their parent executables should be added to the exclusion list.
Response and remediation
- Immediately isolate the affected system to prevent further data exfiltration or persistence by disconnecting it from the network.
- Terminate any suspicious mount processes identified in the alert to halt potential malicious activity.
- Conduct a thorough review of mounted filesystems and directories to identify and unmount any unauthorized or suspicious mounts.
- Restore any compromised files or directories from backups, ensuring they are clean and free from malicious modifications.
- Implement stricter access controls and permissions on sensitive directories like /tmp, /var/tmp, /dev/shm, /home, and /root to prevent unauthorized mounting.
- Escalate the incident to the security operations team for further investigation and to assess the scope of the threat, including potential lateral movement or additional compromised systems.
- Enhance monitoring and detection capabilities by configuring alerts for unusual mount activities and integrating threat intelligence feeds to identify similar tactics used by adversaries.
Related rules
- Kubeconfig File Creation or Modification
- Potential Hex Payload Execution via Command-Line
- Potential Kubectl Masquerading via Unexpected Process
- Suspicious Kernel Feature Activity
- System Binary Symlink to Suspicious Location