Sventato un cyberattacco russo sulla rete elettrica dell’Ucraina che avrebbe potuto mettere fuori uso la corrente a due milioni di persone. Lo riportano i funzionari ucraini. È l’attacco più importante e sofisticato finora esercitato dalla Russia in Ucraina, con un malware chiamato Industroyer2. Il primo Industroyer ha causato un blackout nelle reti elettriche ucraine nel 2016, perché è in grado di interagire con i sistemi di controllo industriale (ICS) di queste reti.
Dietro c’è il gruppo cyber russo Sandworm, anche noto come Voodoo Bear.
La vicenda conferma che l’Ucraina è diventata più abile nelle difese cyber, grazie all’aiuto degli Stati Uniti che anche in questo caso, con Microsoft, stanno indagando sull’accaduto. Ma il caso ci dice anche che la Russia sta andando verso un escalation di attacchi cyber, mentre rifocalizza la campagna di guerra sulle regioni dell’Est.
Il peggio cyber deve insomma ancora arrivare, posto che finora gli attacchi sono stati di scarsa entità e sono stati perlopiù di information war (disinformazione). E quest’allerta riguarda anche i Paesi occidentali, che stanno aiutando l’Ucraina, come da settimane dice l’Agenzia italiana per la cybersecurity.
Forse si sta entrando in una fase di vera cyberwar.
In abbinamento a Industroyer2 gli attaccanti hanno usato anche un malware wiper, CaddyWiper2 e altri.
Indice degli argomenti
L’attacco Industroyer2
Gli esperti hanno detto che l’ultimo attacco – anche se non ha avuto successo – è stato tra i più sofisticati cyberattacchi che hanno visto nella guerra finora. Ha usato una complessa catena di malware, compresi alcuni costruiti su misura per controllare i sistemi di utility. Russia aveva quindi pianificato l’attacco per diverse settimane e intendeva massimizzare il danno sabotando i sistemi informatici che sarebbero stati necessari per ripristinare la rete elettrica.
L’attacco era programmato per iniziare la sera dell’8 aprile, quando i civili tornavano a casa dal lavoro, hanno detto i funzionari ucraini, e avrebbe potuto rendere impossibile per loro andare avanti con la loro vita quotidiana o avere accesso alle informazioni sulla guerra. La violazione ha preso di mira diverse sottostazioni elettriche nel paese, e se avesse avuto successo, avrebbe privato circa due milioni di persone dell’elettricità e reso difficile il ripristino della corrente.
Baldoni: “Come stiamo gestendo la crisi Ucraina e i prossimi passi dell’Agenzia cyber”
Nelle ultime settimane, i funzionari americani hanno avvertito che la Russia potrebbe cercare di espandere la sua guerra cibernetica – forse anche interrompendo gli oleodotti e le reti elettriche americane come ritorsione per le sanzioni che gli Stati Uniti hanno imposto a Mosca.
Gli attaccanti affiliati al G.R.U., l’unità di intelligence militare della Russia, sono stati responsabili dell’attacco, utilizzando un malware simile a quello distribuito nella violazione del 2016 che ha fatto precipitare almeno 100.000 persone nel buio. I ricercatori di cybersicurezza non hanno rilevato malware simile sui sistemi informatici al di fuori dell’attacco del 2016, che è stato attribuito al G.R.U.
L’analisi tecnica
I ricercatori di ESET hanno analizzato Industroyer2. Il malware è stato distribuito come un singolo eseguibile di Windows chiamato 108_100.exe ed eseguito utilizzando un compito programmato il 2022-04-08 alle 16:10:00 UTC. È stato compilato il 2022-03-23, secondo il timestamp del PE, il che indica che gli attaccanti avevano pianificato il loro attacco per più di due settimane.
Industroyer2 a differenza del primo Industroyer implementa solo il protocollo IEC-104 (alias IEC 60870-5-104) per comunicare con le apparecchiature industriali. Qui inclusi i relè di protezione, utilizzati nelle sottostazioni elettriche. Invece la variante 2016 di Industroyer era una piattaforma completamente modulare con payload per più protocolli ICS.
Industroyer2 ha varie somiglianze di codice con il payload 104.dll di Industroyer. Secondo gli esperti può essere stato costruito utilizzando lo stesso codice sorgente.
Industroyer2 è altamente configurabile. Contiene una configurazione dettagliata hardcoded, che guida le azioni del malware. Industroyer invece memorizzava la configurazione in un file .INI separato. Pertanto, gli aggressori devono ricompilare Industroyer2 per ogni nuova vittima o ambiente.
Il nuovo formato di configurazione viene memorizzato come una stringa che viene poi fornita alla routine di comunicazione IEC-104 del malware. Industroyer2 è in grado di comunicare con più dispositivi contemporaneamente. In particolare, il campione analizzato contiene otto diversi indirizzi IP di dispositivi – vedi Figura 4.
Prima di connettersi ai dispositivi mirati, il malware termina un processo legittimo che viene utilizzato nelle operazioni standard quotidiane. Inoltre, rinomina questa applicazione aggiungendo .MZ al nome del file. Lo fa per impedire il riavvio automatico di questo processo legittimo.
L’analisi è ancora in corso per determinare quali sono le azioni esatte intraprese per ogni dispositivo. Eset crede che questo componente sia in grado di controllare specifici sistemi ICS al fine di tagliare l’alimentazione.
Industroyer2 può produrre un file di log o emettere il suo progresso nella finestra della console. Tuttavia, invece di messaggi di testo significativi come nella versione precedente, il malware scrive vari codici di errore. Secondo Eset, è un tentativo di offuscamento da parte degli sviluppatori di Sandworm per ostacolare l’analisi.
CaddyWiper2
In coordinamento con Industroyer2 nella rete ICS, gli aggressori hanno distribuito una nuova versione del malware distruttivo CaddyWiper. “Crediamo che avesse lo scopo di rallentare il processo di recupero e impedire agli operatori della società energetica di riprendere il controllo delle console ICS. È stato anche distribuito sulla macchina dove è stato eseguito Industroyer2, probabilmente per coprire le loro tracce”, scrive Eset.
La prima versione di CaddyWiper è stata scoperta dai ricercatori ESET in Ucraina il 2022-03-14 quando è stata distribuita nella rete di una banca. È stato distribuito tramite Group Policy Object (GPO), il che indica che gli attaccanti avevano già il controllo della rete dell’obiettivo. Il wiper cancella i dati degli utenti e le informazioni delle partizioni dalle unità collegate, rendendo il sistema inutilizzabile e irrecuperabile.
CaddyWiper 2 utilizza un nuovo loader, chiamato ARGUEPATCH dal CERT-UA. ARGUEPATCH è una versione patchata di un componente legittimo del software Hex-Rays IDA Pro, in particolare il server remoto IDA debugger win32_remote.exe. IDA Pro non è destinato ad essere utilizzato in un ambiente ICS, poiché il suo scopo principale è per il reverse-engineering del software, compresa l’analisi del malware. “Non sappiamo perché gli attaccanti abbiano scelto di troianizzare questo pezzo di software; potrebbe essere una trollata verso i difensori”, scrive Eset.
ARGUEPATCH è stato eseguito da un compito programmato che doveva essere lanciato una volta il 2022-04-08 14:58 UTC su una macchina e alle 16:20 UTC sulla macchina dove Industroyer2 è stato distribuito.
Il binario patchato carica lo shellcode criptato da un file e lo decripta con una chiave, entrambi sono forniti sulla linea di comando. Una chiave XOR a singolo byte è derivata dalla chiave di input e usata per decifrare lo shellcode.
Lo shellcode decrittato è una versione leggermente modificata di CaddyWiper. Un confronto delle loro routine principali è fornito nella Figura 6 e Figura 7. Notate che non puliscono il controller di dominio, e puliscono C:Users e i dischi da D: a [:. Anche la routine di cancellazione è quasi identica: riempie tutti i file con 0.
Infine, CaddyWiper chiama DeviceIoControl con IOCTL_DISK_SET_DRIVE_LAYOUT_EX e un InputBuffer azzerato per tutti i dischi da PHYSICALDRIVE9 a PHYSICALDRIVE0. Questo cancella le informazioni estese delle partizioni del disco: il Master boot record (MBR) o la GUID Partition Table (GPT). Questo rende la macchina non avviabile.
Enumerazione di Active Directory
Oltre a CaddyWiper, è stato trovato uno script PowerShell sia nella rete del fornitore di energia che nella banca compromessa in precedenza.
Questo script enumera i Group Policies Objects (GPO) utilizzando l’Active Directory Service Interface (ADSI). Lo script, mostrato nella Figura 8, è quasi identico a uno snippet fornito in un blogpost di Medium.
Malware distruttivo per Linux e Solaris (ORCSHRED, SOLOSHRED, AWFULSHRED)
Un ulteriore malware distruttivo per i sistemi che eseguono Linux e Solaris è stato trovato sulla rete dell’azienda energetica presa di mira. Ci sono due componenti principali di questo attacco: un worm e un wiper. Quest’ultimo è stato trovato in due varianti, una per ogni sistema operativo preso di mira. Tutto il malware è stato implementato in Bash.Il primo componente lanciato dall’attaccante è stato un worm, con il suo file chiamato sc.sh. Questo script Bash inizia aggiungendo un compito programmato (cron job) per lanciare il componente wiper alle 14:58 UTC (assumendo che il sistema sia nel fuso orario locale, UTC+3), a meno che non sia stato lanciato con l’argomento “owner”. Questo è probabilmente un modo per evitare che il sistema iniziale usato per lanciare il worm si autodistrugga.
Lo script poi itera sulle reti accessibili dal sistema guardando il risultato di ip route o ifconfig -a. Presume sempre che una rete di classe C (/24) sia raggiungibile per ogni indirizzo IP che raccoglie. Proverà a connettersi a tutti gli host in quelle reti usando SSH alla porta TCP 22, 2468, 24687 e 522. Una volta trovato un server SSH raggiungibile, prova le credenziali da una lista fornita con lo script maligno. Crediamo che l’attaccante avesse le credenziali prima dell’attacco per consentire la diffusione del wiper.
Se il sistema non è già compromesso, il malware viene copiato sul nuovo obiettivo e il worm viene lanciato. Il worm non viene lanciato con l’argomento proprietario, quindi il wiper è programmato per essere lanciato alle 14:58 UTC e distruggere tutti i dati. Se quei sistemi erano impostati sul fuso orario locale, la distruzione deve essere iniziata alla stessa ora del sistema compromesso con CaddyWiper.
La variante Linux del wiper è leggermente offuscata: le variabili e i nomi delle funzioni sono stati sostituiti con parole di 8 lettere senza senso. Anche la maggior parte dei valori letterali sono stati sostituiti con variabili all’inizio del file.
In definitiva, il wiper Linux distrugge l’intero contenuto dei dischi collegati al sistema utilizzando shred se disponibile o semplicemente dd (con if=/dev/random) altrimenti. Se sono collegati più dischi, la rimozione dei dati viene fatta in parallelo per accelerare il processo.
A seconda della dimensione, potrebbero essere necessarie ore per cancellare completamente l’intero disco. Per rendere il sistema inutilizzabile più velocemente, prima cerca di fermare e disabilitare i servizi HTTP e SSH. Entrambi i servizi sono disabilitati usando systemctl disable. Per assicurarsi che il servizio non venga riabilitato, il file dell’unità systemd responsabile del caricamento del servizio viene cancellato dal disco.
Anche i file di /boot, /home e /var/log vengono rimossi prima di distruggere le unità complete. Questo rende il sistema inutilizzabile più velocemente, cancella i dati dell’utente e forse rimuove i log incriminanti.
L’ultima azione dello script maligno è quella di avviare forzatamente un riavvio utilizzando SysRq. Poiché tutte le unità sono riempite a caso, nessun sistema operativo si avvierà.
A differenza del wiper Linux, la variante Solaris non è offuscata.
Come la variante Linux, lo script maligno itera su tutti i servizi per fermarli e disabilitarli se contengono la parola chiave ssh, http, apache e inoltre ora_ o oracle. Questi servizi sono molto probabilmente utilizzati da applicazioni utilizzate per controllare i sistemi ICS. Cancellarli impedirebbe agli operatori dell’azienda energetica di riprendere il controllo delle sottostazioni e di annullare le azioni di Industroyer2.
Usa systemctl o svcadm a seconda di ciò che è disponibile. Quest’ultimo è più probabile dato che Solaris non esegue systemd.
La distruzione dei file inizia cancellando i database. Rimuove, usando shred e poi rm, tutti i file e le directory contenute nelle variabili d’ambiente che iniziano con ORA. Oracle Database usa le seguenti variabili per definire la posizione dei file di database e del software: ORACLE_BASE, ORACLE_HOME e ORACLE_PATH. Si noti che shred si assicura che il recupero dei dati (senza un backup) non sia possibile.
Come la variante Linux, i file in /boot, /home e /var/log vengono cancellati con priorità.
Poi lo script itera sui dischi collegati al sistema, trovati in /dev/dsk/. Ignora le fette (partizioni) e lavora solo sui dischi completi. Per ognuno di essi, lo script maligno sovrascrive il contenuto completo utilizzando shred. Per ridurre al minimo il tempo necessario per eseguire la cancellazione, tutti i dischi vengono cancellati in parallelo.
Infine, lo script si autodistrugge.
Allerta globale
“Era un attacco che ci aspettavamo. La Russia sempre più spesso stava usando malware wiper e ora il rischio di spillover, che colpisca anche reti e computer occidentali, è altissimo”, dice al nostro giornale l’esperto cyber Pierluigi Paganini. “E infatti l’allerta è ormai globale, tra i principali Governi e Csirt”. “Aspettiamoci una escalation, con altri malware della stessa tipologia, per colpire sistemi ICS e Scada a reti elettrici, oleodotti”. “Necessario fare fronte comune ora, per evitare il peggio”, aggiunge. “La vicenda fa capire come un attore nation state è in grado di colpire qualsiasi sistema, Windows, Linux”, continua Paganini.
Nel suo blog Chris Grove, Director, Cybersecurity Strategy, Nozomi Networks ha commentato così: “Tutti coloro che operano nel settore delle infrastrutture critiche dovrebbero prestare particolare attenzione a questo attacco, perché è tra i pochi che ha colpito direttamente i sistemi OT. Secondo Nozomi Networks Labs, ci sono state segnalazioni di alcuni IP hardcoded nel campione di malware, indicazione che gli attori della minaccia avevano una conoscenza profonda dell’ambiente. Proprio come nel caso del malware che Sandworm aveva distribuito in Ucraina nel 2016, anche questa volta gli operatori ICS devono monitorare le loro reti per identificare ogni attività inconsueta poiché le tattiche russe prevedono una permanenza negli ambienti per settimane o mesi prima di colpire”.
