T1675 IBM QRadar · QRadar

Detect ESXi Administration Command in IBM QRadar

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.

MITRE ATT&CK

Tactic
Execution
Technique
T1675 ESXi Administration Command
Canonical reference
https://attack.mitre.org/techniques/T1675/

QRadar Detection Query

IBM QRadar (QRadar)
sql 
SELECT
    DATEFORMAT(devicetime, 'yyyy-MM-dd HH:mm:ss') AS EventTime,
    LOGSOURCENAME(logsourceid) AS LogSource,
    "username" AS AccountName,
    "CommandLine" AS CommandLine,
    "ParentProcessName" AS ParentProcess,
    "NewProcessName" AS ProcessName,
    CASE
        WHEN "CommandLine" ILIKE '%powershell%' AND "CommandLine" ILIKE '%-enc%' THEN 'EncodedCommand'
        WHEN "CommandLine" ILIKE '%bypass%' THEN 'ExecutionBypass'
        WHEN "CommandLine" ILIKE '%-noprofile%' THEN 'NoProfileExecution'
        ELSE 'SuspiciousProcess'
    END AS DetectionType,
    CASE
        WHEN "username" = 'SYSTEM' THEN 70
        WHEN "CommandLine" ILIKE '%bypass%' THEN 85
        ELSE 60
    END AS RiskScore
FROM events
WHERE
    LOGSOURCETYPENAME(devicetype) IN ('Microsoft Windows Security Event Log', 'Universal DSM')
    AND eventid IN (4688, 1)
    AND ("NewProcessName" ILIKE '%powershell.exe%'
        OR "NewProcessName" ILIKE '%cmd.exe%'
        OR "NewProcessName" ILIKE '%wscript.exe%'
        OR "NewProcessName" ILIKE '%cscript.exe%'
        OR "NewProcessName" ILIKE '%mshta.exe%')
    AND RiskScore >= 60
ORDER BY EventTime DESC
LAST 1 HOURS
high severity high confidence

IBM QRadar AQL detection for ESXi Administration Command (T1675). Queries QRadar event pipeline for indicators consistent with esxi administration command adversary techniques using MITRE ATT&CK-aligned event categorization.

Data Sources

IBM QRadar SIEMWindows Security EventsEndpoint Agent

Required Tables

events

False Positives & Tuning

  • 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

Other platforms for T1675

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

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 1 Execute 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 2 Simulate 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 3 ESXi 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

Last updated: 2026-03-20 Research depth: deep
References (4)

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

Related Techniques

[object Object][object Object][object Object][object Object][object Object][object Object][object Object]

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

TA0002 Execution

Related Techniques

T1059 Command and Scripting Interpreter T1003 OS Credential Dumping T1083 File and Directory Discovery T1005 Data from Local System T1021 Remote Services T1068 Exploitation for Privilege Escalation T1053.007 Container Orchestration Job

Same Tactic: Execution

Popular Detections