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


Response Playbook

Triage

  1. Step 1: Identify the guest VM (DeviceName/hostname) and verify it is hosted on a VMware ESXi hypervisor. Cross-reference with asset inventory to confirm ESXi hosting.
  2. Step 2: Examine the full process tree on the guest VM — determine what vmtoolsd.exe spawned, the exact command line, working directory, and whether the child process spawned further children. Look for multi-stage execution chains.
  3. Step 3: Check the timestamp of the suspicious vmtoolsd.exe child process against known administrative windows, change management tickets, and VMware scheduled tasks. Alert if outside business hours or undocumented.
  4. Step 4: Identify the user account context under which vmtoolsd.exe spawned the child process. Legitimate Guest Operations require vCenter credentials — query vCenter/ESXi authentication logs (vpxd.log, hostd.log) for the corresponding StartProgramInGuest API call around the same timestamp.
  5. Step 5: Review ESXi host-level logs for the API call source IP. Query ESXi syslog or forwarded hostd logs for 'StartProgramInGuest', 'ListProcessesInGuest', or 'InitiateFileTransferFromGuest' entries within ±5 minutes of the detection. Verify the source IP matches authorized vCenter management infrastructure.
  6. Step 6: On the guest VM, run process memory analysis on the spawned child process (if still running) to identify injected payloads, hollowing indicators, or loaded unsigned DLLs.
  7. Step 7: Correlate with network telemetry — check DeviceNetworkEvents for outbound connections from the child process or its descendants that could indicate C2, data staging, or lateral movement.

Containment

  1. Immediately isolate the affected guest VM from the network using Microsoft Defender for Endpoint live response or through the vCenter network policy layer (remove VM from distributed port groups) to prevent further attacker-controlled execution or data exfiltration.
  2. If the ESXi host itself is suspected compromised (source IP for Guest Operations API calls is not vCenter): isolate the hypervisor from the management network and place in maintenance mode after live-snapshotting all hosted VMs for forensic preservation.
  3. Revoke and rotate vCenter/ESXi administrative credentials immediately, prioritizing accounts observed in hostd authentication logs around the time of the incident. Enforce MFA for all vSphere Web Client and API access.
  4. Disable the VMware Guest Operations API (GuestOperationsManager) at the vCenter level for all non-essential VMs via advanced VM configuration: set 'isolation.tools.guestops.disable = TRUE' in VM .vmx files or via vCenter policies.
  5. Terminate any malicious child processes identified on guest VMs using Microsoft Defender for Endpoint live response kill process capability, and quarantine any dropped files.
  6. Block source IP addresses identified as unauthorized callers to the vSphere Guest Operations API at the management network firewall until investigation completes.

Evidence Collection

  1. Export Microsoft Defender for Endpoint advanced hunting results for all DeviceProcessEvents where InitiatingProcessFileName == 'vmtoolsd.exe' for the past 30 days across all enrolled VMs to identify scope and persistence.
  2. Collect ESXi hostd.log and vpxd.log from the affected hypervisor: 'vim-cmd vmsvc/get.summary <vmid>' and copy logs from /var/log/vmware/hostd.log. Focus on StartProgramInGuest, GuestOperations, and authentication entries.
  3. Acquire VM memory snapshot (suspend VM and copy .vmem/.vmsn files from ESXi datastore) before any remediation actions to preserve volatile evidence including process memory, network connections, and in-memory payloads.
  4. Collect Windows event logs from the guest VM: Security (4688), Sysmon (1, 3, 7, 10, 11), PowerShell (4103, 4104), and WMI (Microsoft-Windows-WMI-Activity/Operational). Export to EVTX and copy to secure evidence store.
  5. Collect VMware Tools log from the guest VM at C:\ProgramData\VMware\VMware Tools\vmware-vmsvc-[hostname].log (Windows) or /var/log/vmware-vmsvc.log (Linux) — this log records Guest Operations API calls received and executed.
  6. Capture disk image of guest VM VMDK from ESXi datastore for offline forensic analysis — preserve file system metadata, prefetch files (C:\Windows\Prefetch\), and any files dropped in temp directories.
  7. Export vCenter Server audit logs via vSphere API or vCenter Server Appliance (VCSA) shell at /var/log/vmware/vsphere-ui/logs/ and /var/log/vmware/vpxd/ to establish the full API call chain and attacker session timeline.

Escalation Criteria

  • ! Escalate to P1/Critical if the ESXi host itself shows signs of compromise — e.g., unauthorized VIB (vSphere Installation Bundle) installation, presence of VIRTUALPITA-like backdoors, or ESXi shell access from non-management IPs.
  • ! Escalate immediately if Guest Operations API calls originated from an IP address that is not the authorized vCenter Server — this indicates the ESXi management API is being accessed directly by an adversary without going through vCenter.
  • ! Escalate if lateral movement is detected: evidence that commands executed on one guest VM accessed credential stores, network shares, or initiated connections to other guest VMs or to the management network.
  • ! Escalate if OS Credential Dumping artifacts are observed on the guest VM (LSASS access, SAM/NTDS.dit access, mimikatz indicators) — attacker is likely seeking credentials for broader network compromise.
  • ! Escalate if multiple guest VMs across the same ESXi host or multiple hypervisors show simultaneous vmtoolsd.exe child process anomalies — indicates automated mass exploitation consistent with ransomware deployment campaigns targeting hypervisor fleets.
  • ! Escalate if data staging or exfiltration indicators are present: large file writes to temp directories, outbound connections to external IPs from vmtoolsd.exe children, or InitiateFileTransferFromGuest API calls logged in ESXi.

Investigation Guide

Forensic Artifacts

  • > VMware Tools log on guest VM (Windows: C:\ProgramData\VMware\VMware Tools\vmware-vmsvc-[hostname].log; Linux: /var/log/vmware-vmsvc.log) — records Guest Operations API commands received
  • > ESXi hostd.log at /var/log/vmware/hostd.log — contains StartProgramInGuest, ListProcessesInGuest, InitiateFileTransferFromGuest API calls with source IP and credentials used
  • > ESXi vpxd.log at /var/log/vmware/vpxd/ — vCenter proxy daemon logs showing API call routing and session establishment
  • > Windows Prefetch files on guest VM (C:\Windows\Prefetch\) — process execution evidence for short-lived commands spawned by vmtoolsd.exe
  • > Windows Security Event Log 4688 and Sysmon Event 1 on guest VM — process creation events showing vmtoolsd.exe as parent process with full command line arguments
  • > ESXi authentication log at /var/log/auth.log — SSH sessions and direct ESXi shell access by unauthorized accounts
  • > vCenter Server audit log (VCSA: /var/log/vmware/vsphere-ui/logs/vsphere_client_virgo.log) — tracks which vCenter user/session invoked Guest Operations Manager APIs
  • > Windows NTUSER.DAT and USRCLASS.DAT registry hives on guest VM — ShellBags and UserAssist artifacts from interactive attacker sessions if shell was obtained via spawned cmd.exe

Tuning Guidance

Begin by building a baseline of all legitimate vmtoolsd.exe child processes in your environment over 14+ days. Most organizations will see VMware Tools update processes (VMwareToolsUpgrader.exe, setup64.exe during updates), VGAuthService.exe, and potentially IT automation agents. Add these to the benignChildren exclusion list. Exclude VMs running VMware Horizon where session management spawns additional processes under vmtoolsd.exe. If you use VMware vRealize Automation or Aria Automation, catalog the specific scripts it executes via Guest Operations and add those script names/paths to exclusions. Consider creating a separate alert for HIGH-risk child processes (cmd.exe, PowerShell, certutil, etc.) at Critical severity and a lower-severity alert for any unexpected non-high-risk child processes. Suppress events from known administrative jump boxes or vCenter management IPs during scheduled maintenance windows. For the ESXi syslog hunting queries, ensure your SIEM receives ESXi hostd.log via syslog forwarding — configure this in vCenter Server > Host > Configure > Security Profile > Syslog.


Hunting Queries

Hunts for file creation/modification events initiated by vmtoolsd.exe outside of VMware-owned directories, indicating use of InitiateFileTransferFromGuest or InitiateFileTransferToGuest API to drop or exfiltrate files on guest VMs.

Hunting — KQL
kql
// Hunt: File transfers via VMware Guest Operations (InitiateFileTransferFromGuest artifacts)
DeviceFileEvents
| where TimeGenerated > ago(30d)
| where InitiatingProcessFileName =~ "vmtoolsd.exe"
| where ActionType in ("FileCreated", "FileModified", "FileRenamed")
| where FolderPath !startswith @"C:\Program Files\VMware\"
| where FolderPath !startswith @"C:\ProgramData\VMware\"
| extend Extension = tostring(split(FileName, ".")[-1])
| summarize
    FileCount = count(),
    UniqueFiles = dcount(FileName),
    TotalSizeBytes = sum(FileSize),
    FileList = make_set(FileName, 20),
    Folders = make_set(FolderPath, 10)
    by DeviceName, bin(TimeGenerated, 1h)
| where FileCount > 3
| order by TotalSizeBytes desc
Hunting — SPL
spl
index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11
| where match(lower(Image), "vmtoolsd\.exe$")
| eval FilePath=TargetFilename
| where NOT match(lower(FilePath), "vmware")
| eval Extension=mvindex(split(FilePath, "."), -1)
| stats count as FileCount, dc(FilePath) as UniqueFiles, values(FilePath) as Files by Computer, span(_time, 1h)
| where FileCount > 3
| sort - FileCount

Hunts for outbound network connections initiated by child processes of vmtoolsd.exe to external (non-RFC1918) IP addresses, which would indicate C2 communication or data exfiltration initiated via ESXi Guest Operations command execution.

Hunting — KQL
kql
// Hunt: Network connections from vmtoolsd.exe children to external IPs
let vmtoolsChildren = DeviceProcessEvents
    | where TimeGenerated > ago(30d)
    | where InitiatingProcessFileName =~ "vmtoolsd.exe"
    | where FileName !in~ ("vmtoolsd.exe", "conhost.exe", "vmwaretray.exe", "VGAuthService.exe")
    | project DeviceName, ProcessId, FileName, TimeGenerated;
DeviceNetworkEvents
| where TimeGenerated > ago(30d)
| join kind=inner vmtoolsChildren on DeviceName, $left.InitiatingProcessId == $right.ProcessId
| where RemoteIPType !in ("Private", "Loopback")
| project
    TimeGenerated,
    DeviceName,
    InitiatingProcessFileName,
    FileName,
    RemoteIP,
    RemotePort,
    RemoteUrl,
    InitiatingProcessCommandLine
| order by TimeGenerated desc
Hunting — SPL
spl
index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
| eval ParentImage=ParentImage
| where match(lower(ParentImage), "vmtoolsd\.exe$")
| eval RemoteIP=DestinationIp
| where NOT cidrmatch("10.0.0.0/8", RemoteIP) AND NOT cidrmatch("172.16.0.0/12", RemoteIP) AND NOT cidrmatch("192.168.0.0/16", RemoteIP) AND NOT cidrmatch("127.0.0.0/8", RemoteIP)
| table _time, Computer, Image, ParentImage, RemoteIP, DestinationPort, DestinationHostname
| sort - _time

Hunts for high-volume vSphere Guest Operations API calls (StartProgramInGuest, ListProcessesInGuest, InitiateFileTransferFromGuest) in ESXi hostd/vpxd syslog forwarded to the SIEM. Legitimate administrative use rarely involves rapid repeated API calls; bulk activity indicates scripted attacker exploitation.

Hunting — KQL
kql
// Hunt: Unusual volumes of Guest Operations API activity — ESXi hostd logs forwarded as CommonSecurityLog or Syslog
Syslog
| where TimeGenerated > ago(30d)
| where SyslogMessage contains "StartProgramInGuest"
    or SyslogMessage contains "ListProcessesInGuest"
    or SyslogMessage contains "InitiateFileTransferFromGuest"
    or SyslogMessage contains "InitiateFileTransferToGuest"
    or SyslogMessage contains "ListFilesInGuest"
    or SyslogMessage contains "GuestOps"
| extend GuestOpsAPI = case(
    SyslogMessage contains "StartProgramInGuest", "StartProgramInGuest",
    SyslogMessage contains "ListProcessesInGuest", "ListProcessesInGuest",
    SyslogMessage contains "InitiateFileTransferFromGuest", "InitiateFileTransferFromGuest",
    SyslogMessage contains "InitiateFileTransferToGuest", "InitiateFileTransferToGuest",
    SyslogMessage contains "ListFilesInGuest", "ListFilesInGuest",
    "OtherGuestOps")
| summarize
    CallCount = count(),
    APIs = make_set(GuestOpsAPI),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by HostName, bin(TimeGenerated, 1h)
| where CallCount > 10
| order by CallCount desc
Hunting — SPL
spl
index=* sourcetype="syslog" host=esxi*
("StartProgramInGuest" OR "ListProcessesInGuest" OR "InitiateFileTransferFromGuest" OR "InitiateFileTransferToGuest" OR "ListFilesInGuest")
| eval GuestOpsAPI=case(
    match(_raw, "StartProgramInGuest"), "StartProgramInGuest",
    match(_raw, "ListProcessesInGuest"), "ListProcessesInGuest",
    match(_raw, "InitiateFileTransferFromGuest"), "InitiateFileTransferFromGuest",
    match(_raw, "InitiateFileTransferToGuest"), "InitiateFileTransferToGuest",
    match(_raw, "ListFilesInGuest"), "ListFilesInGuest",
    1=1, "Other")
| stats count as CallCount, values(GuestOpsAPI) as APIs, min(_time) as FirstSeen, max(_time) as LastSeen by host, span(_time, 1h)
| where CallCount > 10
| sort - CallCount

Hunts for OS credential dumping activity specifically initiated via vmtoolsd.exe parent process, targeting LSASS, NTDS.dit, or SAM hive access. This pattern is consistent with UNC3886 post-exploitation behavior after gaining VM execution via ESXi Guest Operations.

Hunting — KQL
kql
// Hunt: Privileged process execution via vmtoolsd.exe targeting credential stores
DeviceProcessEvents
| where TimeGenerated > ago(30d)
| where InitiatingProcessFileName =~ "vmtoolsd.exe"
| where
    ProcessCommandLine has_any ("lsass", "ntds.dit", "SAM", "SYSTEM", "vssadmin", "shadow", "procdump", "mimikatz", "sekurlsa", "hashdump", "credential")
    or FileName =~ "procdump.exe"
    or FileName =~ "procdump64.exe"
    or FileName =~ "ProcDump.exe"
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessCommandLine
| order by TimeGenerated desc
Hunting — SPL
spl
index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| where match(lower(ParentImage), "vmtoolsd\.exe$")
| where match(lower(CommandLine), "lsass|ntds\.dit|vssadmin|procdump|mimikatz|sekurlsa|hashdump|credential|sam\b")
| table _time, Computer, User, Image, CommandLine, ParentImage
| sort - _time

Atomic Red Team Tests

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

Simulates the attacker technique of using the vSphere Web Services SDK to execute a command on a guest VM via StartProgramInGuest, which causes vmtoolsd.exe to spawn the process on the guest. Requires PowerCLI and valid vCenter/ESXi credentials and a VM with VMware Tools installed.

Command

powershell
# Requires VMware PowerCLI: Install-Module VMware.PowerCLI
# Run from attacker machine with vCenter access
Import-Module VMware.PowerCLI
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false
Connect-VIServer -Server <vcenter_ip> -User <admin_user> -Password <password>
$vm = Get-VM -Name <target_vm_name>
$guestCred = New-Object System.Management.Automation.PSCredential('<guest_user>', (ConvertTo-SecureString '<guest_password>' -AsPlainText -Force))
$opsMgr = Get-View -Id 'GuestOperationsManager'
$procMgr = Get-View -Id $opsMgr.ProcessManager
$progSpec = New-Object VMware.Vim.GuestProgramSpec
$progSpec.ProgramPath = 'C:\Windows\System32\cmd.exe'
$progSpec.Arguments = '/c whoami > C:\Temp\vmtoolsd_test.txt'
$pid = $procMgr.StartProgramInGuest($vm.ExtensionData.MoRef, $guestCred, $progSpec)
Write-Host "Process started with PID: $pid"

Cleanup

powershell
# Remove the output file created by the test
Invoke-VMScript -VM <target_vm_name> -ScriptText 'del C:\Temp\vmtoolsd_test.txt' -GuestCredential $guestCred
Disconnect-VIServer -Confirm:$false

Expected Telemetry

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

Expected Detection

Alert: 'ESXi Administration Command — Suspicious Child Process of vmtoolsd.exe' with FileName=cmd.exe, IsHighRisk=true

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

Simulates the endpoint artifact of ESXi Guest Operations by directly launching a test process as a child of vmtoolsd.exe using Windows process injection. This tests whether the detection fires on the guest VM without requiring a full ESXi environment. Uses a simple process creation via the vmtoolsd.exe binary itself in test mode.

Command

powershell
# This simulates the detection trigger on the guest VM side
# Create a scheduled task that mimics vmtoolsd.exe spawning cmd.exe
# Note: In real attacks, vmtoolsd.exe receives the StartProgramInGuest call from ESXi and spawns the process
# For testing: use Invoke-VMScript equivalent or simply verify parent-child via:
# Step 1: Identify vmtoolsd.exe PID
$vmtoolsPid = (Get-Process vmtoolsd -ErrorAction SilentlyContinue).Id
if (-not $vmtoolsPid) { Write-Host 'VMware Tools not running - install VMware Tools first'; exit }
# Step 2: Use wmic to create process with vmtoolsd as spawner (requires VMware Tools)
# In a real ESXi test environment, use the PowerCLI method above instead
# Alternative: test the detection rule with a mock using Atomic Red Team framework
# Invoke-AtomicTest T1675 -TestName 'ESXi Guest Operations Simulation'
Write-Host "VMware Tools PID: $vmtoolsPid"
Write-Host "To generate the artifact: use PowerCLI StartProgramInGuest or a test ESXi environment"

Cleanup

powershell
# No cleanup required for this simulation step

Expected Telemetry

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

Expected Detection

Alert should fire on detection of any high-risk process with InitiatingProcessFileName=vmtoolsd.exe

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

Uses the vSphere Python SDK (pyVmomi) to simulate an attacker dropping a file onto a guest VM via InitiateFileTransferToGuest API, then executing it via StartProgramInGuest. Tests the file creation artifact in DeviceFileEvents/Sysmon Event 11.

Command

bash
# Requires: pip install pyVmomi requests
# Run from attacker machine with vCenter/ESXi network access
python3 << 'EOF'
from pyVmomi import vim, vmodl
from pyVim.connect import SmartConnect, Disconnect
import ssl
import requests
import tempfile
import os

context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
context.check_hostname = False
context.verify_mode = ssl.CERT_NONE

si = SmartConnect(host='<esxi_or_vcenter_ip>', user='<admin>', pwd='<password>', sslContext=context)

content = si.RetrieveContent()
vm = [vm for vm in content.rootFolder.childEntity[0].vmFolder.childEntity if vm.name == '<target_vm>'][0]

creds = vim.vm.guest.NamePasswordAuthentication(username='<guest_user>', password='<guest_password>')
file_manager = content.guestOperationsManager.fileManager
proc_manager = content.guestOperationsManager.processManager

# Transfer a test file to guest
test_content = b'ESXi_GuestOps_T1675_AtomicTest'
file_attr = vim.vm.guest.FileManager.FileAttributes()
transfer_url = file_manager.InitiateFileTransferToGuest(
    vm=vm, auth=creds, guestFilePath='C:\\Temp\\t1675_test.txt',
    fileAttributes=file_attr, fileSize=len(test_content), overwrite=True)
requests.put(transfer_url, data=test_content, verify=False)
print(f'File transferred. Now executing via StartProgramInGuest...')

# Execute command to verify file exists
proc_spec = vim.vm.guest.ProcessManager.ProgramSpec(
    programPath='C:\\Windows\\System32\\cmd.exe',
    arguments='/c type C:\\Temp\\t1675_test.txt > C:\\Temp\\t1675_output.txt')
pid = proc_manager.StartProgramInGuest(vm=vm, auth=creds, spec=proc_spec)
print(f'Process PID: {pid}')
Disconnect(si)
EOF

Cleanup

bash
# Cleanup via pyVmomi or PowerCLI:
# proc_manager.StartProgramInGuest(vm=vm, auth=creds, spec=vim.vm.guest.ProcessManager.ProgramSpec(programPath='C:\\Windows\\System32\\cmd.exe', arguments='/c del C:\\Temp\\t1675_test.txt C:\\Temp\\t1675_output.txt'))

Expected Telemetry

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

Expected Detection

Both file-based and process-based detection queries should fire: DeviceFileEvents alert for vmtoolsd.exe creating files outside VMware directories, and DeviceProcessEvents alert for vmtoolsd.exe spawning cmd.exe

Related Detections

Tactic Hub