Gli operatori del ransomware Ryuk ci sono di nuovo. Dopo un lungo periodo di quiete, abbiamo identificato una nuova campagna di spam legata agli attori di Ryuk – parte di una nuova ondata di attacchi. E alla fine di settembre, il team Managed Threat Response di Sophos ha assistito un’organizzazione nella mitigazione di un attacco Ryuk, fornendo informazioni su come gli strumenti, le tecniche e le pratiche degli attori di Ryuk si siano evoluti. L’attacco fa parte di una recente ondata di incidenti Ryuk legati a recenti campagne di phishing.

Prima individuata nell’agosto del 2018, la banda Ryuk ha guadagnato notorietà nel 2019, chiedendo riscatti multimilionari ad aziende, ospedali ed enti locali. Nel processo, gli operatori del ransomware hanno tirato dentro oltre 61 milioni di dollari solo negli Stati Uniti, secondo le cifre del Federal Bureau of Investigation. E questo è solo quello che è stato riportato – altre stime collocano il guadagno di Ryuk nel 2019 in centinaia di milioni di dollari.

A partire dall’inizio della pandemia mondiale di COVID-19, abbiamo visto una pausa nell’attività di Ryuk. Ci sono state speculazioni sul fatto che gli attori di Ryuk fossero passati a una versione ribattezzata del ransomware, chiamata Conti. La campagna e l’attacco su cui abbiamo indagato è stato interessante sia perché ha segnato il ritorno di Ryuk con alcune modifiche minori, ma ha anche mostrato un’evoluzione degli strumenti utilizzati per compromettere le reti mirate e distribuire il ransomware.

L’attacco è stato anche notevole per la velocità con cui gli attacchi possono passare dalla compromissione iniziale alla distribuzione del ransomware. Entro tre ore e mezza dall’apertura dell’allegato di una e-mail di phishing da parte di un obiettivo, gli aggressori stavano già conducendo una ricognizione della rete. Entro un giorno, avevano ottenuto l’accesso a un controller di dominio, ed erano nelle prime fasi di un tentativo di distribuire il ransomware.

Gli attaccanti erano anche persistenti. Poiché i tentativi di lanciare l’attacco sono falliti, gli attori di Ryuk hanno tentato più volte nel corso della settimana successiva di installare nuovo malware e ransomware, compresi nuovi tentativi di phishing per ristabilire un punto d’appoggio. Prima che l’attacco si concludesse, oltre 90 server e altri sistemi sono stati coinvolti nell’attacco, anche se il ransomware è stato bloccato dalla piena esecuzione.

Fate entrare quello sbagliato

Fase iniziale di compromissione, ricognizione e movimento laterale dell’attacco Ryuk

L’attacco è iniziato nel pomeriggio di martedì. 22 settembre. Diversi dipendenti della società presa di mira avevano ricevuto e-mail di phishing altamente mirate:

Da: Alex Collins

A:

Soggetto: Re: about debit

Per favore richiamami fino alle 2 PM, sarò in ufficio fino alle 2 PM.

, a causa della richiesta della sede centrale #96-9/23, elaborerò ulteriori 3.582 dal tuo conto del libro paga.

, richiamami quando sarai disponibile per confermare che tutto è corretto.

Ecco una copia del tuo estratto conto in PDF.

Alex Collins

specialista in outsourcing

Il link, servito attraverso il servizio di consegna della posta Sendgrid, ha reindirizzato a un documento dannoso ospitato su docs.google.com. L’e-mail è stata contrassegnata con avvisi di mittente esterno dal software di posta della società. E più istanze dell’allegato dannoso sono state rilevate e bloccate.

Ma un dipendente ha cliccato sul link nella mail quel pomeriggio. L’utente ha aperto il documento e abilitato il suo contenuto, permettendo al documento di eseguire print_document.exe-un eseguibile maligno identificato come Buer Loader. Buer Loader è un downloader modulare malware-as-a-service, introdotto sui forum underground per la vendita nell’agosto del 2019. Fornisce un servizio di distribuzione di malware gestito da un pannello web; ogni build del downloader è venduta per $ 350, con moduli aggiuntivi e modifiche all’indirizzo di download fatturati separatamente.

In questo caso, all’esecuzione, il malware Buer Loader ha lasciato cadere qoipozincyusury.exe, un “beacon” Cobalt Strike, insieme ad altri file malware. Il beacon di Cobalt Strike, originariamente progettato per l’emulazione degli attaccanti e i test di penetrazione, è uno strumento di attacco modulare che può eseguire una vasta gamma di compiti, fornendo l’accesso alle funzioni del sistema operativo e stabilendo un canale di comando e controllo segreto all’interno della rete compromessa.

Nell’ora e mezza successiva, sono stati rilevati altri beacon Cobalt Strike sul sistema inizialmente compromesso. Gli aggressori sono stati quindi in grado di stabilire con successo un punto d’appoggio sulla workstation bersaglio per la ricognizione e per la caccia alle credenziali.

Poche ore dopo, è iniziata la ricognizione della rete da parte degli attori Ryuk. I seguenti comandi sono stati eseguiti sul sistema inizialmente infetto:

  • C:\WINDOWS\system32\cmd.exe /C whoami /groups (accesso alla lista dei gruppi AD in cui si trova l’utente locale)
  • C:\WINDOWS\system32\cmd.exe /C nltest /domain_trusts /all_trusts (restituisce un elenco di tutti i domini affidabili)
  • C:\WINDOWS\system32\cmd.exe /C net group “enterprise admins” /domain (restituisce un elenco di membri del gruppo “enterprise admins” per il dominio)
  • C:\WINDOWS\system32\net1 group “domain admins” /domain (lo stesso, ma un elenco del gruppo “domain admins”)
  • C:\WINDOWS\system32\cmd.exe /C net localgroup administrators (restituisce un elenco di amministratori per la macchina locale)
  • C:\WINDOWS\system32\cmd.exe /C ipconfig (restituisce la configurazione di rete)
  • C:\WINDOWS\system32\cmd.exe /C nltest /dclist: (restituisce i nomi dei controller di dominio per il nome del dominio aziendale)
  • C:\WINDOWS\system32\cmd.exe /C nltest /dclist: (lo stesso, ma controllando i controller di dominio che utilizzano il nome della società come nome di dominio)

Forward lateral

Utilizzando questi dati, mercoledì mattina gli attori hanno ottenuto le credenziali amministrative e si sono collegati a un controller di dominio, dove hanno eseguito un dump dei dati di Active Directory. Questo è stato molto probabilmente realizzato attraverso l’uso di SharpHound, uno strumento di “injestor” di dati basato su Microsoft C# per BloodHound (uno strumento di analisi open-source di Active Directory utilizzato per identificare i percorsi di attacco in ambienti AD). Un dump di dati dallo strumento è stato scritto in una directory utente per l’account di amministratore di dominio compromesso sul server di dominio stesso.

Un altro eseguibile Cobalt Strike è stato caricato e lanciato poche ore dopo. Questo è stato seguito immediatamente dall’installazione di un servizio Cobalt Strike sul controller di dominio utilizzando le credenziali dell’amministratore di dominio ottenute in precedenza. Il servizio era un ascoltatore di Server Message Block concatenato, permettendo ai comandi di Cobalt Strike di essere passati al server e agli altri computer della rete. Utilizzando Windows Management Interface, gli aggressori hanno eseguito in remoto un nuovo beacon Cobalt Strike sullo stesso server.

In breve tempo, altri servizi dannosi sono stati creati su altri due server utilizzando le stesse credenziali di amministratore, utilizzando Windows Management Instrumentation dal PC inizialmente compromesso. Uno dei servizi configurati era un comando PowerShell codificato che creava un altro tubo di comunicazione Cobalt.

Gli attori hanno continuato ad eseguire attività di ricognizione dal desktop inizialmente infetto, eseguendo comandi che cercavano di identificare potenziali obiettivi per ulteriori movimenti laterali. Molti di questi ripetevano i comandi precedenti. Il comando nltest è stato utilizzato nel tentativo di recuperare i dati dai controller di dominio su altri domini all’interno dell’albero dell’Active Directory aziendale. Altri comandi hanno eseguito il ping di server specifici, cercando di ottenere indirizzi IP. Gli attori hanno anche controllato tutte le condivisioni di rete mappate collegate alla workstation e hanno usato WMI per controllare le sessioni attive di Desktop Remoto su un altro controller di dominio all’interno dell’albero di Active Directory.

Impostare la trappola

Nel tardo pomeriggio di mercoledì – meno di un giorno dopo che la vittima aveva cliccato sul phish – gli attori di Ryuk hanno iniziato i preparativi per lanciare il loro ransomware. Usando la testa di ponte sul PC inizialmente compromesso, gli attaccanti hanno usato RDP per connettersi al controller di dominio con le credenziali di amministrazione ottenute il giorno prima. Una cartella chiamata C:-Perflogs\grub.info.test2 – Copy è stata rilasciata sul controller di dominio, un nome coerente con una serie di strumenti distribuiti nei precedenti attacchi Ryuk. Poche ore dopo, gli aggressori hanno eseguito un comando PowerShell codificato che, accedendo ai dati di Active Directory, ha generato un file di dump chiamato ALLWindows.csv, contenente dati di login, controller di dominio e sistema operativo per i computer Windows in rete.

Poi, il proxy maligno SystemBC è stato distribuito sul controller di dominio. SystemBC è un proxy SOCKS5 utilizzato per nascondere il traffico del malware che condivide codice e marcatori forensi con altri malware della famiglia Trickbot. Il malware si è installato da solo (come itvs.exe), e ha creato un lavoro programmato per il malware, utilizzando il vecchio formato del task scheduler di Windows in un file chiamato itvs.job-per mantenere la persistenza.

Si è poi eseguito uno script PowerShell caricato nella cartella grub.info.test sul controller di dominio. Questo script, Get.DataInfo.ps1 , scansiona la rete e fornisce un output di quali sistemi sono attivi. Controlla anche quale AV è in esecuzione sul sistema.

Gli attori di Ryuk hanno usato una serie di metodi per tentare di diffondere i file su altri server, comprese le condivisioni di file, WMI e il trasferimento degli appunti del Remote Desktop Protocol. WMI è stato utilizzato per tentare di eseguire GetDataInfo.ps1 contro un altro server.

Fallimento nel lancio

Giovedì mattina, gli aggressori hanno diffuso e lanciato Ryuk. Questa versione di Ryuk non aveva cambiamenti sostanziali rispetto alle versioni precedenti che abbiamo visto in termini di funzionalità di base, ma gli sviluppatori di Ryuk hanno aggiunto più offuscamento al codice per eludere i rilevamenti del malware basati sulla memoria.

Il server di backup organizzativo è stato tra i primi obiettivi. Quando Ryuk è stato rilevato e fermato sul server di backup, gli aggressori hanno usato il comando icacls per modificare il controllo degli accessi, dando loro il pieno controllo di tutte le cartelle di sistema sul server.

Hanno poi distribuito GMER, uno strumento “rootkit detector”:

Lo strumento GMER process hunting.

GMER è spesso usato dagli attori ransomware per trovare e chiudere processi nascosti, e per spegnere il software antivirus che protegge il server. Gli aggressori di Ryuk hanno fatto questo, e poi ci hanno riprovato. Il ransomware Ryuk è stato distribuito e rilanciato altre tre volte in breve tempo, cercando di sopraffare le difese rimanenti sul server di backup.

Le note di riscatto sono state lasciate nelle cartelle che ospitavano il ransomware, ma nessun file è stato criptato.

La nota di riscatto HTML di Ryuk.

In totale, Ryuk è stato eseguito in attacchi lanciati da oltre 40 sistemi compromessi, ma è stato ripetutamente bloccato da Sophos Intercept X. Entro mezzogiorno di giovedì, la parte ransomware dell’attacco era stata sventata. Ma gli aggressori non avevano finito di provarci e non erano ancora fuori dalla rete.

Venerdì, i difensori hanno implementato un blocco nei domini colpiti dall’attacco per il SystemBC RAT. Il giorno successivo, gli aggressori hanno tentato di attivare un altro proxy SOCKS sul controller di dominio ancora compromesso. E ulteriori implementazioni di Ryuk sono state rilevate nel corso della settimana successiva, insieme a ulteriori tentativi di phishing e tentativi di implementare Cobalt Strike.

Lezioni apprese

La catena di sfruttamento dell’attacco Ryuk.

Le tattiche esposte dagli attori Ryuk in questo attacco dimostrano un solido spostamento dal malware che era stato alla base della maggior parte degli attacchi Ryuk dello scorso anno (Emotet e Trickbot). La gang di Ryuk è passata da un fornitore di malware-as-a-service (Emotet) a un altro (Buer Loader), e ha apparentemente sostituito Trickbot con strumenti di sfruttamento più hands-on-keyboard – Cobalt Strike, Bloodhound e GMER, tra questi – e strumenti integrati di scripting e amministrazione di Windows per muoversi lateralmente all’interno della rete. E gli aggressori sono veloci a cambiare tattica man mano che emergono le opportunità di sfruttare l’infrastruttura di rete locale: in un altro recente attacco a cui Sophos ha risposto questo mese, gli attori di Ryuk hanno anche usato i Global Policy Objects di Windows distribuiti dal controller di dominio per diffondere il ransomware. E altri attacchi recenti hanno utilizzato un’altra backdoor collegata a Trickbot, conosciuta come Bazar.

La varietà di strumenti utilizzati, compresi gli strumenti di attacco off-the-shelf e open-source, e il volume e la velocità degli attacchi è indicativa di un’evoluzione nelle capacità operative della banda Ryuk. La suite “sicurezza offensiva” di Cobalt Strike è uno strumento preferito sia dagli attori sponsorizzati dallo stato che da quelli criminali, a causa della sua relativa facilità d’uso e l’ampia funzionalità, e la sua ampia disponibilità – versioni “craccate” del software con licenza commerciale sono facilmente acquistate nei forum underground. E il software fornisce agli attori un toolkit pronto per lo sfruttamento, il movimento laterale, e molti degli altri compiti necessari per rubare i dati, aumentare la compromissione e lanciare attacchi ransomware senza richiedere un malware fatto apposta.

Mentre questo attacco è avvenuto rapidamente, la persistenza degli attacchi dopo il fallimento iniziale di Ryuk per crittografare i dati dimostra che gli attori di Ryuk – come molti attaccanti ransomware – sono lenti a sganciare le loro mascelle, e possono persistere per lunghi periodi di tempo una volta che si sono spostati lateralmente all’interno della rete e possono stabilire ulteriori backdoor. L’attacco mostra anche che il Remote Desktop Protocol può essere pericoloso anche quando è all’interno del firewall.

Articles

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.