Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1505.006: vSphere Installation Bundles

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:[1]

* 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. * XML descriptor file: a configuration file containing associated VIB metadata, such as the name of the VIB and its dependencies.

Adversaries may leverage malicious VIB packages to maintain persistent access to ESXi hypervisors, allowing system changes to be executed upon each bootup of ESXi – such as using `esxcli` to enable firewall rules for backdoor traffic, creating listeners on hard coded ports, and executing backdoors.[2] Adversaries may also masquerade their malicious VIB files as PartnerSupported by modifying the XML descriptor file.[2]

EnterpriseT1505.006Sub-techniqueObject v1.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This technique matters because ESXi hypervisors are foundational infrastructure: if a malicious vSphere Installation Bundle persists on a host, changes can survive reboot and affect the virtualization layer rather than a single guest system. For leaders, the key risk is not just malware on a server; it is unauthorized persistence in the platform that runs many workloads.

Executive priority

Prioritize governance over who can install VIBs, change ESXi acceptance levels, or use forced installation options. This is a persistence technique, so incident decisions should include whether rebooting or rebuilding a host is sufficient, and audit evidence should show that installed bundles, signatures, boot integrity, and administrative actions are reviewed. The ATT&CK relationships to Code Signing, Boot Integrity, and Audit make this a control-validation issue as much as a detection issue.

Technical view

SOC, detection, and IR teams should validate visibility into ESXi administrative activity and VIB state. ATT&CK does not provide official detection text for this object, but it does link detection strategy DET0535: Detect Abuse of vSphere Installation Bundles for Persistent Access. Practical validation should focus on VIB installation events, use of esxcli to change acceptance levels, forced VIB installation, unexpected VIB metadata or XML descriptor changes, startup tasks created by VIB payloads, custom firewall rules, and listeners or backdoors that appear after boot. Treat this as a sub-technique of Server Software Component persistence in an ESXi context.

Likely telemetry

  • ESXi host administrative command history or logs, especially esxcli activity
  • VIB inventory, package metadata, XML descriptor contents, signatures, and acceptance levels
  • Events or records for VIB installation, removal, update, or forced installation
  • Configuration changes to ESXi firewall rules and startup behavior
  • Boot-time execution evidence and persistence-related file changes from VIB payloads

Detection direction

  • Validate whether DET0535-style analytics are implemented for VIB abuse rather than only general ESXi administration.
  • Baseline expected VIBs, publishers, acceptance levels, dependencies, and host roles; alert on unexpected additions or metadata changes.
  • Monitor for acceptance-level changes and forced installation behavior because the description notes privileged users can alter acceptance requirements or install regardless of acceptance level.
  • Correlate VIB changes with new firewall rules, startup tasks, binaries, or network listeners after reboot.
  • Tune for legitimate administrator maintenance windows and approved partner-supported updates to reduce false positives.

Mitigation priorities

  • Enforce code signing expectations for software installed on ESXi hosts, aligned to ATT&CK mitigation M1045.
  • Validate boot integrity and trusted startup behavior for hypervisors, aligned to M1046.
  • Maintain routine auditing of ESXi configuration, installed VIBs, administrative actions, and firewall changes, aligned to M1047.
  • Restrict privileged ability to install VIBs, change acceptance levels, or use forced installation options to tightly controlled administrative workflows.
  • Include ESXi VIB review in incident response scoping when persistence on virtualization infrastructure is suspected.
Analyst notes and limits

The supplied ATT&CK relationships identify this as ESXi persistence and connect it to DET0535, M1045 Code Signing, M1046 Boot Integrity, M1047 Audit, parent technique T1505 Server Software Component, UNC3886, and VIRTUALPIE. The VIRTUALPIE relationship specifically notes installation via malicious VIBs in the supplied context. Use those relationships for prioritization, but validate exposure and telemetry locally.

MITRE provides no official detection text for this technique in the supplied object. This take does not assert active exploitation, customer exposure, or guaranteed detection. Local ESXi versions, logging configuration, administrative processes, and approved VIB inventories are required to determine actual risk and coverage.

Official MITRE ATT&CK definition

vSphere Installation Bundles

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:[1]

* 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. * XML descriptor file: a configuration file containing associated VIB metadata, such as the name of the VIB and its dependencies.

Adversaries may leverage malicious VIB packages to maintain persistent access to ESXi hypervisors, allowing system changes to be executed upon each bootup of ESXi – such as using `esxcli` to enable firewall rules for backdoor traffic, creating listeners on hard coded ports, and executing backdoors.[2] Adversaries may also masquerade their malicious VIB files as PartnerSupported by modifying the XML descriptor file.[2]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1505 Server Software Component This object subtechnique of Server Software Component.
Associated objects

Groups, software, and campaigns

Group Enterprise

G1048: UNC3886

UNC3886 is a China-nexus cyberespionage group that has been active since at least 2022, targeting defense, technology, and telecommunication organizations located in the United States and the Asia-Pacific-Japan (APJ) regions. UNC3886 has displayed a deep understanding of edge devices and virtualization technologies through the exploitation of zero-day vulnerabilities and the use of novel malware families and utilities.[1][2]

Malware Enterprise

S1218: VIRTUALPIE

VIRTUALPIE is a lightweight backdoor written in Python that spawns an IPv6 listener on a VMware ESXi server and features command line execution, file transfer, and reverse shell capabilities. VIRTUALPIE has been in use since at least 2022 including by UNC3886 who installed it via malicious vSphere Installation Bundles (VIBs).[1]

ESXi
Relationship explorer

All related ATT&CK context

detects · Detection Strategy DET0535: Detect Abuse of vSphere Installation Bundles (VIBs) for Persistent Access Enterprise uses · Group G1048: UNC3886 Enterprise subtechnique of · Technique T1505: Server Software Component Enterprise mitigates · Mitigation M1046: Boot Integrity Enterprise uses · Malware S1218: VIRTUALPIE Enterprise mitigates · Mitigation M1045: Code Signing Enterprise mitigates · Mitigation M1047: Audit Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1046: Boot Integrity

Boot Integrity ensures that a system starts securely by verifying the integrity of its boot process, operating system, and associated components. This mitigation focuses on leveraging secure boot mechanisms, hardware-rooted trust, and runtime integrity checks to prevent tampering during the boot sequence. It is designed to thwart adversaries attempting to modify system firmware, bootloaders, or critical OS components. This mitigation can be implemented through the following measures:

Implementation of Secure Boot:

- Implementation: Enable UEFI Secure Boot on all systems and configure it to allow only signed bootloaders and operating systems. - Use Case: An adversary attempts to replace the system’s bootloader with a malicious version to gain persistence. Secure Boot prevents the untrusted bootloader from executing, halting the attack.

Utilization of TPMs:

- Implementation: Configure systems to use TPM-based attestation for boot integrity, ensuring that any modification to the firmware, bootloader, or OS is detected. - Use Case: A compromised firmware component alters the boot sequence. The TPM detects the change and triggers an alert, allowing the organization to respond before further damage.

Enable Bootloader Passwords:

- Implementation: Protect BIOS/UEFI settings with a strong password and limit physical access to devices. - Use Case: An attacker with physical access attempts to disable Secure Boot or modify the boot sequence. The password prevents unauthorized changes.

Runtime Integrity Monitoring:

- Implementation: Deploy solutions to verify the integrity of critical files and processes after boot. - Use Case: A malware infection modifies kernel modules post-boot. Runtime integrity monitoring detects the modification and prevents the malicious module from loading.

Mitigation Enterprise

M1045: Code Signing

Code Signing is a security process that ensures the authenticity and integrity of software by digitally signing executables, scripts, and other code artifacts. It prevents untrusted or malicious code from executing by verifying the digital signatures against trusted sources. Code signing protects against tampering, impersonation, and distribution of unauthorized or malicious software, forming a critical defense against supply chain and software exploitation attacks. This mitigation can be implemented through the following measures:

Enforce Signed Code Execution:

- Implementation: Configure operating systems (e.g., Windows with AppLocker or Linux with Secure Boot) to allow only signed code to execute. - Use Case: Prevent the execution of malicious PowerShell scripts by requiring all scripts to be signed with a trusted certificate.

Vendor-Signed Driver Enforcement:

- Implementation: Enable kernel-mode code signing to ensure that only drivers signed by trusted vendors can be loaded. - Use Case: A malicious driver attempting to modify system memory fails to load because it lacks a valid signature.

Certificate Revocation Management:

- Implementation: Use Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs) to block certificates associated with compromised or deprecated code. - Use Case: A compromised certificate used to sign a malicious update is revoked, preventing further execution of the software.

Third-Party Software Verification:

- Implementation: Require software from external vendors to be signed with valid certificates before deployment. - Use Case: An organization only deploys signed and verified third-party software to prevent supply chain attacks.

Script Integrity in CI/CD Pipelines:

- Implementation: Integrate code signing into CI/CD pipelines to sign and verify code artifacts before production release. - Use Case: A software company ensures that all production builds are signed, preventing tampered builds from reaching customers.

**Key Components of Code Signing**

- Digital Signature Verification: Verifies the authenticity of code by ensuring it was signed by a trusted entity. - Certificate Management: Uses Public Key Infrastructure (PKI) to manage signing certificates and revocation lists. - Enforced Policy for Unsigned Code: Prevents the execution of unsigned or untrusted binaries and scripts. - Hash Integrity Check: Confirms that code has not been altered since signing by comparing cryptographic hashes.

Mitigation Enterprise

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
40691869be9707d1...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 40691869be97…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    VMware VIBs

    Kyle Gleed. (2011, September 13). What's in a VIB?. Retrieved March 27, 2025.

    Open source URL
  2. [2]
    Google Cloud Threat Intelligence ESXi VIBs 2022

    Alexander Marvi, Jeremy Koppen, Tufail Ahmed, and Jonathan Lepore. (2022, September 29). Bad VIB(E)s Part One: Investigating Novel Malware Persistence Within ESXi Hypervisors. Retrieved March 26, 2025.

    Open source URL
  3. [3]
    mitre-attack T1505.006
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use