È molto più semplice cambiare l’aspetto (oppure offuscare il codice) di un ransomware, che modificarne gli obiettivi o i comportamenti principali. Dopotutto, il ransomware è costretto a rivelare le proprie intenzioni quando sferra il proprio attacco.
Tuttavia, ci sono tratti comportamentali comunemente esibiti dal ransomware che il software di sicurezza può utilizzare per stabilire se il programma è malevolo. Alcuni tratti (ad esempio la cifratura dei documenti subito dopo l’esecuzione) sono difficili da modificare per i cyber criminali.
L’autore del ransomware WastedLocker ha astutamente escogitato una serie di manovre che servono a eludere il rilevamento e a confondere le soluzioni antiransomware basate sui comportamenti.
Di seguito descriveremo alcuni di questi stratagemmi, ma è bene sottolineare anche che l’analisi del codice svolta su WastedLocker mostra un’ulteriore caratteristica inattesa: alcune delle tecniche utilizzate dal ransomware WastedLocker per offuscarne il codice e svolgere alcune operazioni sono molto simili a subroutine che abbiamo osservato in un altro ransomware (Bitpaymer) e nel trojan Dridex. A nostro avviso, le analogie sono troppo marcate per essere una coincidenza.
Indice degli argomenti
Ransomware WastedLocker: l’elusione assume il ruolo principale
Gli autori del ransomware sono consci del fatto che i controlli di sicurezza della rete e degli endpoint rappresentano una minaccia letale per qualsiasi attacco, per cui hanno sviluppato un’ossessione nel trovare una logica complessa che sia in grado di rilevare e sabotare questi controlli. Il ransomware attuale impiega diverso tempo a cercare di eludere i controlli di sicurezza.
Nella maggior parte dei casi, le evoluzioni che abbiamo osservato nello sviluppo del ransomware possono essere classificate come tecniche di sopravvivenza che permettono al ransomware di nascondere la sua presenza per il tempo necessario per cifrare i file della vittima selezionata.
Per raggiungere questo obiettivo, gli hacker devono accertarsi che i sistemi dinamici di protezione endpoint non riescano a stabilire la natura di un file in base al relativo aspetto o codice; inoltre, devono mettere fuori strada gli strumenti di rilevamento basati sui comportamenti quando cercano di determinare la causa originale del comportamento malevolo.
Molte famiglie di malware sfruttano tecniche di offuscamento del codice, come ad es. i runtime packer, per depistare le indagini, ma alcune si sono spinte oltre. Bitpaymer, ad esempio, si serve di una metodologia unica nel suo genere, che chiama le funzioni API di Windows utilizzando un hash di chiamata di funzione invece della chiamata stessa.
Sembra che WastedLocker abbia adottato la stessa tecnica, aggiungendo un livello extra di offuscamento eseguendo l’intera operazione nella memoria, dove è più difficile che venga identificato dal rilevamento basato sui comportamenti.
Nel corso degli anni, i comportamenti del ransomware in termini di file system sono generalmente rimasti coerenti (ad esempio, quest’anno gli attacchi di Ryuk e REvil hanno mostrato gli stessi comportamenti di CryptoLocker del 2013 per quanto riguarda il file system).
Di solito i sistemi di difesa antiransomware basati sul monitoraggio dei comportamenti sono realizzati in modo da individuare questa tipica attività universale. Oggi, tuttavia, le cose sono leggermente diverse, per cui devono cambiare anche le tattiche che utilizziamo per rilevare questi comportamenti.
Usare la memoria per eludere il monitoraggio basato sui comportamenti
Prima di analizzare gli stratagemmi degli hacker, occorre sottolineare che di solito i sistemi di difesa antiransomware basati sul monitoraggio dei comportamenti utilizzano un driver minifiltro.
I driver minifiltro sono driver del kernel che si connettono allo stack del file system. I minifiltri filtrano le operazioni I/O per tenere d’occhio tutto quello che succede ai file. Ad esempio, la nota utilità Monitoraggio processi di Sysinternals si serve di un driver minifiltro per creare un log in tempo reale dell’attività del file system. La maggior parte delle soluzioni antiransomware adotta un approccio simile per monitorare le attività che riguardano i file.
WastedLocker utilizza uno stratagemma che impedisce alle soluzioni antiransomware basate sui comportamenti di tenere d’occhio quello che accade, in quanto sfrutta le operazioni I/O mappate alla memoria per cifrare i file.
Sebbene il ransomware non abbia necessariamente bisogno di accedere ai documenti come file mappati alla memoria (Memory-Mapped File, MMF), ultimamente questo metodo è diventato più comune e Maze e Clop adottano la stessa tattica.
Questa tecnica permette al ransomware di cifrare in maniera invisibile i documenti situati nella cache direttamente nella memoria, senza generare ulteriori operazioni di I/O su disco.
Per il monitoraggio dei comportamenti, questo potrebbe essere un problema.
Gli strumenti utilizzati per monitorare le attività di scrittura su disco potrebbero non notare che il ransomware sta effettuando l’accesso a un documento nella cache, perché i dati vengono forniti dalla memoria, invece che dal disco.
Il colpo di scena è che WastedLocker chiude il file una volta che lo ha mappato alla memoria. Si potrebbe pensare che questo genererebbe un errore, ma non è così, in quanto la Gestione cache di Windows apre un handle al file una volta che viene mappato alla memoria.
Il Lazy writer della Gestione cache
La Gestione cache è un componente del kernel situato tra il file system e la Gestione memoria. Se un processo accede alla memoria mappata, la Gestione memoria emette un errore di pagina e la Gestione cache legge i dati necessari dal disco, immettendoli in memoria.
Più viene effettuato l’accesso alla memoria, maggiore sarà il numero di pagine lette dal disco e immesse in memoria tramite un processo che si chiama paging I/O.
La Gestione memoria monitora anche la memoria che viene modificata, ovvero le pagine “dirty”. Se un processo cifra la memoria mappata, la Gestione memoria riconosce quali pagine devono essere nuovamente scritte su disco. La scrittura avviene per mezzo del Lazy writer della Gestione cache.
La Gestione cache implementa una cache write-back con scrittura lenta. Questo significa che viene permesso un accumulo temporaneo di pagine dirty, che vengono poi scaricate su disco contemporaneamente, riducendo la quantità complessiva di operazioni I/O su disco.
Inoltre, la scrittura non viene effettuata nel contesto del processo, bensì del sistema (PID 4). È un aspetto che può essere problematico per le soluzioni antiransomware, in quanto complica l’identificazione del processo che ha scritto sul file.
Ransomware WastedLocker: ulteriori complicazioni
Il ransomware WastedLocker chiude il suo handle di file subito dopo aver mappato il file alla memoria. Le viste mappate di un oggetto di mapping dei file mantengono riferimenti interni all’oggetto e un oggetto di mapping dei file non viene chiuso fino a quando non siano stati rilasciati tutti i riferimenti allo stesso.
Pertanto, per chiudere completamente un oggetto di mapping dei file, un’applicazione deve annullare il mapping di tutte le viste mappate dell’oggetto di mapping dei file, chiamando il comando UnmapViewOfFile e chiudendo l’handle dell’oggetto di mapping dei file chiamando il comando CloseHandle.
Queste funzioni possono essere chiamate in qualsiasi ordine. Le soluzioni antiransomware che correlano le attività basate sulle operazioni CreateFile e CloseFile non sono in grado di rilevare le operazioni di I/O su disco effettuate dalla Gestione cache in risposta a operazioni svolte nella memoria mappata.
Come ultima cosa, la Gestione cache rilascerà il proprio handle interno per il file mappato alla memoria. Questo potrebbe avvenire entro pochi minuti, ma abbiamo notato che la Gestione cache chiude l’handle solamente dopo diverse ore.
L’evoluzione del codice da un’origine imprevista
È interessante vedere come un’analisi del codice di WastedLocker abbia dato origine all’ipotesi che potrebbe trattarsi di un discendente evoluto di Bitpaymer.
Gli analisti che conoscono entrambi hanno osservato analogie degne di nota (potenzialmente persino codice riscritto) che sembrano essere molto più di una semplice coincidenza.
Abuso di Alternate Data Streams (ADS)
Sia Bitpaymer che WastedLocker sono caratterizzati dallo stesso utilizzo improprio di ADS: Il malware trova un file di sistema pulito, si copia nel flusso di dati alternativi del file pulito e si esegue come componente del servizio di questo file pulito. Dà così l’impressione che all’origine del comportamento del ransomware ci sia il file pulito.
Entrambi i ransomware ottengono questo risultato utilizzando la stessa tecnica: reimpostano i privilegi del file di sistema attaccato utilizzando icacls.exe per aggiungere il componente ADS e successivamente copiano il file di sistema pulito nella cartella %APPDATA%.
Metodo di risoluzione di API personalizzate
Bitpaymer utilizza le funzioni di risoluzione di API personalizzate per chiamare API Windows utilizzando un valore hash, piuttosto che il nome della funzione API.
Lo stesso codice veniva utilizzato anche dal malware Dridex ed è stato osservato varie volte in molte varianti meno recenti di Bitpaymer. L’autore di WastedLocker ha introdotto un importante upgrade della base di codici, rimuovendo queste funzioni.
Ora le API Windows vengono chiamate direttamente nella memoria.
Questo cambiamento ha migliorato l’efficienza dell’esecuzione del malware, senza che occorra investire troppo tempo nella compilazione dell’hash e nella chiamata dinamica delle API.
Siccome la funzione Resolve delle API viene chiamata in tutte le chiamate API, il codice della funzione dal comportamento simile aveva un aspetto completamente diverso durante le analisi.
Elusione del Controllo dell’account utente
Entrambi i ransomware utilizzano una tecnica di elusione del Controllo dell’account utente per fare in modo che il processo pulito e compromesso ottenga privilegi elevati ed esegua il codice del ransomware (utilizzando la tecnica ADS descritta sopra).
Bitpaymer aggiunge un file .cmd file alla chiave di registro ("HKCUSoftwareClassesmscfileshellopencommand"), in modo tale che, quando un file eventvwr.exe viene eseguito con privilegi elevati, controlli la chiave di registro (per impostazione predefinita) e che, a sua volta, avvii il file .cmd che esegue il file binario del ransomware.
Nel caso di WastedLocker, winsat.exe e winmm.dll vengono utilizzati per eseguire il file binario del ransomware (componente ADS) applicando una patch a winmm.dll.
Metodi di cifratura
Nel tempo, Bitpaymer ha migliorato il metodo di cifratura utilizzato.
Le prime varianti di Bitpaymer si servivano di una chiave RC4 per cifrare i contenuti dei file e la chiave RC4 veniva ulteriormente cifrata con una chiave pubblica RSA a 1024 bit.
Le varianti successive di Bitpaymer (nonché le versioni attuali di WastedLocker) hanno apportato dei miglioramenti, utilizzando la modalità CBC AES a 256 bit per la cifratura dei file, insieme a una chiave pubblica RSA a 4096 bit.
Entrambi i ransomware, inoltre, codificano le informazioni delle chiavi con Base64 e memorizzano la chiave codificata nel messaggio di riscatto
Composizione del messaggio di riscatto
Entrambi personalizzano il messaggio per ogni vittima, includendovi il nome dell’organizzazione. WastedLocker specifica l’organizzazione anche nel nome della nota di riscatto, aggiungendovi un prefisso.
Stile simile per gli argomenti della riga di comando
WastedLocker è in grado di svolgere certe operazioni quando il suo principale file eseguibile viene aperto con argomenti specifici, esattamente come alcune delle versioni meno recenti di Bitpaymer.
Ambedue i malware utilizzano come argomenti dei numeri e i numeri che indicano l’operazione che il malware deve compiere sono gli stessi (ad es. -1 indica l’esecuzione principale/iniziale, -2 emette un comando che copia il malware e lo esegue utilizzando ADS e -3 indica l’avvio del processo di cifratura).
Sebbene nessuno di questi punti, da solo o insieme ad altri fattori, sia abbastanza per confermare con certezza che, ad esempio, tutti e due i ransomware hanno lo stesso autore, il numero di analogie è talmente impressionante da far sorgere il dubbio che il o gli autori di Bitpaymer e WastedLocker possano avere quanto meno un rapporto di collaborazione.
