T1675

ESXi Administration Command

Execution Last updated:

This detection identifies adversaries abusing ESXi administration services — particularly the VMware Tools Daemon (vmtoolsd.exe on Windows, vmtoolsd on Linux, vmware-tools-daemon on macOS) — to execute commands on guest virtual machines from a compromised ESXi hypervisor. Attackers, including UNC3886 using VIRTUALPITA malware, leverage the vSphere Web Services SDK and Guest Operations APIs (StartProgramInGuest, ListProcessesInGuest, InitiateFileTransferFromGuest) to run arbitrary code on hosted VMs without traditional lateral movement vectors. Detection focuses on anomalous child process spawning from vmtoolsd.exe on guest OSes, unusual file transfer activity through VMware guest operations channels, and suspicious vSphere API authentication events from unexpected source IPs.

What is T1675 ESXi Administration Command?

ESXi Administration Command (T1675) maps to the Execution tactic — the adversary is trying to run malicious code in MITRE ATT&CK.

This page provides production-ready detection logic for ESXi Administration Command, covering the data sources and telemetry it touches: Microsoft Defender for Endpoint. The queries below are rated high severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Execution
Technique
T1675 ESXi Administration Command
Canonical reference
https://attack.mitre.org/techniques/T1675/
Microsoft Sentinel / Defender
kusto
// Primary detection: Suspicious child processes spawned by VMware Tools Daemon on guest VMs
let suspiciousProcesses = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe", "wmic.exe", "net.exe", "net1.exe", "whoami.exe", "ipconfig.exe", "nltest.exe", "ping.exe", "tasklist.exe", "netstat.exe", "schtasks.exe", "at.exe", "sc.exe", "reg.exe", "curl.exe", "wget.exe"]);
let benignChildren = dynamic(["vmtoolsd.exe", "vmwaretray.exe", "vmwareuser.exe", "VGAuthService.exe", "TPAutoConnect.exe", "vmacthlp.exe", "conhost.exe", "vmwarehostopen.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName =~ "vmtoolsd.exe"
| where FileName !in~ (benignChildren)
| extend IsHighRisk = iff(FileName in~ (suspiciousProcesses), true, false)
| extend CommandLineLen = strlen(ProcessCommandLine)
| project
    TimeGenerated,
    DeviceName,
    AccountName,
    AccountDomain,
    FileName,
    ProcessCommandLine,
    ProcessId,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    InitiatingProcessParentFileName,
    InitiatingProcessParentId,
    IsHighRisk,
    FolderPath
| order by IsHighRisk desc, TimeGenerated desc

Detects suspicious processes spawned by vmtoolsd.exe (VMware Tools Daemon) on guest virtual machines. When an ESXi host is compromised and an attacker uses the vSphere Guest Operations API (StartProgramInGuest), the executed process appears as a child of vmtoolsd.exe on the guest OS. This query identifies non-standard child processes of vmtoolsd.exe, prioritizing high-risk executables like cmd.exe, PowerShell, and living-off-the-land binaries that indicate attacker-controlled execution via ESXi administration channels.

high severity high confidence

Data Sources

Microsoft Defender for Endpoint

Required Tables

DeviceProcessEvents

False Positives

  • VMware Tools auto-update mechanisms launching update executables as children of vmtoolsd.exe
  • Legitimate IT operations or configuration management tools configured to run via VMware Guest Operations APIs for automated provisioning or patch management
  • VMware vRealize Automation or vSphere Lifecycle Manager executing maintenance scripts through Guest Operations as part of scheduled infrastructure management tasks
  • Monitoring agents deployed via VMware Tools integration that spawn diagnostic collection processes under vmtoolsd.exe
  • VMware Horizon View or App Volumes agents performing session management operations through the tools daemon

Sigma rule & cross-platform mapping

The detection logic for ESXi Administration Command (T1675) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Execute Command on Guest VM via vSphere Guest Operations API (PowerCLI)

    Expected signal: On the guest Windows VM: Sysmon Event ID 1 with ParentImage=vmtoolsd.exe and Image=cmd.exe; Windows Security Event 4688 with ParentProcessName vmtoolsd.exe; vmware-vmsvc log entry recording StartProgramInGuest invocation

  2. Test 2Simulate vmtoolsd.exe Child Process Execution (Local Process Spawn)

    Expected signal: Sysmon Event ID 1 showing ParentProcessId matching vmtoolsd.exe PID; Windows Security EventID 4688

  3. Test 3ESXi Guest File Transfer Simulation via InitiateFileTransferToGuest (Python SDK)

    Expected signal: Sysmon Event ID 11 (FileCreate) with Image=vmtoolsd.exe creating C:\Temp\t1675_test.txt; Sysmon Event ID 1 with ParentImage=vmtoolsd.exe spawning cmd.exe; ESXi hostd.log entries for InitiateFileTransferToGuest and StartProgramInGuest

Unlock Pro Content

Get the full detection package for T1675 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections

Tactic Hub