Proposal: Model ESXi Atomics by Target Platform, Not SSH Transport

Use-cases

Atomic Red Team has ESXi atomics that test behavior on an ESXi host, but some of them are currently modeled around the client used to reach that host, such as plink.exe, ssh.exe, PowerCLI, Posh-SSH, or native SSH from Linux/macOS.

This makes supported_platforms describe the operator's runner or transport tool instead of the platform where the adversary behavior occurs. For ESXi atomics, defenders usually care about the ESXi command or API action that was run on the hypervisor, not whether the command reached the host through plink.exe, ssh.exe, PowerCLI, Posh-SSH, or another SSH client.

A target-focused model would help users:

• find all ESXi atomics by filtering for esxi
• avoid duplicate atomics that differ only by SSH client
• keep the YAML focused on the ESXi behavior being tested
• move reusable SSH/session handling into Invoke-AtomicRedTeam
• avoid downloading or depending on plink.exe inside individual atomics

Proposal

Use esxi as the supported_platforms value for atomics that execute behavior on an ESXi host.

Suggested convention:

supported_platforms:
    - esxi

The atomic YAML should focus on the ESXi command, API action, and cleanup logic. It should not need separate variants for plink.exe, ssh.exe, PowerCLI, Posh-SSH, or Linux/macOS SSH when those tools are only transport mechanisms.

For ESXi shell atomics, prefer storing and documenting the command that runs on the host, for example:

esxcli system version get
vim-cmd hostsvc/advopt/view

Move SSH session creation and command transport into Invoke-AtomicRedTeam, preferably using Posh-SSH for PowerShell-based execution. The caller could pass an existing SSH session to the atomic runner instead of each atomic managing its own SSH client and credentials.

Example direction:

$sshSession = New-SSHSession -ComputerName $esxiHost -Credential $credential
Invoke-AtomicTest T0000 -Session $sshSession

This keeps the atomic test platform as esxi while letting Invoke-AtomicRedTeam decide how to deliver the command to the target host.

Suggested migration:

PowerCLI-specific atomics can still exist when the behavior being tested is actually a vSphere or PowerCLI API action. If PowerCLI is only being used as a transport wrapper for an ESXi shell command, the atomic should still be modeled as esxi and the transport should live in Invoke-AtomicRedTeam.

References

• https://github.com/redcanaryco/atomic-red-team/pull/3386
• https://attack.mitre.org/techniques/T1059/012/