Essendo notizia ormai di ieri, la messa a disposizione su GitHub, da parte della CISA, del tool di ripristino per le vittime del recente ransomware ESXiArgs, mi sento tranquillo nel descrivere in maniera diretta come agisce lo script malevolo che sta infettando il mondo delle virtual machine VMware non adeguatamente aggiornate.
Lo script ransomware ESXiArgs da vicino
Come detto dunque la Cybersecurity & Infrastructure Security Agency statunitense ha sviluppato un tool in aiuto alle vittime che hanno subito l’infezione da ransomware ESXiArgs negli ultimi giorni.
Già nei miei commenti riportati nell’analisi di domenica 5 febbraio su CyberSecurity360, proprio per fare chiarezza su questa campagna malevola in atto, avevo accennato al fatto che gli attacchi fossero mirati a rendere non operativa in maniera rapida una virtual machine (VM) VMware ESXi, utilizzando la crittografia unicamente per alcuni file di configurazione della VM, essenziali per la sua operatività, ma senza intaccare il completo filesystem che conterrebbe anche i “dati utente” interni al software che la VM tiene in piedi.
Questa affermazione oggi viene accompagnata dall’analisi dello script che svolge proprio questa attività malevola, negli attacchi descritti.
Tengo a precisare che faccio solo oggi questa analisi benché lo script malevolo sia disponibile già da giorni, perché pur essendo nota la procedura di ripristino, senza un tool che la automatizzasse, potrebbe risultare difficoltosa per alcuni da mettere in pratica. Il tool facilita il ripristino e dunque rende questa analisi decisamente fuori rischio di sfruttamento malevolo.
Tralasciando i dettagli interni al ransomware, come la pulizia dei log e eventuali sistemazioni di permessi di determinati file, così come lo shutdown della VM e la compromissione delle righe crontab (per la pianificazione dei processi), vorrei concentrarmi sulla parte centrale, quella che riguarda proprio la crittografia.
In questa immagine ho selezionato il blocco di codice che applica la crittografia per compromettere la funzionalità della virtual machine.
Come si può notare lo script interviene con un ciclo for, più esterno, con il quale cerca i volumi di storage della macchina. Per ogni volume trovato effettua un altro ciclo for con il quale cerca i files presenti all’interno di quel volume.
La particolarità di questo ransomware e se vogliamo anche la sua semplicità o per meglio dire, più bassa pericolosità rispetto altri, sta proprio qui, in questo ciclo for più interno. Per bassa pericolosità intendo unicamente il fatto che l’impatto della sua azione è più limitato.
Infatti questa ricerca di files viene fatta, ma con una condizione. Vengono infatti cercati (all’interno del dato volume), tutti i file che rispondono a questo criterio:
find "/vmfs/volumes/$volume/" -type f -name "*.vmdk" -o -name "*.vmx" -o -name "*.vmxf" -o -name "*.vmsd" -o -name "*.vmsn" -o -name "*.vswp" -o -name "*.vmss" -o -name "*.nvram" -o -name "*.vmem"Questo è un criterio di ricerca che, partendo dal nome del file, seleziona quelli che riportano le stringhe elencate, ovvero tipi specifici di estensioni (.vmdk, .vmx, .vmxf ecc).
Una ricerca di questo tipo, esclude ovviamente una marea di altri file che potenzialmente sono contenuti nei volumi della virtual machine, come per esempio tutti i file di sistema oppure tutti quelli di produzione, personali, di software e qualsiasi altra cosa che non abbia una di quelle estensioni.
Per ognuno di questi file trovati, lo script esegue poi la crittografia con le istruzioni successive che stanno però, come vediamo, tutte all’interno del ciclo for più interno.
Per concludere
In definitiva questo ci fa capire come funziona questa nuova tipologia di ransomware, cosa compromette e come. Ad ogni modo il consiglio è sempre quello di evitare di avere sistemi VMware infrastrutturali esposti ad Internet. Nel caso sia strettamente necessario esporli ad Internet, averne cura negli aggiornamenti per coprire in maniera celere eventuali vulnerabilità (questa era di febbraio 2021, e successive nel 2022).
Inoltre se proprio si è caduti vittima di attacco, infettati da ESXiArgs, evitare l’eccessivo panico, proprio perché il sistema è ripristinabile e non impatta sul contenuto produttivo della virtual machine presa di mira.
