Manual Mount Discovery via /etc/exports or /etc/fstab

This rule detects manual mount discovery via the /etc/exports or /etc/fstab file on Linux systems. These files are used by NFS (Network File System) to define which directories are shared with remote hosts. Attackers may access this file to gather information about shared directories and potential targets for further exploitation.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/04/25"
  3integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
  4maturity = "production"
  5updated_date = "2025/07/07"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects manual mount discovery via the /etc/exports or /etc/fstab file on Linux systems. These files are used
 11by NFS (Network File System) to define which directories are shared with remote hosts. Attackers may access this
 12file to gather information about shared directories and potential targets for further exploitation.
 13"""
 14from = "now-9m"
 15index = [
 16    "endgame-*",
 17    "logs-crowdstrike.fdr*",
 18    "logs-endpoint.events.process*",
 19    "logs-sentinel_one_cloud_funnel.*",
 20]
 21language = "eql"
 22license = "Elastic License v2"
 23name = "Manual Mount Discovery via /etc/exports or /etc/fstab"
 24note = """ ## Triage and analysis
 25
 26> **Disclaimer**:
 27> 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.
 28
 29### Investigating Manual Mount Discovery via /etc/exports or /etc/fstab
 30
 31In Linux environments, the `/etc/exports` and `/etc/fstab` files are crucial for managing shared directories and mounting filesystems, respectively. Adversaries may exploit these files to identify shared resources and potential targets for lateral movement. The detection rule identifies suspicious processes accessing these files, using common command-line utilities, to flag potential reconnaissance activities by attackers.
 32
 33### Possible investigation steps
 34
 35- Review the process details to identify the user account associated with the suspicious activity, focusing on the process.name and process.command_line fields.
 36- Examine the command line arguments in the process.command_line field to determine the specific actions taken and whether they align with legitimate administrative tasks.
 37- Check the process start time and correlate it with other system activities to identify any unusual patterns or sequences of events.
 38- Investigate the source IP address or hostname if the process was initiated remotely, to assess whether it is a known or trusted entity.
 39- Look for any other related alerts or logs around the same timeframe to identify potential lateral movement or further reconnaissance activities.
 40- Verify if the accessed directories in /etc/exports or /etc/fstab are critical or sensitive, and assess the potential impact of unauthorized access.
 41
 42### False positive analysis
 43
 44- Routine system administration tasks may trigger alerts when administrators use command-line utilities to view or edit /etc/exports or /etc/fstab. To mitigate this, consider excluding processes executed by known administrator accounts or during scheduled maintenance windows.
 45- Automated scripts for system monitoring or configuration management might access these files regularly. Identify and whitelist these scripts by their process names or command-line patterns to reduce false positives.
 46- Backup operations often involve reading configuration files like /etc/exports or /etc/fstab. Exclude processes associated with backup software or services to prevent unnecessary alerts.
 47- Security tools or compliance checks may scan these files as part of their regular operations. Review and whitelist these tools based on their process names or command-line arguments to avoid false positives.
 48- Developers or testers might access these files in development environments for testing purposes. Consider excluding processes from development servers or specific user accounts associated with testing activities.
 49
 50### Response and remediation
 51
 52- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker.
 53- Conduct a thorough review of the `/etc/exports` and `/etc/fstab` files on the affected system to identify any unauthorized changes or suspicious entries.
 54- Revoke any unauthorized access to shared directories identified in the `/etc/exports` file and ensure that only trusted hosts have access.
 55- Reset credentials and review access permissions for users and services that have access to the affected system to prevent further unauthorized access.
 56- Monitor network traffic for any unusual activity originating from the affected system, focusing on connections to external IPs or unexpected internal hosts.
 57- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
 58- Implement enhanced monitoring and logging for access to critical configuration files like `/etc/exports` and `/etc/fstab` to detect similar threats in the future.
 59"""
 60risk_score = 21
 61rule_id = "bd18f4a3-c4c6-43b9-a1e4-b05e09998110"
 62setup = """## Setup
 63
 64This rule requires data coming in from Elastic Defend.
 65
 66### Elastic Defend Integration Setup
 67Elastic 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.
 68
 69#### Prerequisite Requirements:
 70- Fleet is required for Elastic Defend.
 71- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 72
 73#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 74- Go to the Kibana home page and click "Add integrations".
 75- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 76- Click "Add Elastic Defend".
 77- Configure the integration name and optionally add a description.
 78- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 79- 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).
 80- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 81- 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.
 82For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 83- Click "Save and Continue".
 84- 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.
 85For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 86"""
 87severity = "low"
 88tags = [
 89    "Domain: Endpoint",
 90    "OS: Linux",
 91    "Use Case: Threat Detection",
 92    "Tactic: Discovery",
 93    "Data Source: Elastic Defend",
 94    "Data Source: Elastic Endgame",
 95    "Data Source: Crowdstrike",
 96    "Data Source: SentinelOne",
 97    "Resources: Investigation Guide",
 98]
 99timestamp_override = "event.ingested"
100type = "eql"
101query = '''
102process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
103process.name in ("cat", "grep", "tail", "less", "more", "egrep", "fgrep") and process.command_line like ("/etc/exports", "/etc/fstab")
104'''
105
106[[rule.threat]]
107framework = "MITRE ATT&CK"
108
109[[rule.threat.technique]]
110id = "T1082"
111name = "System Information Discovery"
112reference = "https://attack.mitre.org/techniques/T1082/"
113
114[rule.threat.tactic]
115id = "TA0007"
116name = "Discovery"
117reference = "https://attack.mitre.org/tactics/TA0007/"

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 Manual Mount Discovery via /etc/exports or /etc/fstab

In Linux environments, the /etc/exports and /etc/fstab files are crucial for managing shared directories and mounting filesystems, respectively. Adversaries may exploit these files to identify shared resources and potential targets for lateral movement. The detection rule identifies suspicious processes accessing these files, using common command-line utilities, to flag potential reconnaissance activities by attackers.

Possible investigation steps

  • Review the process details to identify the user account associated with the suspicious activity, focusing on the process.name and process.command_line fields.
  • Examine the command line arguments in the process.command_line field to determine the specific actions taken and whether they align with legitimate administrative tasks.
  • Check the process start time and correlate it with other system activities to identify any unusual patterns or sequences of events.
  • Investigate the source IP address or hostname if the process was initiated remotely, to assess whether it is a known or trusted entity.
  • Look for any other related alerts or logs around the same timeframe to identify potential lateral movement or further reconnaissance activities.
  • Verify if the accessed directories in /etc/exports or /etc/fstab are critical or sensitive, and assess the potential impact of unauthorized access.

False positive analysis

  • Routine system administration tasks may trigger alerts when administrators use command-line utilities to view or edit /etc/exports or /etc/fstab. To mitigate this, consider excluding processes executed by known administrator accounts or during scheduled maintenance windows.
  • Automated scripts for system monitoring or configuration management might access these files regularly. Identify and whitelist these scripts by their process names or command-line patterns to reduce false positives.
  • Backup operations often involve reading configuration files like /etc/exports or /etc/fstab. Exclude processes associated with backup software or services to prevent unnecessary alerts.
  • Security tools or compliance checks may scan these files as part of their regular operations. Review and whitelist these tools based on their process names or command-line arguments to avoid false positives.
  • Developers or testers might access these files in development environments for testing purposes. Consider excluding processes from development servers or specific user accounts associated with testing activities.

Response and remediation

  • Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker.
  • Conduct a thorough review of the /etc/exports and /etc/fstab files on the affected system to identify any unauthorized changes or suspicious entries.
  • Revoke any unauthorized access to shared directories identified in the /etc/exports file and ensure that only trusted hosts have access.
  • Reset credentials and review access permissions for users and services that have access to the affected system to prevent further unauthorized access.
  • Monitor network traffic for any unusual activity originating from the affected system, focusing on connections to external IPs or unexpected internal hosts.
  • Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
  • Implement enhanced monitoring and logging for access to critical configuration files like /etc/exports and /etc/fstab to detect similar threats in the future.

Related rules

to-top