Ryuk è uno dei ransomware più noti degli ultimi anni. Dalla sua prima apparizione nell'estate del 2018, ha accumulato , in particolare nel settore aziendale, che è il principale obiettivo dei suoi attacchi.
1. Informazioni generali
Questo documento contiene un'analisi del ransomware Ryuk e del loader responsabile del caricamento del malware nel sistema.
Il ransomware Ryuk è apparso per la prima volta nell'estate del 2018. Una delle caratteristiche distintive di Ryuk è che si concentra sugli attacchi a contesti aziendali.
Nella metà del 2019, i gruppi di criminalità informatica hanno attaccato un numero enorme di aziende spagnole con questo ransomware.
Fig. 1: Estratto da El Confidencial riguardo l'attacco del ransomware Ryuk [1]
Fig. 2: Estratto da El País sull'attacco effettuato con il ransomware Ryuk [2]
Quest'anno Ryuk ha attaccato numerose aziende in vari paesi. Come si può vedere dalle immagini sottostanti, Germania, Cina, Algeria e India sono state le più colpite.
Confrontando il numero di attacchi informatici, possiamo notare che Ryuk ha colpito milioni di utenti e ha compromesso un'enorme quantità di dati, causando gravi danni economici.
Fig. 3: Illustrazione dell'attività globale di Ryuk.
Fig. 4: 16 paesi maggiormente colpiti da Ryuk
Fig. 5: Numero di utenti attaccati dal ransomware Ryuk (in milioni)
Secondo il consueto funzionamento di minacce simili, questo ransomware, dopo aver completato la crittografia, mostra alla vittima una notifica di riscatto che deve essere pagata in bitcoin all'indirizzo indicato per ripristinare l'accesso ai file crittografati.
Questo malware si è evoluto da quando è apparso per la prima volta.
La variante di questa minaccia analizzata in questo documento è stata rilevata durante un tentativo di attacco a gennaio 2020.
A causa della sua complessità, questo malware è spesso attribuito a gruppi di criminalità informatica organizzati, noti anche come gruppi APT.
Una parte del codice di Ryuk mostra una notevole somiglianza con il codice e la struttura di un altro noto ransomware, Hermes, con cui condivide diverse funzionalità. Proprio per questo motivo, inizialmente si pensava che Ryuk fosse collegato al gruppo nordcoreano Lazarus, che all'epoca era sospettato di essere dietro il ransomware Hermes.
Successivamente, il servizio Falcon X di CrowdStrike ha osservato che in effetti Ryuk era stato creato dal gruppo WIZARD SPIDER [4].
Ci sono diverse prove a sostegno di questa ipotesi. Innanzitutto, questo ransomware è stato pubblicizzato sul sito web exploit.in, che è un noto mercato russo di malware ed è stato precedentemente collegato a diversi gruppi APT russi.
Questo fatto esclude la teoria che Ryuk possa essere stato sviluppato dal gruppo APT Lazarus, poiché non corrisponde al modo in cui opera il gruppo.
Inoltre, Ryuk è stato pubblicizzato come un ransomware che non funzionerà su sistemi russi, ucraini e bielorussi. Questo comportamento è definito da una funzione, rilevata in alcune versioni di Ryuk, in cui controlla la lingua del sistema su cui è in esecuzione il ransomware e ne interrompe il funzionamento se il sistema è in russo, ucraino o bielorusso. Infine, durante l'analisi forense della macchina compromessa dal gruppo WIZARD SPIDER, sono stati trovati diversi "artefatti" che presumibilmente sono stati utilizzati nello sviluppo di Ryuk come variante del ransomware Hermes.
D'altra parte, gli esperti Gabriela Nicolo e Luciano Martins hanno ipotizzato che il ransomware potrebbe essere stato sviluppato dal gruppo APT CryptoTech [5].
Questo si deduce dal fatto che alcuni mesi prima dell'apparizione di Ryuk, questo gruppo aveva pubblicato sul forum dello stesso sito informazioni relative allo sviluppo di una nuova versione del ransomware Hermes.
Alcuni utenti del forum si sono chiesti se CryptoTech abbia davvero creato Ryuk. Dopo ciò, questo gruppo si è difeso affermando di avere prove di aver sviluppato il 100% di questo ransomware.
2. Caratteristiche
Iniziamo con il caricatore, il cui compito è identificare il sistema in cui si trova, in modo da poter avviare la versione "corretta" del ransomware Ryuk.
L'hash del caricatore è il seguente:
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
Una delle caratteristiche di questo caricatore è che non contiene metadati, ovvero i creatori di questo malware non hanno incluso alcuna informazione.
A volte includono dati errati per indurre l'utente a pensare di star eseguendo un'applicazione legittima. Tuttavia, come vedremo più avanti, nel caso in cui l'infezione non preveda l'interazione dell'utente (come in questo caso del ransomware), gli aggressori non ritengono necessario utilizzare metadati.
Fig. 6: Metadati del campione
Il campione è stato compilato nel formato a 32 bit, in modo da poter essere eseguito sia su sistemi a 32 bit che a 64 bit.
3. Vettore di attacco
Il campione che carica e avvia Ryuk è entrato nel nostro sistema tramite una connessione remota, e le credenziali di accesso sono state ottenute grazie a un attacco RDP preliminare.
Fig. 7: Registro dell'attacco
L'attaccante è riuscito a entrare nel sistema da remoto. Successivamente, ha creato un file eseguibile con il nostro campione.
Questo file eseguibile è stato bloccato dalla soluzione antivirus prima dell'esecuzione.
Fig. 8: Blocco del campione
Fig. 9: Blocco del campione
Quando il file dannoso è stato bloccato, l'attaccante ha tentato di caricare una versione crittografata del file eseguibile, che è stata anch'essa bloccata.
Fig. 10: Set di campioni che l'attaccante ha tentato di avviare
Infine, ha tentato di caricare un altro file dannoso tramite una console crittografata
PowerShell per eludere la protezione antivirus. Ma anche questo è stato bloccato.
Fig. 11: PowerShell con contenuto dannoso bloccato
Fig. 12: PowerShell con contenuto dannoso bloccato
4. Loader
Quando viene eseguito, scrive un file ReadMe nella cartella %temp%, che è tipico di Ryuk. Questo file è un riscatto che contiene un indirizzo email nel dominio protonmail, che è piuttosto comune in questa famiglia di malware: msifelabem1981@protonmail.com
Fig. 13: Richiesta di riscatto
Durante l'esecuzione del loader, puoi vedere che avvia diversi file eseguibili con nomi casuali. Sono memorizzati in una cartella nascosta PUBLIC, ma se l'opzione nel sistema operativo non è attiva «Mostra file e cartelle nascoste», rimarranno nascosti. Inoltre, questi file sono a 64 bit a differenza del file principale, che è a 32 bit.
Fig. 14: File eseguibili avviati dal campione
Come puoi vedere nell'immagine sopra, Ryuk avvia icacls.exe, che verrà utilizzato per modificare tutte le liste di controllo degli accessi ACL (Access Control List), garantendo così accesso e modifica dei flag.
Ottiene accesso completo da tutti gli utenti a tutti i file sul dispositivo (/T) indipendentemente dagli errori (/C) e senza mostrare alcun messaggio (/Q).
Fig. 15: Parametri di esecuzione di icacls.exe avviati da un campione
È importante considerare che Ryuk verifica quale versione di Windows è in esecuzione. Per farlo,
esegue un controllo della versione tramite GetVersionExW, nel quale verifica il valore del flag lpVersionInformation, che mostra se l'attuale versione di Windows è successiva a Windows XP.
A seconda che tu stia utilizzando una versione più recente di Windows XP, il caricatore registrerà nella cartella dell'utente locale — in questo caso, nella cartella %Public%.
Fig. 17: Controllo della versione del sistema operativo
Il file registrato è Ryuk. Successivamente, lo avvia passando il proprio indirizzo come parametro.
Fig. 18: Esecuzione di Ryuk tramite ShellExecute
La prima cosa che fa Ryuk è ottenere i parametri di ingresso. Questa volta ci sono due parametri di ingresso (il file eseguibile stesso e l'indirizzo del dropper) che vengono utilizzati per eliminare le proprie tracce.
Fig. 19: Creazione del processo
Puoi anche vedere che una volta avviati i suoi file eseguibili, si elimina, in questo modo non lasciando tracce della propria presenza nella cartella in cui è stato eseguito.
Fig. 20: Eliminazione del file
5. RYUK
5.1 Presenza
Ryuk, come altri malware, cerca di rimanere nel sistema il più a lungo possibile. Come mostrato in precedenza, uno dei modi per raggiungere questo obiettivo è creare e avviare in modo furtivo file eseguibili. Per fare ciò, la pratica più comune è modificare la chiave di registro CurrentVersionRun.
In questo caso, puoi vedere che per questo scopo il primo file eseguibile VWjRF.exe
(il nome del file è generato casualmente) avvia cmd.exe.
Fig. 21: Esecuzione del file VWjRF.exe
Poi viene inserito il comando RUN con il nome "svchos". In questo modo, se desideri controllare in qualsiasi momento le chiavi di registro, potresti facilmente non notare questa modifica, considerando la somiglianza di questo nome con svchost. Grazie a questa chiave, Ryuk garantisce la sua presenza nel sistema. Se il sistema non è ancora stato infettato, quando riavvii il sistema, il file eseguibile tenterà di nuovo.
Fig. 22: Esempio di presenza nella chiave di registro
Possiamo anche vedere che questo file eseguibile ferma due servizi:
"audioendpointbuilder", che come suggerisce il nome, corrisponde all'audio di sistema,
Fig. 23: Il campione interrompe il servizio audio di sistema
e samss, che è un servizio di gestione degli account. La sospensione di questi due servizi è una caratteristica di Ryuk. In questo caso, se il sistema è collegato a un sistema SIEM, il ransomware tenta di fermare l'invio di eventuali avvisi. In questo modo, protegge i propri passaggi successivi, poiché alcuni servizi SAM non riusciranno a iniziare correttamente dopo l'esecuzione di Ryuk.
Fig. 24: Il campione interrompe il servizio Samss
5.2 Privilegi
In generale, Ryuk inizia con un movimento orizzontale all'interno della rete oppure viene avviato da un'altra malware, come o , che nel caso di un'escensione dei privilegi trasferiscono questi diritti elevati al ransomware.
In anticipo, come preludio al processo di infiltrazione, vediamo che esegue il processo ImpersonateSelf, il che significa che il contenuto della sicurezza del token di accesso verrà trasferito nel thread, dove sarà immediatamente ricevuto tramite GetCurrentThread.
Fig. 25: Chiamata a ImpersonateSelf
Poi vediamo che collegherà il token di accesso al thread. Vediamo anche che uno dei flag è DesiredAccess, che può essere utilizzato per controllare l'accesso che avrà il thread. In questo caso, il valore che otterrà edx dovrebbe essere TOKEN_ALL_ACCESS o in alternativa TOKEN_WRITE.
Figura 26: Creazione del token del thread
Poi utilizzerà SeDebugPrivilege e farà una chiamata per ottenere i diritti di debug rispetto al thread, specificando così PROCESS_ALL_ACCESS, sarà in grado di accedere a qualsiasi processo necessario. Ora, considerando che il ransomware ha già preparato il thread, rimane solo iniziare la fase finale.
Figura 27: Chiamata a SeDebugPrivilege e funzione di escalation dei privilegi
Da un lato, abbiamo LookupPrivilegeValueW, che ci fornisce le informazioni necessarie sui privilegi che vogliamo aumentare.
Figura 28: Richiesta di informazioni sui privilegi per la loro escalation
Dall'altro lato, abbiamo AdjustTokenPrivileges, che consente di ottenere i diritti necessari per il nostro thread. In questo caso, la cosa più importante è NewState, il cui flag fornirà i privilegi.
Figura 29: Configurazione dei diritti per il token
5.3 Implementazione
In questa sezione mostreremo come un campione esegue il processo di iniezione menzionato in precedenza in questo rapporto.
L'obiettivo principale del processo di iniezione, così come dell'escalation, è ottenere accesso a copia shadow. Per fare ciò, deve lavorare con un flusso con privilegi superiori a quelli dell'utente locale. Non appena ottiene tali privilegi più elevati, eliminerà le copie e apporterà modifiche ad altri processi per rendere impossibile il ritorno a un punto di ripristino precedente nel sistema operativo.
Come accade di solito con questo tipo di malware, per eseguire l'iniezione utilizza CreateToolHelp32Snapshot, quindi effettua uno snapshot dei processi attualmente in esecuzione e cerca di accedere a questi processi tramite OpenProcess. Una volta ottenuto l'accesso al processo, apre anche un token con le sue informazioni per ottenere i parametri del processo.
Fig. 30: Ottenimento dei processi dal computer
Possiamo vedere dinamicamente come ottiene l'elenco dei processi in esecuzione nel thread 140002D9C utilizzando CreateToolhelp32Snapshot. Dopo averli ottenuti, scorre l'elenco cercando di aprire i processi uno per uno tramite OpenProcess finché non riesce a farlo. In questo caso, il primo processo che è riuscito a aprire è «taskhost.exe».
Fig. 31: Esecuzione dinamica della procedura per ottenere il processo
Possiamo vedere che successivamente legge le informazioni sul token del processo, quindi chiama OpenProcessToken con il parametro "20008"
Fig. 32: Lettura delle informazioni sul token del processo
Controlla anche che il processo in cui intende iniettare non sia csrss.exe, explorer.exe, lsaas.exe o che abbia un insieme di diritti NT authority.
Fig. 33: Processi esclusi
Possiamo vedere dinamicamente come inizialmente esegue un controllo utilizzando le informazioni sul token del processo in 140002D9C per scoprire se l'account i cui diritti vengono utilizzati per eseguire il processo è un account NT AUTHORITY.
Fig. 34: Verifica di NT AUTHORITY
Successivamente, al di fuori della procedura, controlla che non sia csrss.exe, explorer.exe o lsaas.exe.
Fig. 35: Verifica di NT AUTHORITY
Dopo aver acquisito uno snapshot dei processi, ha aperto i processi e verificato che nessuno di essi fosse eccezionale, è pronto a registrare in memoria i processi che verranno iniettati.
Per fare ciò, prima prenota un'area in memoria (VirtualAllocEx), la scrive (WriteProcessMemory) e crea un thread (CreateRemoteThread). Per lavorare con queste funzioni utilizza i PID dei processi scelti, che ha precedentemente ottenuto tramite CreateToolhelp32Snapshot.
Fig. 36: Codice per l'iniezione
Qui possiamo osservare dinamicamente come utilizza il PID del processo per chiamare la funzione VirtualAllocEx.
Fig. 37: Chiamata a VirtualAllocEx
5.4 Crittografia
In questa sezione esamineremo una parte di questo campione relativa alla crittografia. Nell'immagine seguente puoi vedere due sottofunzioni chiamate "LoadLibrary_EncodeString" e "Encode_Func", che sono responsabili dell'esecuzione della procedura di crittografia.
Fig. 38: Procedure di crittografia
Inizialmente possiamo vedere come carica una stringa, che verrà utilizzata in seguito per deoffuscare tutto ciò che è necessario: importazioni, DLL, comandi, file e CSP.
Fig. 39: Catena di deoffuscamento
Nella figura seguente viene mostrato il primo import, che viene deobfuscato nel registro R4, LoadLibrary. Questo sarà usato in seguito per caricare i necessari DLL. Possiamo anche vedere un'altra stringa nel registro R12, che viene utilizzata insieme alla stringa precedente per eseguire la deobfuscazione.
Fig. 40: Deobfuscazione dinamica
Continua a caricare i comandi che eseguirà in seguito per disabilitare le copie di backup, i punti di ripristino e le modalità di avvio sicuro.
Fig. 41: Caricamento dei comandi
Poi carica la posizione in cui depositerà 3 file: Windows.bat, run.sct e start.bat.
Fig. 42: Posizioni dei file
Questi 3 file sono utilizzati per verificare i privilegi di cui dispone ciascuna delle posizioni. Se i privilegi richiesti non sono disponibili, Ryuk interrompe l'esecuzione.
Continua a caricare le stringhe corrispondenti ai tre file. Il primo, DECRYPT_INFORMATION.html, contiene le informazioni necessarie per il recupero dei file. Il secondo, PUBLIC, contiene la chiave pubblica RSA.
Fig. 43: Stringa DECRYPT INFORMATION.html
Il terzo, UNIQUE_ID_DO_NOT_REMOVE, contiene la chiave crittografata che verrà utilizzata nella prossima sottoprogramma per eseguire la crittografia.
Fig. 44: UNIQUE ID DO NOT REMOVE
Infine, carica le librerie necessarie insieme alle importazioni richieste e CSP (Microsoft Enhanced RSA e AES Cryptographic Provider).
Fig. 45: Caricamento delle librerie
Una volta completata la deoffuscazione, passa a eseguire le operazioni necessarie per la crittografia: scansiona tutti i dischi logici, esegue ciò che è stato caricato nel sottoprogramma precedente, rafforza la presenza nel sistema, crea il file RyukReadMe.html, crittografa, scansiona tutti i dischi di rete, accede ai dispositivi rilevati e li crittografa.
Tutto inizia caricando "cmd.exe" e registrando la chiave RSA pubblica.
Fig. 46: Preparativi per la crittografia
Poi ottiene tutti i dischi logici usando GetLogicalDrives e disattiva tutti i backup, i punti di ripristino e le modalità di avvio sicure.
Fig. 47: Disattivazione degli strumenti di ripristino
Successivamente, rinforza la sua presenza nel sistema, come abbiamo visto sopra, e crea il primo file RyukReadMe.html in TEMP.
Fig. 48: Pubblicazione della richiesta di riscatto
Nella figura successiva puoi vedere come crea un file, carica il contenuto e lo registra:
Fig. 49: Caricamento e registrazione del contenuto del file
Per poter eseguire queste stesse azioni su tutti i dispositivi, utilizza
"icacls.exe", come mostrato sopra.
Fig. 50: Utilizzo di icacls.exe
Infine, inizia la crittografia dei file, ad eccezione dei file "*.exe", "*.dll", dei file di sistema e di altre posizioni specificate in un elenco bianco crittografato. Per questo utilizza le importazioni: CryptAcquireContextW (in cui è specificato l'uso di AES e RSA), CryptDeriveKey, CryptGenKey, CryptDestroyKey ecc. Viene anche tentato di estendere la propria azione a dispositivi di rete rilevati tramite WNetEnumResourceW e quindi crittografarli.
Fig. 51: Crittografia dei file di sistema
6. Importazioni e flag corrispondenti
Di seguito è riportata una tabella con l'elenco delle importazioni e dei flag più pertinenti utilizzati dal campione:
7. IOC
Link
- usersPublicrun.sct
- Start MenuProgramsStartupstart.bat AppDataRoamingMicrosoftWindowsStart
- MenuProgramsStartupstart.bat
Il rapporto tecnico sul ransomware Ryuk è stato redatto da esperti del laboratorio antivirus PandaLabs.
8. Riferimenti
1. “Everis e Prisa Radio subiscono un grave attacco informatico che sequestra i loro sistemi.” https://www.elconfidencial.com/tecnologia/2019-11-04/everis-la-ser-ciberataque-ransomware-15_2312019/, Pubblicato il 04/11/2019.
2. “Un virus di origine russa attacca importanti aziende spagnole.”https://elpais.com/tecnologia/2019/11/04/actualidad/1572897654_251312.html, Pubblicata il 04/11/2019.
3. “Articolo VB2019: La vendetta di Shinigami: la lunga scia del malware Ryuk.”https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Pubblicata l'11/12/2019.
4. “Big Game Hunting con Ryuk: un altro obiettivo mirato redditizio.”https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Pubblicata il 10/01/2019.
5. “Articolo VB2019: La vendetta di Shinigami: la lunga scia del malware Ryuk.”https://www.virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r
Fonte: habr.com
