vSphere Installation Bundles
Where this stands
A reviewer read the telemetry and concluded there is nothing here to detect that a sibling technique does not already cover.
The single analytic AN1475 offers exactly one Sigma logsource, {product: linux, service: fim}, and that source is neither a Sigma taxonomy entry nor something lib/sigma can name a field on. It is a pass-through: scripts/mitre/logsource.mjs matches the linux family and returns {product: linux, service: } with the MITRE string copied straight into service, so fim here is MITRE's own word for the telemetry rather than a Sigma service with a defined schema. Sigma's real file-write vocabulary on this platform is {category: file_event, product: linux} carrying TargetFilename, which lib/sigma/translate.ts does map — but the brief does not offer it, and substituting it would breach AUTHORING.md rule 1 exactly as inventing field names on service: fim would breach rule 2. No rule in this corpus has ever been written against a fim logsource. […]
Covered instead by T1037.004.
What the technique is
Adversaries may abuse vSphere Installation Bundles (VIBs) to establish persistent access to ESXi hypervisors. VIBs are collections of files used for software distribution and virtual system management in VMware environments. Since ESXi uses an in-memory filesystem where changes made to most files are stored in RAM rather than in persistent storage, these modifications are lost after a reboot. However, VIBs can be used to create startup tasks, apply custom firewall rules, or deploy binaries that persist across reboots. Typically, administrators use VIBs for updates and system maintenance. VIBs can be broken down into three components: VIB payload: a.vgz archive containing the directories and files to be created and executed on boot when the VIBs are loaded. Signature file: verifies the host acceptance level of a VIB, indicating what testing and validation has been done by VMware or its partners before publication of a VIB. By default, ESXi hosts require a minimum acceptance level of PartnerSupported for VIB installation, meaning the VIB is published by a trusted VMware partner. However, privileged users can change the default acceptance level using the esxcli command line interface. Additionally, VIBs are able to be installed regardless of acceptance level by using the esxcli software vib install --force command. […]
Read it on attack.mitre.orgWhat MITRE says you would watch
- AN1475
Malicious VIB installation for persistence via esxcli software vib install using --force or --no-sig-check, enabling custom startup scripts or firewall rules. Behavior chain: (1) unsigned/suspicious VIB installation → (2) startup script or binary placed in persistent boot path → (3) persistence across reboot via /etc/rc.local.d or other boot hook).
Technique names and descriptions © MITRE ATT&CK®, CC BY 4.0. Not endorsed by MITRE.