ESXi Attempt to Force Install a VMware VIB Package


Description

Detects an attempt to install a VMware VIB with --force. A VIB is how ESXi adds drivers and host software, and signature checks normally block an unsigned package. --force skips that validation, so an untrusted package can be written onto the hypervisor and affect every virtual machine it runs.

Query · kuery

data_stream.dataset:vsphere.log and event.module:vsphere and message:("vib install" and ("--force" or "-f" or "--no-sig-check"))

Investigation fields

Pivot points the source recommends for triage.

  • @timestamp
  • message
  • event.original
  • host.hostname
  • log.file.path
  • process.pid

Implementation guide

This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere

Known false positives

  • Administrators sometimes force a vendor VIB during a documented recovery or upgrade when the acceptance level would otherwise reject it. Confirm the VIB name against the change ticket.

Analyst notes

Investigating ESXi Attempt to Force Install a VMware VIB Package

esxcli software vib install --force writes the package even when its signature or acceptance level would block it. The shell records the command in shell.log, including attempts that fail because the file is missing.

Possible investigation steps

  • Read the VIB path in message (-v, -d, or --viburl). A path under /tmp is worth a closer look.
  • On the host, run esxcli software vib list and compare new packages with the approved image.
  • Check the same session for ExecInstalledOnly set to FALSE and SSH being enabled.

False positive analysis

A forced install of a known vendor VIB during an approved window can be expected. The package name should match the ticket.

Response and remediation

  • If the package was not approved, remove it with esxcli software vib remove and review files left under /tmp.
  • Set ExecInstalledOnly back to TRUE if it was turned off in the same session.
  • Preserve shell.log before rotating credentials.
Raw source ESXi Attempt to Force Install a VMware VIB Package · Elastic TOML
Esc
Published by elastic/detection-rules ↗, licensed under Elastic License 2.0 ↗. Reproduced here unmodified.
[metadata]
creation_date = "2026/09/30"
integration = ["vsphere"]
maturity = "production"
updated_date = "2026/09/30"

[rule]
author = ["Elastic"]
description = """
Detects an attempt to install a VMware VIB with `--force`. A VIB is how ESXi adds drivers and host software,
and signature checks normally block an unsigned package. `--force` skips that validation, so an untrusted
package can be written onto the hypervisor and affect every virtual machine it runs.
"""
false_positives = [
    """
    Administrators sometimes force a vendor VIB during a documented recovery or upgrade when the acceptance
    level would otherwise reject it. Confirm the VIB name against the change ticket.
    """,
]
from = "now-9m"
index = ["logs-vsphere.log-*"]
language = "kuery"
license = "Elastic License v2"
name = "ESXi Attempt to Force Install a VMware VIB Package"
note = """## Triage and analysis

### Investigating ESXi Attempt to Force Install a VMware VIB Package

esxcli software vib install --force writes the package even when its signature or acceptance level would block it. The shell records the command in shell.log, including attempts that fail because the file is missing.

#### Possible investigation steps

- Read the VIB path in message (-v, -d, or --viburl). A path under /tmp is worth a closer look.
- On the host, run esxcli software vib list and compare new packages with the approved image.
- Check the same session for ExecInstalledOnly set to FALSE and SSH being enabled.

### False positive analysis

A forced install of a known vendor VIB during an approved window can be expected. The package name should match the ticket.

### Response and remediation

- If the package was not approved, remove it with esxcli software vib remove and review files left under /tmp.
- Set ExecInstalledOnly back to TRUE if it was turned off in the same session.
- Preserve shell.log before rotating credentials.
"""
references = [
    "https://lolesxi-project.github.io/LOLESXi/#",
    "https://blogs.vmware.com/security/2022/10/esxi-targeting-ransomware-tactics-and-techniques-part-2.html",
    "https://detect.fyi/vmware-esxi-logging-detection-opportunities-4fb56411ec21",
]
setup = """## Setup

This rule requires ESXi host logs collected by the Elastic vSphere integration: https://www.elastic.co/docs/reference/integrations/vsphere
"""
risk_score = 47
rule_id = "3c9a356d-d878-555c-9d27-a7028c9a074f"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "Data Source: VMware vSphere",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
    "Rule Type: Custom Query (KQL)",
    "Platform: VMware ESXi",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:vsphere.log and event.module:vsphere and message:("vib install" and ("--force" or "-f" or "--no-sig-check"))
'''

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1553"
name = "Subvert Trust Controls"
reference = "https://attack.mitre.org/techniques/T1553/"
[[rule.threat.technique.subtechnique]]
id = "T1553.006"
name = "Code Signing Policy Modification"
reference = "https://attack.mitre.org/techniques/T1553/006/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "message",
    "event.original",
    "host.hostname",
    "log.file.path",
    "process.pid"
]

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.