Il ransomware VMware ESXi cambia pelle. Ora crittografa quantità estese di dati e sembra non utilizzare SLP

Come abbiamo riportato recentemente, un attacco ransomware globale ha crittografato circa 3000 server VMware ESXi esposti a Internet utilizzando il nuovo ransomware ESXiArgs.

A livello Italia, non abbiamo avuto grossi impatti, ma la diffusione del ransomware a livello globale e soprattutto in certi paesi come la Francia, ha portato all’attenzione questa nuova minaccia che chiede 2 bitcoin per il ripristino delle infrastrutture violate.

Nella giornata di ieri abbiamo riportato che gli esperti del Department of Homeland Security Cybersecurity and Infrastructure Protection Agency (DHS CISA) hanno creato uno script per consentire il ripristino delle macchine crittografate, ma sembra che la situazione sia cambiata.

Infatti, i nuovi attacchi ransomware ESXiArgs stanno ora crittografando quantità di dati più estese, rendendo molto più difficile, se non impossibile, il ripristino di macchine virtuali VMware ESXi crittografate.

I rapporti preliminari hanno indicato che i dispositivi sono stati violati utilizzando le vecchie vulnerabilità SLP di VMware. Tuttavia, alcune vittime hanno affermato che SLP era disabilitato sui propri dispositivi ed è stato comunque violato e crittografato.

Come funziona la crittografia di ESXiArgs

Dalle analisi di BleepingComputer, quando si crittografa un dispositivo, uno script “encrypt.sh” cerca i file della macchina virtuale che corrispondono alle seguenti estensioni:

.vmdk
.vmx
.vmxf
.vmsd
.vmsn
.vswp
.vmss
.nvram
.vmem

Per ogni file trovato, lo script controlla la dimensione del file e, se il file è inferiore a 128 MB, crittografa l’intero file con incrementi di 1 MB.

Tuttavia, per i file più grandi di 128 MB, calcolerebbe un ‘size_step’, che farebbe alternare il crittografo tra la crittografia di 1 MB di dati e la non crittografia di blocchi (il size_step in megabyte) di dati.

Lo script encrypt.sh utilizza la seguente formula per determinare quale size_step deve essere utilizzato:

size_step=((($size_in_kb/1024/100)-1))

Ciò significa che per un file da 4,5 GB, genererebbe un size_step di ’45’, facendo sì che il codificatore alterni una crittografia di 1 MB ad un salto di 45 MB del file. Quindi, un bel po ‘di dati rimane non crittografato al termine del processo di crittografia. 

Per file ancora più grandi, come un file da 450 GB, la quantità di dati saltati aumenta drasticamente, con size_step che diventa “4607”, alternando la crittografia di 1 MB ad un salto di 4,49 GB di dati.

A causa di questi grandi blocchi di dati non crittografati, i ricercatori hanno ideato un metodo per ripristinare le macchine virtuali. Hanno utilizzato i file flat di grandi dimensioni e principalmente non crittografati, in cui sono archiviati i dati del disco della macchina virtuale.

Uno script creato da CISA ha successivamente automatizzato questo processo di recupero.

Una seconda ondata di ESXiArgs cambia tutto

Sfortunatamente, una seconda ondata di ransomware ESXiArgs è iniziata oggi e include una routine di crittografia modificata che crittografa molti più dati in file di grandi dimensioni.

Un amministratore ha pubblicato sul forum di BleepingComputer un post sull’argomento ESXiArgs affermando che il suo server è stato crittografato e non poteva essere recuperato utilizzando i metodi che avevano funzionato in precedenza.

BleepingComputer ha notato che l’encryptor non era cambiato, ma la routine ‘size_step’ dello script encrypt.sh era stata eliminata e semplicemente impostata su 1 nella nuova versione.

Questa modifica è illustrata di seguito in un confronto tra il calcolo originale encrypt.sh size_step (a sinistra) nella prima ondata di attacchi, con il nuovo script (a destra) nella seconda ondata.

L’esperto di ransomware Michael Gillespie ha dichiarato a BleepingComputer che questa modifica fa sì che il crittografo alterni tra la crittografia di 1 MB di dati e il salto di 1 MB di dati.

Tutti i file superiori a 128 MB avranno ora il 50% dei loro dati crittografati, rendendoli probabilmente irrecuperabili.

Questa modifica impedisce inoltre agli strumenti di ripristino precedenti di ripristinare correttamente le macchine, poiché i file flat avranno troppi dati crittografati per essere utilizzabili.

Modificata anche la richiesta di riscatto eliminando il wallet

Questa seconda ondata di attacco ha anche apportato una piccola modifica alla richiesta di riscatto non includendo più gli indirizzi bitcoin nella nota di riscatto, come mostrato di seguito.

La rimozione degli indirizzi bitcoin è probabilmente dovuta al fatto che tali indirizzi venivano raccolti dai ricercatori di sicurezza per tenere traccia dei pagamenti del riscatto.

Tuttavia, cosa ancora più preoccupante, l’amministratore che ha condiviso i nuovi campioni ha affermato di aver disabilitato SLP sul proprio server ma di essere stato comunque violato di nuovo.

Hanno anche controllato la backdoor vmtool.py vista negli attacchi precedenti e non è stata trovata. Con SLP disabilitato, diventa ancora più confuso il modo in cui questo server è stato violato.

Redazione

La Redazione di Red Hot Cyber fornisce aggiornamenti quotidiani su bug, data breach e minacce globali. Ogni contenuto è validato dalla nostra community di esperti come Pietro Melillo, Massimiliano Brolli, Sandro Sana, Olivia Terragni e Stefano Gazzella. Grazie alla sinergia con i nostri Partner leader nel settore (tra cui Accenture, CrowdStrike, Trend Micro e Fortinet), trasformiamo la complessità tecnica in consapevolezza collettiva, garantendo un'informazione accurata basata sull'analisi di fonti primarie e su una rigorosa peer-review tecnica.