Potential Hidden Process via Mount Hidepid

Identifies the execution of mount process with hidepid parameter, which can make processes invisible to other users from the system. Adversaries using Linux kernel version 3.2+ (or RHEL/CentOS v6.5+ above) can hide the process from other users. When hidepid=2 option is executed to mount the /proc filesystem, only the root user can see all processes and the logged-in user can only see their own process. This provides a defense evasion mechanism for the adversaries to hide their process executions from all other commands such as ps, top, pgrep and more. With the Linux kernel hardening hidepid option all the user has to do is remount the /proc filesystem with the option, which can now be monitored and detected.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2023/04/11"
  3integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
  4maturity = "production"
  5min_stack_version = "8.13.0"
  6min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
  7updated_date = "2025/01/15"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Identifies the execution of mount process with hidepid parameter, which can make processes invisible to other users from
 13the system. Adversaries using Linux kernel version 3.2+ (or RHEL/CentOS v6.5+ above) can hide the process from other
 14users. When hidepid=2 option is executed to mount the /proc filesystem, only the root user can see all processes and the
 15logged-in user can only see their own process. This provides a defense evasion mechanism for the adversaries to hide
 16their process executions from all other commands such as ps, top, pgrep and more. With the Linux kernel hardening
 17hidepid option all the user has to do is remount the /proc filesystem with the option, which can now be monitored and
 18detected.
 19"""
 20from = "now-9m"
 21index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-sentinel_one_cloud_funnel.*"]
 22language = "eql"
 23license = "Elastic License v2"
 24name = "Potential Hidden Process via Mount Hidepid"
 25references = ["https://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/"]
 26risk_score = 47
 27rule_id = "dc71c186-9fe4-4437-a4d0-85ebb32b8204"
 28setup = """## Setup
 29
 30This rule requires data coming in from Elastic Defend.
 31
 32### Elastic Defend Integration Setup
 33Elastic 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.
 34
 35#### Prerequisite Requirements:
 36- Fleet is required for Elastic Defend.
 37- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 38
 39#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 40- Go to the Kibana home page and click "Add integrations".
 41- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 42- Click "Add Elastic Defend".
 43- Configure the integration name and optionally add a description.
 44- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 45- 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).
 46- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 47- 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.
 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: Endpoint",
 56    "OS: Linux",
 57    "Use Case: Threat Detection",
 58    "Tactic: Defense Evasion",
 59    "Data Source: Elastic Endgame",
 60    "Data Source: Elastic Defend",
 61    "Data Source: Auditd Manager",
 62    "Data Source: SentinelOne",
 63    "Resources: Investigation Guide",
 64]
 65timestamp_override = "event.ingested"
 66type = "eql"
 67query = '''
 68process where host.os.type == "linux" and event.type == "start" and
 69  event.action in ("exec", "exec_event", "start", "executed", "process_started") and
 70  process.name == "mount" and process.args == "/proc" and process.args == "-o" and process.args : "*hidepid=2*" and
 71  not process.parent.command_line like "/opt/cloudlinux/*"
 72'''
 73note = """## Triage and analysis
 74
 75> **Disclaimer**:
 76> 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.
 77
 78### Investigating Potential Hidden Process via Mount Hidepid
 79
 80The 'hidepid' mount option in Linux allows users to restrict visibility of process information in the /proc filesystem, enhancing privacy by limiting process visibility to the owner. Adversaries exploit this by remounting /proc with 'hidepid=2', concealing their processes from non-root users and evading detection tools like ps or top. The detection rule identifies such activity by monitoring for the execution of the mount command with specific arguments, flagging potential misuse for further investigation.
 81
 82### Possible investigation steps
 83
 84- Review the alert details to confirm the presence of the 'mount' process execution with arguments indicating '/proc' and 'hidepid=2'.
 85- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential adversary.
 86- Investigate the parent process of the 'mount' command to understand the context and origin of the execution, ensuring it is not part of a known or legitimate administrative script.
 87- Examine recent login activity and user sessions on the host to identify any unauthorized access or suspicious behavior around the time of the alert.
 88- Analyze other processes running on the system to identify any hidden or suspicious activities that might be related to the use of 'hidepid=2'.
 89- Review system logs and audit logs for any additional indicators of compromise or related suspicious activities that coincide with the alert.
 90
 91### False positive analysis
 92
 93- System administrators or automated scripts may remount /proc with hidepid=2 for legitimate privacy or security reasons. To handle this, create exceptions for known administrative scripts or users by excluding their specific command lines or user IDs.
 94- Some security tools or monitoring solutions might use hidepid=2 as part of their normal operation to enhance system security. Identify these tools and exclude their processes from triggering alerts by adding them to an allowlist.
 95- Cloud environments or containerized applications might use hidepid=2 to isolate processes for multi-tenant security. Review the environment's standard operating procedures and exclude these known behaviors from detection.
 96- Regular system updates or maintenance scripts might temporarily use hidepid=2. Document these occurrences and adjust the detection rule to ignore these specific maintenance windows or scripts.
 97- If using a specific Linux distribution that employs hidepid=2 by default for certain operations, verify these defaults and configure the detection rule to exclude them.
 98
 99### Response and remediation
100
101- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
102- Use root privileges to remount the /proc filesystem without the 'hidepid=2' option to restore visibility of all processes.
103- Conduct a thorough review of running processes and system logs to identify any unauthorized or suspicious activities that may have been concealed.
104- Terminate any identified malicious processes and remove any associated files or scripts from the system.
105- Change all system and user passwords to prevent unauthorized access, especially if credential theft is suspected.
106- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
107- Implement enhanced monitoring and alerting for future attempts to use the 'hidepid' option, ensuring rapid detection and response."""
108
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111
112[[rule.threat.technique]]
113id = "T1564"
114name = "Hide Artifacts"
115reference = "https://attack.mitre.org/techniques/T1564/"
116
117[rule.threat.tactic]
118id = "TA0005"
119name = "Defense Evasion"
120reference = "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 Potential Hidden Process via Mount Hidepid

The 'hidepid' mount option in Linux allows users to restrict visibility of process information in the /proc filesystem, enhancing privacy by limiting process visibility to the owner. Adversaries exploit this by remounting /proc with 'hidepid=2', concealing their processes from non-root users and evading detection tools like ps or top. The detection rule identifies such activity by monitoring for the execution of the mount command with specific arguments, flagging potential misuse for further investigation.

Possible investigation steps

  • Review the alert details to confirm the presence of the 'mount' process execution with arguments indicating '/proc' and 'hidepid=2'.
  • Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential adversary.
  • Investigate the parent process of the 'mount' command to understand the context and origin of the execution, ensuring it is not part of a known or legitimate administrative script.
  • Examine recent login activity and user sessions on the host to identify any unauthorized access or suspicious behavior around the time of the alert.
  • Analyze other processes running on the system to identify any hidden or suspicious activities that might be related to the use of 'hidepid=2'.
  • Review system logs and audit logs for any additional indicators of compromise or related suspicious activities that coincide with the alert.

False positive analysis

  • System administrators or automated scripts may remount /proc with hidepid=2 for legitimate privacy or security reasons. To handle this, create exceptions for known administrative scripts or users by excluding their specific command lines or user IDs.
  • Some security tools or monitoring solutions might use hidepid=2 as part of their normal operation to enhance system security. Identify these tools and exclude their processes from triggering alerts by adding them to an allowlist.
  • Cloud environments or containerized applications might use hidepid=2 to isolate processes for multi-tenant security. Review the environment's standard operating procedures and exclude these known behaviors from detection.
  • Regular system updates or maintenance scripts might temporarily use hidepid=2. Document these occurrences and adjust the detection rule to ignore these specific maintenance windows or scripts.
  • If using a specific Linux distribution that employs hidepid=2 by default for certain operations, verify these defaults and configure the detection rule to exclude them.

Response and remediation

  • Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
  • Use root privileges to remount the /proc filesystem without the 'hidepid=2' option to restore visibility of all processes.
  • Conduct a thorough review of running processes and system logs to identify any unauthorized or suspicious activities that may have been concealed.
  • Terminate any identified malicious processes and remove any associated files or scripts from the system.
  • Change all system and user passwords to prevent unauthorized access, especially if credential theft is suspected.
  • Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
  • Implement enhanced monitoring and alerting for future attempts to use the 'hidepid' option, ensuring rapid detection and response.

References

Related rules

to-top