Potential CVE-2025-41244 vmtoolsd LPE Exploitation Attempt

  1[metadata]
  2creation_date = "2025/09/30"
  3integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"]
  4maturity = "production"
  5updated_date = "2025/09/30"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule looks for processes that behave like an attacker trying to exploit a known vulnerability in VMware tools (CVE-2025-41244).
 11The vulnerable behavior involves the VMware tools service or its discovery scripts executing other programs to probe their version
 12strings. An attacker can place a malicious program in a writable location (for example /tmp) and have the tools execute it with
 13elevated privileges, resulting in local privilege escalation. The rule flags launches where vmtoolsd or the service discovery
 14scripts start other child processes.
 15"""
 16from = "now-9m"
 17index = [
 18    "logs-endpoint.events.process*",
 19    "logs-sentinel_one_cloud_funnel.*",
 20    "endgame-*",
 21    "auditbeat-*",
 22    "logs-auditd_manager.auditd-*",
 23    "logs-crowdstrike.fdr*",
 24]
 25language = "eql"
 26license = "Elastic License v2"
 27name = "Potential CVE-2025-41244 vmtoolsd LPE Exploitation Attempt"
 28note = """
 29## Triage and analysis
 30
 31> **Disclaimer**:
 32> 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.
 33
 34### Investigating Potential CVE-2025-41244 vmtoolsd LPE Exploitation Attempt
 35
 36This rule flags child processes started by vmtoolsd or its version-checking script on Linux, behavior central to CVE-2025-41244 where the service executes external utilities to read version strings. It matters because a local user can coerce these invocations to run arbitrary code with elevated privileges. A typical pattern is dropping a counterfeit lsb_release or rpm in /tmp, modifying PATH, and triggering vmtoolsd/get-versions.sh so the rogue binary executes and spawns a privileged shell or installer.
 37
 38### Possible investigation steps
 39
 40- Examine the executed child binary’s full path and location, flagging any binaries in writable directories (e.g., /tmp, /var/tmp, /dev/shm, or user home) or masquerading as version utilities (lsb_release, rpm, dpkg, dnf, pacman), and record owner, size, hash, and recent timestamps.
 41- Pull the parent’s and child’s command-line and environment to confirm PATH ordering and whether writable paths precede system binaries, capturing any evidence that get-versions.sh or vmtoolsd invoked a non-standard utility.
 42- Pivot to subsequent activity from the child process to see if it spawns an interactive shell, escalates EUID to root, touches /etc/sudoers or /etc/passwd, writes to privileged directories, or opens outbound connections.
 43- Verify integrity of open-vm-tools components by comparing hashes and file sizes of vmtoolsd and serviceDiscovery scripts with vendor packages (rpm -V or dpkg --verify) and checking for unexpected edits, symlinks, or PATH-hijackable calls within the scripts.
 44- Correlate filesystem creation events and terminal histories to identify the user who dropped or modified the suspicious binary and whether it appeared shortly before the alert, then assess other hosts for the same filename or hash to determine spread.
 45
 46### False positive analysis
 47
 48- Routine vmtoolsd service discovery via get-versions.sh during VM boot or periodic guest info refresh can legitimately spawn version/package utilities from standard system paths with a default PATH and no execution from writable directories, yet still match this rule.
 49- Administrator troubleshooting or post-update validation of open-vm-tools—manually running get-versions.sh or restarting vmtoolsd—can cause a shell to launch the script and start expected system utilities in trusted locations, producing a benign alert.
 50
 51### Response and remediation
 52
 53- Isolate the affected VM, stop the vmtoolsd service, terminate its spawned children (e.g., lsb_release, rpm, dpkg, or /bin/sh launched via open-vm-tools/serviceDiscovery/scripts/get-versions.sh), and temporarily remove execute permissions from the serviceDiscovery scripts to halt exploitation.
 54- Quarantine and remove any counterfeit or hijacked utilities and symlinks in writable locations (/tmp, /var/tmp, /dev/shm, or user home) that were executed by vmtoolsd/get-versions.sh, capturing full paths, hashes, owners, and timestamps for evidence.
 55- Recover by reinstalling open-vm-tools from a trusted repository and verifying integrity of vmtoolsd and serviceDiscovery scripts (rpm -V or dpkg --verify), then restart vmtoolsd only after confirming PATH does not include writable directories and that the scripts call absolute binaries under /usr/bin.
 56- Escalate to full incident response if a vmtoolsd child executed from a writable path ran with EUID 0, spawned an interactive shell (/bin/sh or /bin/bash), or modified /etc/sudoers or /etc/passwd, and initiate credential rotation and a host-wide compromise assessment.
 57- Harden hosts by enforcing a safe PATH (e.g., /usr/sbin:/usr/bin:/sbin:/bin), removing writable directories from system and user environment files, mounting /tmp,/var/tmp,/dev/shm with noexec,nosuid,nodev, and applying AppArmor/SELinux policies to block vmtoolsd from executing binaries outside system directories.
 58- Prevent recurrence by deploying the vendor fix for CVE-2025-41244 across all Linux VMs, pinning or replacing the open-vm-tools serviceDiscovery scripts with versions that use absolute paths, and adding EDR allowlists/blocks so vmtoolsd cannot launch binaries from writable paths.
 59"""
 60references = ["https://blog.nviso.eu/2025/09/29/you-name-it-vmware-elevates-it-cve-2025-41244/"]
 61risk_score = 47
 62rule_id = "c5da2519-160c-4cc9-bf69-b0223e99d0db"
 63setup = """## Setup
 64
 65This rule requires data coming in from Elastic Defend.
 66
 67### Elastic Defend Integration Setup
 68Elastic 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.
 69
 70#### Prerequisite Requirements:
 71- Fleet is required for Elastic Defend.
 72- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 73
 74#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 75- Go to the Kibana home page and click "Add integrations".
 76- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 77- Click "Add Elastic Defend".
 78- Configure the integration name and optionally add a description.
 79- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 80- 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).
 81- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 82- 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.
 83For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 84- Click "Save and Continue".
 85- 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.
 86For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 87"""
 88severity = "medium"
 89tags = [
 90    "Domain: Endpoint",
 91    "OS: Linux",
 92    "Use Case: Threat Detection",
 93    "Tactic: Privilege Escalation",
 94    "Data Source: Elastic Defend",
 95    "Data Source: SentinelOne",
 96    "Data Source: Crowdstrike",
 97    "Data Source: Elastic Endgame",
 98    "Data Source: Auditd Manager",
 99    "Use Case: Vulnerability",
100    "Resources: Investigation Guide",
101]
102timestamp_override = "event.ingested"
103type = "eql"
104query = '''
105process where host.os.type == "linux" and event.type == "start" and
106event.action in ("exec", "exec_event", "start", "executed", "process_started", "ProcessRollup2") and
107(
108  (
109    process.parent.name == "vmtoolsd"
110  ) or
111  (
112    process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
113    ?process.parent.args like ("/*/open-vm-tools/serviceDiscovery/scripts/get-versions.sh")
114  )
115)
116'''
117
118[[rule.threat]]
119framework = "MITRE ATT&CK"
120
121[[rule.threat.technique]]
122id = "T1068"
123name = "Exploitation for Privilege Escalation"
124reference = "https://attack.mitre.org/techniques/T1068/"
125
126[rule.threat.tactic]
127id = "TA0004"
128name = "Privilege Escalation"
129reference = "https://attack.mitre.org/tactics/TA0004/"