Binary Executed from Shared Memory Directory

  1[metadata]
  2creation_date = "2022/05/10"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/02/04"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies the execution of a binary by root in Linux shared memory directories: (/dev/shm/, /run/shm/, /var/run/,
 11/var/lock/). This activity is to be considered highly abnormal and should be investigated. Threat actors have placed
 12executables used for persistence on high-uptime servers in these directories as system backdoors.
 13"""
 14false_positives = [
 15    """
 16    Directories /dev/shm and /run/shm are temporary file storage directories in Linux. They are intended to appear as a
 17    mounted file system, but uses virtual memory instead of a persistent storage device and thus are used for mounting
 18    file systems in legitimate purposes.
 19    """,
 20]
 21from = "now-9m"
 22index = ["endgame-*", "logs-endpoint.events.process*"]
 23language = "eql"
 24license = "Elastic License v2"
 25name = "Binary Executed from Shared Memory Directory"
 26references = [
 27    "https://linuxsecurity.com/features/fileless-malware-on-linux",
 28    "https://twitter.com/GossiTheDog/status/1522964028284411907",
 29    "https://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor",
 30]
 31risk_score = 73
 32rule_id = "3f3f9fe2-d095-11ec-95dc-f661ea17fbce"
 33setup = """## Setup
 34
 35This rule requires data coming in from Elastic Defend.
 36
 37### Elastic Defend Integration Setup
 38Elastic 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.
 39
 40#### Prerequisite Requirements:
 41- Fleet is required for Elastic Defend.
 42- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 43
 44#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 45- Go to the Kibana home page and click "Add integrations".
 46- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 47- Click "Add Elastic Defend".
 48- Configure the integration name and optionally add a description.
 49- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 50- 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).
 51- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 52- 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.
 53For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 54- Click "Save and Continue".
 55- 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.
 56For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 57"""
 58severity = "high"
 59tags = [
 60    "Domain: Endpoint",
 61    "OS: Linux",
 62    "Use Case: Threat Detection",
 63    "Tactic: Execution",
 64    "Threat: BPFDoor",
 65    "Data Source: Elastic Endgame",
 66    "Data Source: Elastic Defend",
 67    "Resources: Investigation Guide",
 68]
 69timestamp_override = "event.ingested"
 70type = "eql"
 71
 72query = '''
 73process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
 74user.id == "0" and process.executable : ("/dev/shm/*", "/run/shm/*", "/var/run/*", "/var/lock/*") and
 75not process.executable : ("/var/run/docker/*", "/var/run/utsns/*", "/var/run/s6/*", "/var/run/cloudera-scm-agent/*",
 76"/var/run/argo/argoexec") and not process.parent.command_line : "/usr/bin/runc init"
 77'''
 78note = """## Triage and analysis
 79
 80> **Disclaimer**:
 81> 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.
 82
 83### Investigating Binary Executed from Shared Memory Directory
 84
 85Shared memory directories in Linux, such as /dev/shm and /run/shm, are designed for efficient inter-process communication. However, adversaries exploit these directories to execute binaries stealthily, often as root, bypassing traditional security measures. The detection rule identifies such anomalies by monitoring for root-executed binaries in these directories, excluding known legitimate processes, thus flagging potential backdoor activities.
 86
 87### Possible investigation steps
 88
 89- Review the process executable path to confirm it resides in a shared memory directory such as /dev/shm, /run/shm, /var/run, or /var/lock, and verify it is not part of the known exclusions like /var/run/docker or /var/run/utsns.
 90- Investigate the parent process of the suspicious executable to understand the context of its execution, focusing on the command line used, especially if it does not match the exclusion pattern /usr/bin/runc init.
 91- Check the process's creation time and correlate it with any other suspicious activities or alerts around the same timeframe to identify potential patterns or related incidents.
 92- Analyze the binary file in question for any known malicious signatures or unusual characteristics using tools like file integrity checkers or antivirus solutions.
 93- Review system logs and audit logs for any unauthorized access or privilege escalation attempts that might have led to the execution of the binary as root.
 94- Investigate the user account activity associated with user.id "0" to ensure there are no signs of compromise or misuse of root privileges.
 95- If possible, isolate the affected system to prevent further potential malicious activity while the investigation is ongoing.
 96
 97### False positive analysis
 98
 99- Docker-related processes can trigger false positives when binaries are executed from shared memory directories. To mitigate this, exclude paths like /var/run/docker/* from the detection rule.
100- Processes related to container orchestration tools such as Kubernetes might also cause false positives. Exclude paths like /var/run/utsns/* and /var/run/s6/* to prevent these.
101- Cloudera services may execute binaries from shared memory directories as part of their normal operations. Exclude /var/run/cloudera-scm-agent/* to avoid false alerts.
102- Argo workflows might execute binaries in these directories. Exclude /var/run/argo/argoexec to reduce false positives.
103- Legitimate use of /usr/bin/runc init as a parent process can be excluded to prevent unnecessary alerts.
104
105### Response and remediation
106
107- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the threat actor.
108- Terminate any suspicious processes running from the shared memory directories (/dev/shm, /run/shm, /var/run, /var/lock) to halt potential malicious activity.
109- Conduct a thorough review of the system's process tree and logs to identify any additional malicious binaries or scripts that may have been executed or are scheduled to run.
110- Remove any unauthorized binaries or scripts found in the shared memory directories and other critical system paths to eliminate persistence mechanisms.
111- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through manual remediation.
112- Implement enhanced monitoring and alerting for any future execution of binaries from shared memory directories, ensuring that legitimate processes are whitelisted appropriately.
113- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
114
115
116[[rule.threat]]
117framework = "MITRE ATT&CK"
118[[rule.threat.technique]]
119id = "T1059"
120name = "Command and Scripting Interpreter"
121reference = "https://attack.mitre.org/techniques/T1059/"
122
123
124[rule.threat.tactic]
125id = "TA0002"
126name = "Execution"
127reference = "https://attack.mitre.org/tactics/TA0002/"