DET0535: Detect Abuse of vSphere Installation Bundles (VIBs) for Persistent Access
DET0535 matters because it focuses on detecting persistence through vSphere Installation Bundles, a mechanism associated with ESXi hypervisors. For leaders...
Analyst context for executives and security teams
DET0535 matters because it focuses on detecting persistence through vSphere Installation Bundles, a mechanism associated with ESXi hypervisors. For leaders, the key issue is not just malware detection; it is whether changes to the virtualization layer can survive reboot and undermine recovery assumptions for critical workloads.
Executive priority
Prioritize this as a virtualization resilience and privileged-change-control question. Executives should ask whether ESXi host changes, VIB inventory, startup behavior, and firewall-rule changes are visible, approved, and auditable. If hypervisors support critical systems, gaps here can weaken incident recovery, business continuity, and compliance evidence around administrative control of infrastructure.
Technical view
The supplied ATT&CK relationship maps this detection strategy to T1505.006, vSphere Installation Bundles, under persistence on ESXi. SOC, IR, and detection engineering teams should validate whether they can identify new, modified, or unexpected VIBs and related changes that create startup tasks, custom firewall rules, or deployed binaries. Because the detection strategy object does not include official detection logic, teams should build environment-specific baselines and compare host state against approved software distribution and change records.
Likely telemetry
- ESXi host logs relevant to VIB installation, update, or removal activity
- Current and historical VIB inventory from ESXi hosts
- Configuration evidence for startup tasks or boot-time execution behavior
- ESXi firewall rule configuration and change history
- File or binary deployment evidence on ESXi hosts where available
Detection direction
- Baseline approved VIBs per ESXi host or cluster and alert on unapproved additions, removals, or modifications.
- Correlate VIB changes with authorized maintenance windows and documented administrative activity to reduce false positives.
- Review VIB-associated startup tasks, firewall-rule changes, and deployed binaries for persistence-relevant behavior.
- Account for blind spots where ESXi host telemetry is not centrally collected or where only guest workload logs are monitored.
- Use the relationship to T1505.006 to treat suspicious VIB activity as persistence-focused, especially when changes survive reboot or affect host-level startup behavior.
Mitigation priorities
- Establish an approved VIB inventory and enforce change control for ESXi host modifications.
- Limit and audit privileged access capable of changing ESXi host software or configuration.
- Ensure hypervisor configuration and host-state evidence is collected for SOC and IR use, not only guest operating system telemetry.
- Include ESXi VIB review in incident response triage and post-incident recovery validation for VMware environments.
- Test recovery procedures to confirm unauthorized persistent host-level changes would be identified before returning workloads to service.
Analyst notes and limits
This take is based on a detection strategy object with no official description or detection text, plus its ATT&CK relationship to T1505.006. The practical value is in validating visibility and governance around ESXi VIB changes rather than assuming a specific analytic is provided by MITRE.
Platforms and tactics are not specified on the detection strategy object itself; ESXi and persistence come from the related technique context. No active exploitation, attribution, specific tool behavior, or guaranteed detection coverage is supplied. Local VMware architecture, logging configuration, and change-management data are required to operationalize this.
Detect Abuse of vSphere Installation Bundles (VIBs) for Persistent Access
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1505.006 | vSphere Installation Bundles Sub-technique | This object detects vSphere Installation Bundles. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | dd76794f9964… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0535Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.