Russian cybersecurity firm Solar attributes a nearly two-year intrusion inside a Russian healthcare organization to Partisan Zmiy, also tracked as Cyber Partisans, a Belarus-aligned hacktivist cluster active since at least 2020. The key defensive lesson is not geopolitical attribution. It is the reported tradecraft: the operators allegedly concealed an unauthorized access mechanism named Vasilek inside VMware Tools, the ubiquitous guest-agent stack present in large numbers of Windows and Linux virtual machines.
This is a high-severity defensive signal for healthcare, pharmaceutical, insurance, and any virtualization-heavy enterprise. A backdoor that lives beside, inside, or impersonates VMware Tools can blend into expected guest operations, survive casual triage, and inherit trust from administrators who treat vmtoolsd, VMwareToolboxCmd, VGAuth, or open-vm-tools as benign plumbing. The public summary does not provide a CVE, a patch, CISA KEV inclusion, or a proof of concept. Treat this as confirmed active intrusion tradecraft reported by a credible incident-response firm, not as a disclosed VMware vulnerability.
For healthcare defenders, the risk is amplified by long dwell time. Two years is enough to map clinical networks, identify imaging and laboratory systems, steal credentials, stage data near HL7/FHIR interfaces, and learn backup windows. If your organization runs VMware, assume guest-agent integrity is now an incident-response and threat-hunting priority.
Technical analysis: what is being abused
Affected platforms, based on the reported technique rather than a vendor advisory: VMware guest environments running VMware Tools on Windows, Linux distributions using open-vm-tools, and the ESXi/vCenter operational plane that administrators trust for guest management. The news item does not claim that VMware Tools itself is vulnerable. The defensive interpretation is narrower and more actionable: attackers are using the VMware Tools footprint as camouflage for persistence and access.
The likely defender-observable attack chain is:
- Initial access is obtained through credential theft, exposed remote access, third-party access, or a weakly monitored clinical/business segment.
- The actor lands on a virtualized workload and identifies VMware Tools as a trusted, always-present component.
- A backdoor or loader is placed where it can be mistaken for legitimate VMware tooling: near VMware Tools binaries, under VMware-named services/tasks, inside guest-initiated command execution channels, or as a VMware-looking executable outside the approved install directory.
- Persistence is established through a service, scheduled task, run key, systemd unit, cron entry, or modified startup script with a VMware-flavored name.
- Command-and-control is routed through low-and-slow guest egress, possibly piggybacking on management networks that are allowed broadly because vCenter, backup, EDR, patching, and clinical integrations all need connectivity.
- During long dwell, the actor harvests credentials and moves laterally to domain controllers, backup servers, EHR database hosts, medical device VLAN gateways, and file shares containing PHI.
The most important nuance: defenders should not open a change ticket titled patch VMware Tools CVE. There is no CVE in the source reporting. Open an incident hypothesis titled trusted guest-agent abuse. Your hunt is for tampering, impersonation, unexpected child processes, unsigned or mismatched binaries, abnormal service registration, and egress from processes that should not be talking like operators.
Exploitation status: confirmed active intrusion activity is reported by Solar; no public PoC, no CISA KEV entry, and no vendor patch are identified in the provided item. Treat as an active TTP against healthcare and virtualization infrastructure.
Detection and response
Prioritize behaviors that are specific enough to survive production: VMware Tools processes spawning shells, VMware-looking binaries outside the authorized path, unsigned or newly modified files in the tools directory, and services whose names imitate VMware but whose executable paths do not.
---
title: VMware Tools Process Spawning Shell or Script Interpreter
id: 6c8a5f2e-7d4b-4d7a-9c2f-1e5b8a0f3d21
status: experimental
description: Detects vmtoolsd, VMwareToolboxCmd, or VGAuth launching command shells, script engines, or LOLBins consistent with backdoor execution hidden behind trusted guest-agent processes.
references:
- https://attack.mitre.org/techniques/T1059/
- https://attack.mitre.org/techniques/T1218/
author: Security Arsenal
date: 2026/10/01
tags:
- attack.execution
- attack.defense_evasion
- attack.t1059
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith:
- '\vmtoolsd.exe'
- '\VMwareToolboxCmd.exe'
- '\VGAuthService.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\wmic.exe'
condition: selection_parent and selection_child
falsepositives:
- Rare administrative guest operations, application packaging, or troubleshooting executed through VMware guest operations
level: high
---
title: VMware-Named Binary Executing Outside Approved Tools Path
id: 2b7d9c14-8f61-4a0b-b8e3-9d0c6a7e5f44
status: experimental
description: Detects processes with VMware-like names executing from user-writable, temporary, or otherwise non-standard locations, a common impersonation pattern for hidden access mechanisms.
references:
- https://attack.mitre.org/techniques/T1036/
- https://attack.mitre.org/techniques/T1543/
author: Security Arsenal
date: 2026/10/01
tags:
- attack.defense_evasion
- attack.persistence
- attack.t1036.005
logsource:
category: process_creation
product: windows
detection:
selection_name:
Image|contains:
- 'vmware'
- 'vmtools'
- 'vgauth'
- 'toolboxcmd'
filter_approved:
Image|startswith:
- 'C:\Program Files\VMware\VMware Tools\'
- 'C:\Program Files (x86)\VMware\VMware Tools\'
- 'C:\Windows\System32\'
condition: selection_name and not filter_approved
falsepositives:
- Portable administrative utilities renamed by IT; validate against software inventory before tuning out
level: high
---
title: Linux Guest Shell Spawned by vmtoolsd or open-vm-tools Context
id: 91f0a7d6-3c52-4bfe-a0d1-7c6e2b8d9aa0
status: experimental
description: Detects shells or script interpreters spawned in the context of Linux guest tooling where vmtoolsd or open-vm-tools is expected to run quietly.
references:
- https://attack.mitre.org/techniques/T1059.004/
author: Security Arsenal
date: 2026/10/01
tags:
- attack.execution
- attack.t1059.004
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentImage|contains:
- 'vmtoolsd'
- 'open-vm-tools'
- 'vmware-tools'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/python'
- '/python3'
- '/perl'
- '/curl'
- '/wget'
condition: selection_parent and selection_child
falsepositives:
- Guest customization scripts and configuration management; restrict to unexpected hosts and maintenance windows
level: medium
let vmParents = dynamic(['vmtoolsd.exe','VMwareToolboxCmd.exe','VGAuthService.exe','vmtoolsd']);
let riskyChildren = dynamic(['cmd.exe','powershell.exe','pwsh.exe','wscript.exe','cscript.exe','mshta.exe','rundll32.exe','regsvr32.exe','wmic.exe','sh','bash','dash','python','python3','perl','curl','wget']);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName in~ (vmParents) or InitiatingProcessFolderPath has_any ('vmware tools','open-vm-tools','vmtoolsd')
| where FileName in~ (riskyChildren) or ProcessCommandLine has_any ('-enc','frombase64','downloadstring','invoke-expression','/c ','curl ','wget ','chmod +x')
| extend SuspiciousPath = iff(FolderPath has_any ('Program Files\\VMware\\VMware Tools','/usr/sbin','/usr/lib/open-vm-tools','/etc/vmware-tools'), 'approved-ish', 'review-path')
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, FolderPath, SHA256, ReportId, SuspiciousPath
| join kind=leftouter (
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName in~ (vmParents)
| summarize FirstNet=min(TimeGenerated), RemoteIPs=make_set(RemoteIP, 10), RemoteUrls=make_set(RemoteUrl, 10) by DeviceName, InitiatingProcessFileName
) on DeviceName, InitiatingProcessFileName
| summarize arg_min(TimeGenerated, *) by DeviceName, FileName, SHA256
| order by TimeGenerated desc
-- Hunt VMware Tools adjacent processes, suspicious lineage, and unexpected guest egress
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)vmtoolsd|vmwaretoolboxcmd|vgauth|vmware'
OR Exe =~ '(?i)vmware tools|open-vm-tools|vmware-tools'
OR CommandLine =~ '(?i)powershell|cmd.exe|/bin/sh|/bin/bash|curl|wget|base64|downloadstring'
# Read-only audit for VMware Tools integrity and impersonation on Windows guests.
# Run from an elevated prompt. Review output before taking containment action.
$toolsPath = Join-Path $env:ProgramFiles 'VMware/VMware Tools'
$report = Join-Path $env:TEMP ('vmware-tools-integrity-' + (Get-Date -Format 'yyyyMMdd-HHmmss') + '.csv')
# Collect unsigned, invalid, or recently modified files under the VMware Tools directory.
$files = Get-ChildItem -LiteralPath $toolsPath -Recurse -File -ErrorAction SilentlyContinue
$fileFindings = foreach ($f in $files) {
$sig = Get-AuthenticodeSignature -FilePath $f.FullName -ErrorAction SilentlyContinue
[pscustomobject]@{
Host = $env:COMPUTERNAME
Type = 'ToolsFile'
Path = $f.FullName
LastWriteTime = $f.LastWriteTime
SignatureStatus = $sig.Status
Signer = $sig.SignerCertificate.Subject
Sha256 = (Get-FileHash -Algorithm SHA256 -LiteralPath $f.FullName -ErrorAction SilentlyContinue).Hash
Flag = if ($sig.Status -ne 'Valid' -or $f.LastWriteTime -gt (Get-Date).AddDays(-45)) { 'REVIEW' } else { '' }
}
}
# Find VMware-named services whose binary path is outside the expected tools directory.
$serviceFindings = Get-CimInstance Win32_Service | Where-Object { $_.Name -match 'vmware|vmtools|vgauth' -or $_.DisplayName -match 'vmware|vmtools|vgauth' } | ForEach-Object {
$approved = $_.PathName -match 'Program Files.\VMware\VMware Tools|system32|SysWOW64'
[pscustomobject]@{
Host = $env:COMPUTERNAME
Type = 'Service'
Path = $_.Name
LastWriteTime = $null
SignatureStatus = $_.State
Signer = $_.PathName
Sha256 = $null
Flag = if (-not $approved) { 'REVIEW-PATH' } else { '' }
}
}
# Capture currently running VMware-named processes with command lines for lineage review.
$procFindings = Get-CimInstance Win32_Process | Where-Object { $_.Name -match 'vmware|vmtools|vgauth|toolboxcmd' -or $_.ExecutablePath -match 'VMware Tools' } | ForEach-Object {
[pscustomobject]@{
Host = $env:COMPUTERNAME
Type = 'Process'
Path = ($_.ProcessId.ToString() + ' ' + $_.Name)
LastWriteTime = $null
SignatureStatus = $_.ExecutablePath
Signer = $_.CommandLine
Sha256 = $null
Flag = if ($_.CommandLine -match 'powershell|cmd|rundll32|regsvr32|wscript|cscript|mshta|curl|wget') { 'REVIEW-CMDLINE' } else { '' }
}
}
$fileFindings + $serviceFindings + $procFindings | Export-Csv -NoTypeInformation -LiteralPath $report
Write-Output ('Wrote audit to ' + $report)
Response playbook for suspected Vasilek-style access
Contain without tipping off the operator until evidence is preserved. Isolate the affected guest at the distributed firewall or NSX segment rather than powering off immediately. Capture memory from the guest and, where operationally safe, snapshot the VM after isolation for forensic review. Acquire the VMware Tools directory, service registry hives, scheduled tasks, startup folders, WMI subscriptions, Linux systemd units, cron, init scripts, shell histories, vmtoolsd/open-vm-tools logs, EDR telemetry, vCenter events, and guest operations audit trails.
Scope outward from trust relationships. Review vCenter and ESXi administrative logons, guest operation invocations, backup console activity, service accounts with healthcare application rights, clinical integration engines, and any jump hosts that touch both IT and biomedical/device segments. Rotate credentials that were exposed on affected guests: local admins, service accounts, stored clinical interface credentials, backup credentials, and domain credentials if lsass or equivalent material may have been touched.
Do not simply delete the suspicious file and resume operations. If an access mechanism survived in guest tooling, assume redundancy. Rebuild affected guests from known-good templates, re-import VMware Tools only from vendor-trusted sources, and validate hashes/signatures before reconnection. For Linux, reinstall open-vm-tools from the distribution repository after root cause is understood and verify package ownership with rpm or dpkg. For Windows, compare file signatures and installation sources; treat recently changed VMware Tools binaries as compromised until proven otherwise.
Remediation and hardening
Because no CVE or vendor patch is identified in the reporting, remediation is architectural and operational. Start with a 30-day sprint.
First, establish a trusted baseline for VMware Tools across templates. Record approved versions, expected directories, signer subjects, service names, and normal parent-child behavior. Alert on drift rather than waiting for malware names. Enforce tamper protection in EDR, and restrict write access to VMware Tools directories to installer, updater, and approved configuration-management identities.
Second, constrain execution. Use WDAC or AppLocker on Windows guests to allow only signed VMware/Broadcom components from approved paths, and block script interpreters from launching as children of vmtoolsd, VMwareToolboxCmd, or VGAuth unless an approved change window is active. On Linux, use SELinux or AppArmor profiles where mature, auditd rules around vmtoolsd and open-vm-tools, and configuration management to detect package ownership changes.
Third, reduce blast radius in healthcare networks. Segment EHR databases, HL7/FHIR integration engines, PACS/VNA, laboratory middleware, biomedical VLANs, backup infrastructure, and corporate IT. Deny broad guest-to-guest east-west traffic by default. Permit vCenter guest operations only from hardened admin workstations. Egress-filter clinical servers; most EHR and imaging hosts do not need arbitrary internet access.
Fourth, verify management-plane hygiene. Require phishing-resistant MFA for vCenter, backup, IdP, EDR, and remote access. Monitor VMware guest operations, file transfers, and power/snapshot events as high-value audit sources. Review third-party and vendor support pathways, a common soft spot in healthcare.
Useful official references for validation and hardening are the VMware Tools documentation at https://docs.vmware.com/en/VMware-Tools/ and Broadcom/VMware support resources at https://support.broadcom.com/. There is no CISA KEV deadline to cite from this item; set an internal deadline of 72 hours for the initial hunt and 30 days for baseline enforcement on crown-jewel clinical systems.
Finally, brief leadership with the business impact: unauthorized access hidden in guest tooling is not an IT hygiene issue. In healthcare it becomes patient-safety, privacy, clinical-continuity, and regulatory exposure. The organizations that fare best will be those that can prove what normal VMware Tools looks like, detect deviation quickly, and rebuild trust without shutting down care delivery.
Related Resources
Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.