Indagine sul ritorno della campagna Mexals
Analisi riassuntiva
Editoriale e commenti aggiuntivi di Tricia Howard
L'Akamai Security Research ha monitorato e analizzato il ritorno di Mexals, una probabile campagna di cryptojacking con sede in Romania.
La campagna è attiva almeno dal 2020 ed è stata precedentemente esaminata in un rapporto di Bitdefender nel luglio 2021.
La nuova ondata di attacchi e miglioramenti del malware sembra essere iniziata nell'ottobre 2022. Ora si fanno chiamare Diicot, che è anche il nome dell'agenzia rumena che combatte il terrorismo e la criminalità organizzata..
I ricercatori della sicurezza di Akamai hanno iniziato ad analizzare la campagna in seguito a un rilevamento DNS dannoso presso un cliente Akamai. Tutti i clienti Akamai interessati sono stati tempestivamente informati e sono state adottate le opportune contromisure.
Gli autori di attacchi utilizzano una lunga catena di payload prima di scaricare un cryptominer Monero.
Le nuove funzionalità includono l'utilizzo di un modulo worm SSH (Secure Shell Protocol), più rapporti, migliore offuscamento del payload e un nuovo modulo LAN spreader.
Analizzando il pool del miner, stimiamo che gli autori di attacchi abbiano eseguito il mining di monete XMR per un valore di circa 10.000 di dollari.
Forniamo strategie di mitigazione, strumenti di rilevamento e un archivio completo di indicatori di compromissione (IOC).. Abbiamo anche contattato le vittime con questi strumenti, prima della pubblicazione di questo blog.
Introduzione
I ricercatori di sicurezza di Akamai hanno studiato una campagna di cryptojacking attiva, che riteniamo sia il ritorno di una campagna del 2021 supportata da Bitdefender. Sebbene ci fossero diverse correlazioni con il rapporto originale, da allora questo malware è salito di livello .
Uno dei cambiamenti tra le due campagne è il relativo nome: il gruppo precedentemente noto come Mexals (vedi la loro pagina web nella Figura 1) ora si fa chiamare Diicot e uno dei suoi strumenti porta lo stesso nome. Diicot è anche il nome dell' agenzia rumena antiterrorismo; nel tentativo di evitare confusione, faremo riferimento al gruppo di criminali come Mexals. Durante l'analisi del modus operandi, della catena di payload e degli IOC, è apparso chiaro che, nonostante il cambio di nome, queste due campagne erano correlate.
Figura 1: La pagina web predefinita mostrata nel dominio dell'autore di attacchi che ospita anche i relativi payload
In questa campagna abbiamo osservato un migliore offuscamento, nomi di file meno appariscenti e proxy pool di mining personalizzati che non erano presenti nell'iterazione precedente. La catena di attacco inizia con un attacco di forza bruta alle credenziali SSH. Segue una lunga catena di payload offuscati, che alla fine scarica un cryptominer XMRig. Uno dei payload scaricati è un modulo wormable che pensiamo sia stato attivo in questo ritorno.
Crediamo anche che i loro server di attacco siano ospitati in un VPS con sede nei Paesi Bassie le loro vittime sono distribuite in tutto il mondo. Stimiamo che gli autori di attacchi siano riusciti a estrarre più di 10.000 dollari in monete XMR.
Alcuni hacker utilizzano un kit di strumenti. Questi criminali sembrano utilizzare una catena
Nella nostra analisi della catena di infezione degli autori di attacchi, abbiamo trovato otto file eseguibili. Questi eseguibili non sembrano differire molto da quanto osservato da Bitdefender, ad eccezione dei nomi dei file e dei percorsi e da alcune nuove funzionalità (figura 2).
Nome payload |
Utilizzo |
|---|---|
Storia |
Uno no script bash. Controlla se l'' aggiornamento è in corso. Se non lo è, lo esegue. |
Aggiorna |
Uno Script bash compilato. Avvisa gli aggressori tramite un webhook Discord ed esegue una scansione di rete su una rete IP di classe B casuale per computer con SSH aperto. Fornisce i risultati agli alias. |
Chrome/ps |
Uno scanner di rete. Accetta un intervallo di rete di classe B (255.255.0.0) e una porta. Esegue la scansione dell'intervallo di rete per i computer con tale porta aperta e salva i risultati in un file. |
Un modulo worm SSH scritto in Golang. Esegue il payload. |
|
Il principale modulo post-violazione. In base alle risorse a disposizione della vittima, installa una backdoor, un cryptominer o un worm LAN SSH. |
|
.diicot |
Uno script bash compilato. Scarica Opera, un cryptominer. Installa anche un'altra backdoor sotto forma di un nuovo utente e di una chiave SSH. |
Opera |
Un cryptominer XMRig. |
Uno script bash compilato. È l'inizio del modulo LAN spreader. Esegue uno scanner di porte SSH sull'intervallo IP della LAN interna e quindi chiama la rete per provare a violare i computer con SSH. |
|
Rete |
Un'altra variante di alias con minori funzionalità. Esegue un attacco al dizionario SSH sulla LAN locale, salva le informazioni sui computer violati (e le credenziali di lavoro) in un file di testo. |
Figura 2: Un riepilogo dei diversi payload utilizzati dagli autori di attacchi
Generazione binaria e offuscamento
Il cambiamento più significativo che abbiamo osservato riguarda l'offuscamento del payload. In precedenza, la maggior parte dei payload eseguibili erano, in effetti, script bash compilati con shc, ma ora anche quegli script bash compilati erano compressi UPXe l'intestazione UPX è stata rimossa per ostacolare l'analisi e la decompressione (Figura 3).
Figura 3: Un file eseguibile compresso non può essere decompresso da UPX a causa dell'intestazione rimossa
Fortunatamente, potevamo contare su uno strumento creato dallo sviluppatore Akamai Larry Cashdollar come parte di un precedente avviso SIRT. Questo ci ha permesso di ripristinare facilmente l'intestazione UPX, decomprimere gli eseguibili ELF ed estrarre gli script bash all'interno.
Siamo quindi rimasti con un file binario completamente rimosso e compilato in modo statico, senza alcun modo di distinguere tra il codice del malware e il codice di glibc (Figura 4).
Figura 4: Il punto di accesso del file binario rimosso
Possiamo fare affidamento sul codice sorgente di glibc per capire come appare il punto di accesso. La funzione principale effettiva è la funzione caricata in rdi. Esaminandola, possiamo individuare una stringa di errore piuttosto specifica: E: neither argv[0] nor $_ works., che possiamo cercare sul web. Questa ci conduce a shc. .Sfortunatamente, non esiste un decompilatore facilmente disponibile. Invece di decodificarlo e creare un componente di crittografia, che sarebbe problematico, possiamo eseguire il debug del payload e sospendere l'esecuzione dopo un secondo. Lo script di shell decrittografato risiederà nella memoria del malware, che potremo quindi scaricare e analizzare.
Catena di infezione
Figura 5: La catena di payload completa
Ogni payload si concatena in modo relativamente semplice, con vari metodi per impostare il link successivo. Ad esempio, terminare i miner o i processi pesanti per la CPU, pulire la cronologia di bash o la persistenza di installazione e quindi scaricare ed eseguire il payload successivo (Figura 5).
Analisi tecnica dei payload principali
alias
Questo è un binario Golang, che non è stato rimosso in modo da poter trovare facilmente tutta la logica del malware. Il malware legge due file, che sono stati creati nei passaggi precedenti: protocolli (elenco di parole utente-password scaricato dall' aggiornamento) e bios.txt (elenco IP di destinazione dei computer con SSH aperto, creato da Chrome). Quindi continua eseguendo un attacco al dizionario su ogni destinazione e, dopo l'autenticazione riuscita, esegue il payload e altri comandi per eseguire il profiling del sistema violato.
L'ultimo comando eseguito è uname -s -v -n -r -m, e il suo output viene analizzato. Nello specifico, cerca nomi di sistemi operativi specifici all'interno di quell'output che possono indicare obiettivi interessanti. Per la maggior parte dei nomi del sistema operativo che cerca, è innocuo, ma, se sul computer di destinazione è in esecuzione OpenWrt, esegue un altro comando bash su di esso per scaricare ed eseguire un altro script di shell da 107.182.129.219, che scaricherà una variante Mirai. Pensiamo che l'attenzione su OpenWrt Sia dovuta al fatto che è installato su dispositivi integrati e potrebbe fungere da vettore di accesso iniziale alle reti dell'organizzazione. Ciò dimostra che gli autori di attacchi sono interessati a qualcosa di più di una semplice campagna di cryptomining e sono attivamente alla ricerca di nuove opportunità di sfruttamento.
Una volta che il malware ha terminato il proprio tentativo di violazione, lo segnala agli autori di attacchi tramite un webhook Discord (una pratica di attacco che sta guadagnando popolarità). Esistono quattro diversi webhook, con scopi diversi (Figura 6).
Figura 6: Un'intercettazione dei webhook Discord richiamati dal malware
Il primo webhook proviene da una funzione chiamata toDiscorde relega i risultati dei vari comandi di profiling eseguiti sul computer di destinazione. I successivi due vengono chiamati dalle funzioni toAPIlogs e toDisced entrambi relegano le stesse informazioni: l'IP della destinazione e l'utente e la password in grado di eseguire l'autenticazione.
Infine, se la vittima stava eseguendo OpenWrt, viene chiamata un'altra funzione toMiraiche invia le stesse informazioni a un altro webhook. Osserviamo una certa ridondanza qui, che presumiamo serva agli autori di attacchi per tracciare più facilmente diverse metriche oppure può fungere da separazione per diverse parti della loro campagna di attacco (Mirai come botnet/IAB rispetto all'uso regolare di Mirai come criptominer).
payload
Sebbene sia "solo" uno script bash compilato, il payload è interessante perché è pieno di commenti e messaggi di avanzamento, che possono illuminarci sui processi mentali degli operatori di malware.
I commenti e i messaggi sullo stato di avanzamento sono in lingua rumena, il che rafforza l'ipotesi che gli autori di attacchi siano rumeni (il dominio C2 (Command and Control)/di download del malware si traduce letteralmente in "archivio dell'hacker").
Lo script verifica anche la presenza di altri cryptominer noti e interrompe i loro processi, tra cui dhpcd e ksmdx. Ciò dimostra che gli autori di attacchi sono consapevoli del proprio ecosistema e non si muovono a caso nel mondo del cryptomining.
Dopo aver terminato concorrenti e altri processi pesanti per la CPU, lo script controlla quanti core della CPU sono presenti sul computer: se ce ne sono meno di quattro, installa semplicemente Storia e Aggiornamento e un processo cron per essi. (I due file eseguibili sono responsabili del download del payload alias e sono programmati per essere eseguiti al riavvio del computer preso di mira). Se sono presenti quattro o più core, viene scaricato anche lo script ed esegue .diicot, uno script bash compilato che scarica ed esegue un cryptominer XMRig.
Infine, se sono presenti otto o più core della CPU, lo script viene scaricato ed esegue retea, il LAN spreader.
retea
Il modulo LAN spreader presenta una nuova funzionalità nella catena degli autori di attacchi. È un altro script di shell compilato, che estrae tutti gli utenti configurati sul sistema e crea un file chiamatousrs. Il file viene utilizzato per un attacco al dizionario SSH e viene popolato utilizzando gli utenti estratti e un elenco di password predefinite codificate. Quindi scarica ed esegue uno scanner di rete sulla rete LAN, che rileva i computer con porte SSH aperte e scrive l'output in un file. Successivamente, scarica ed esegue Rete, che è una versione minore di alias, con meno funzionalità. Invece di installare un payload dannoso o segnalare a un webhook Discord, salva semplicemente l'output dei computer violati in un file, che può essere successivamente recuperato dagli autori di attacchi.
Vi presentiamo le vittime
O forse no?
Poiché gli autori di attacchi hanno un payload wormable, è difficile distinguere quale IP di origine rilevato nei nostri sensori di minacce sia l'infrastruttura dell'autore di attacchi e quale sia una vittima. In questa sezione, cercheremo di analizzare l'infrastruttura dell'autore di attacchi e individuare le vittime effettive.
Abbiamo estratto tutti gli IP di attacco che abbiamo rilevato (50 indirizzi IP univoci) e li abbiamo geomappati in base alla loro posizione geografica nel mondo. Oltre agli IP di attacco, abbiamo anche rilevato prove di infezione presso alcuni dei clienti di Akamai, quindi anche loro sono stati inseriti nel nostro elenco delle vittime. La distribuzione geografica delle vittime/infrastrutture è illustrata nella Figura 7.
Figura 7: Mappa del mondo con geolocalizzazione degli IP di attacco
Sebbene la maggior parte delle località presenti un'attività molto scarsa, abbiamo alcuni hotspot nell'Europa occidentale. Il picco di attività lì individuato (Figura 8) ci porta a ipotizzare che gli hotspot siano in realtà computer controllati dagli autori di attacchi, mentre il resto sono computer delle vittime rilevati dal modulo wormable. Sembra che il modulo wormable non sia particolarmente attivo, poiché osserviamo pochissimi computer attivi contemporaneamente. Questo ha senso, dal momento che alias viene eseguito solo una volta per l'esecuzione di un processo cron, su una classe B casuale. Il cron è programmato per essere eseguito al riavvio del computer, cosa che probabilmente accade di rado, data la natura del computer delle vittime (ad esempio, server Linux aperti a Internet).
Figura 8: Numero di IP che attaccano i nostri sensori di minacce contemporaneamente, nel tempo
Osservando gli indirizzi IP più registrati nei nostri honeypot, che presumiamo rappresentino l'infrastruttura degli autori di attacchi, possiamo notare una chiara distribuzione degli host (Figura 9). Gli indirizzi IP precedenti erano ospitati da DigitalOcean. Gli indirizzi più recenti (dal recente ritorno) sembrano essere stati ospitati in Serverion, un VPS e provider di web hosting dai Paesi Bassi (il loro ASN è effettivamente registrato sotto la l'azienda capogruppo, Des Capital B.V., un'agenzia immobiliare, che inizialmente ci ha confuso).
Data dell'attacco |
Numero di attacchi |
IP autore di attacchi |
Nome dell'organizzazione di hosting |
|---|---|---|---|
01/02/2023 |
14 |
185.225.74.231 |
Des Capital B.V. |
01/10/2022 |
72 |
45.139.105.222 |
Des Capital B.V. |
01/10/2022 |
62 |
212.193.30.11 |
Des Capital B.V. |
01/03/2022 |
22 |
195.133.40.157 |
Des Capital B.V. |
01/12/2021 |
43 |
134.209.95.47 |
DigitalOcean, LLC (DO-13) |
01/12/2021 |
37 |
134.209.195.231 |
DigitalOcean, LLC (DO-13) |
01/12/2021 |
34 |
104.248.85.104 |
DigitalOcean, LLC (DO-13) |
01/12/2021 |
27 |
134.209.198.229 |
DigitalOcean, LLC (DO-13) |
01/12/2021 |
27 |
167.71.48.128 |
DigitalOcean, LLC (DO-13) |
01/12/2021 |
74 |
188.166.60.8 |
DigitalOcean, LLC |
Fig. 9: Principali IP di attacco, che presumiamo rappresentino l'infrastruttura dell'autore di attacchi, non solo le vittime
Prima della pubblicazione di questo post sul blog, abbiamo contattato i clienti Akamai interessati con informazioni sugli attacchi, nonché sulle e-mail abusate registrate per ciascun indirizzo IP dell'attacco.
Pagamenti esterni?
Sembra che gli autori di attacchi abbiano cambiato la propria configurazione di mining rispetto alla campagna precedente. In passato indirizzavano i propri miner a operare direttamente con supportxmr.com , ma i miner che abbiamo analizzato di recente comunicano con indirizzi IP che sono probabilmente sotto il controllo degli autori di attacchi. Temevamo che si trattasse di pool privati, il che significava che non potevamo tenere traccia dei pagamenti, ma i nostri timori erano infondati: supportxmr continuava a tracciare i pagamenti di mining sul portafoglio, quindi presumiamo che i relativi server siano solo proxy del pool ospitato da supportxmr. Potrebbe trattarsi di un modo per eludere il blocco e il rilevamento del DNS non raggiungendo direttamente il pool.
Siamo riusciti a estrarre due diversi indirizzi di portafogli dai payload XMRig che abbiamo osservato durante le indagini sulla campagna. Questi indirizzi di portafogli sono diversi da quelli individuati da Bitdefender, ma in base alla cronologia dei pagamenti, sembrano essere stati attivi anche durante quel periodo.
Abbiamo osservato che gli importi dei pagamenti variavano notevolmente prima di novembre 2021 (raggiungendo anche due volte un XMR completo), ma in seguito sono diventati molto più frequenti e coerenti (Figura 10). Ciò potrebbe essere dovuto a un cambiamento nello schema di pagamento o all'aggiunta di più miner: la tempistica corrisponde ad altri picchi nell'attività del malware che abbiamo rilevato.
Fig. 10: La cronologia dei pagamenti di mining al portafoglio degli autori di attacchi, come estratta da supportxmr
Complessivamente, stimiamo che gli autori di attacchi siano riusciti a estrarre XMR per un valore superiore a 10.000 dollari durante l'intera campagna, con oltre il 75% di esso estratto dal loro ritorno. La quantità reale estratta è probabilmente persino superiore alla nostra stima, a giudicare dal numero di operatori univoci riportato da supportxmr, abbiamo osservato solo la metà dei payload e delle configurazioni XMRig (Figura 11).
Fig. 11: I miner associati a uno dei portafogli degli autori di attacchi
Riepilogo
La catena di payload impiegata dagli autori delle minacce è certamente impressionante e indicativa di un autore di attacchi piuttosto sofisticato. Inoltre, di solito non vediamo una catena così lunga di payload e crediamo che ci siano alcuni motivi per cui gli autori di attacchi hanno scelto di utilizzare così tanti payload.
Offuscamento : più parti si muovono nel sistema, più difficile è analizzarlo e tenerne traccia. Il fatto che i binari siano offuscati non fa che rafforzare questa ipotesi.
Ci sono più persone dietro il gruppo di criminali. Sebbene non disponiamo di informazioni effettive sugli autori di attacchi dietro la campagna, abbiamo notato notevoli differenze di codice tra diversi campioni degli stessi script, che possiamo attribuire solo al fatto che sono stati sviluppati da persone diverse.
La campagna malware è progettata per evolversi nel tempo. Ne vediamo la prova nelle nuove funzionalità e nell'ulteriore offuscamento che sono stati aggiunti, nonché in alcune delle ridondanze nel codice che sono state create come base per un utilizzo futuro.
Miglioramenti e aggiunte dall'operazione precedente
Compressione UPX e rimozione dell'intestazione UPX .
La funzionalità di aggiornamento automatico è stata spostata dall'interno del payload agli script esterni (Storia e Aggiornamento).
Nomi di file meno appariscenti (Chrome, Opera : che imitano i browser)
Ulteriori segnalazioni di malware su Discord
Comportamento specifico di OpenWRT (e probabilmente altro in arrivo)
Utilizzo di proxy pool di mining personalizzati al posto di pool pubblici
Archivio degli addetti alla sicurezza
Protezione del perimetro e della rete
Il malware non ha alcuna tecnica nuova o sofisticata per distribuirsi. Utilizza semplicemente un attacco al dizionario su SSH. Pertanto, solo i computer aperti a SSH da Internet sono a rischio. Bloccare SSH sul perimetro della rete o spostarlo dietro una VPN può ridurre notevolmente i rischi che tali attacchi comportano.
Inoltre, l'utilizzo di credenziali non predefinite o password complicate riduce notevolmente il rischio di un attacco al dizionario come quello impiegato da questo malware. Si consiglia inoltre di utilizzare le chiavi SSH per l'autenticazione poiché sono ancora più sicure delle password (sono impossibili da indovinare e il "segreto" non viene mai trasmesso tramite la connessione).
Infine, dobbiamo considerare anche il modulo LAN spreader. Poiché utilizza anche SSH per il movimento laterale, segmentare la rete può mitigare in modo sicuro tale rischio. Se consideriamo i server aperti a Internet come la zona demilitarizzata (DMZ), impedire il traffico SSH (e in generale altro traffico che può essere utilizzato per il movimento laterale, come RDP, MS-RPC o WinRM) dalla DMZ al resto della rete è la cosa logica da fare. Se, per qualche motivo, è necessario che uno di tali server abbia l'accesso SSH alla rete interna (perché funge da jumpbox, ad esempio), spostarlo al di fuori della DMZ e sotto la VPN dovrebbe essere il metodo preferito. Basta non esporre i server a Internet e consentire agli autori di attacchi di passare da essi internamente: ridurre il raggio di azione e i percorsi di propagazione.
Rilevamento delle infezioni
Abbiamo creato un archivio Github per strumenti che possono aiutarvi a rilevare le infezioni causate da questa campagna dannosa. Qui potrete trovare uno script bash, un elenco completo di IOC e query osquery che i clienti di Akamai Guardicore Segmentation possono utilizzare. Potete inoltre trovare lo script di rilevamento e un elenco parziale di IOC alla fine di questo post.
Oltre a questi strumenti, vorremmo anche raccomandare un metodo generale per rilevare i cryptominer che potrebbe essere applicato in questo caso: rilevare il traffico in uscita verso i pool di mining osservando la porta di destinazione. Le porte predefinite per i pool di mining a volte sono uniche, quindi tenerle d'occhio potrebbe rivelarsi vantaggioso. Ad esempio:
La porta TCP 4242 è la porta predefinita per questa questa implementazione del pool
Le porte TCP 3333, 5555, 7777, 9000 sono le porte predefinite nell' implementazione del pool nodejs
Naturalmente, i miner possono anche comunicare con il loro pool tramite HTTP e HTTPS, nel qual caso il rilevamento sarebbe molto più difficile. Tuttavia, vale la pena cercare queste porte.
Script di rilevamento
Lo script di rilevamento cerca vari IoC che possono indicare la presenza passata o attuale della campagna di attacco. Cerca artefatti nel crontab, i loro percorsi file e processi in esecuzione e anche la backdoor della chiave SSH dannosa. Per eseguirlo, è sufficiente scaricalo sul computer da controllare ed eseguilo. Scansiona il computer e stampa il risultato:
Figura 12: Esecuzione dello script di rilevamento per cercare artefatti Mexals.
Indicatori di compromissione
Questo è un elenco di IOC parziale. L'elenco completo è disponibile nel nostro archivio Github.
Percorsi
/var/tmp/.update-logs/
/var/tmp/Documents/
/var/tmp/.ladyg0g0/
/dev/shm/.x/
/dev/shm/.magic/
Nomi file
protocolli
bios.txt
Aggiornamento
Cronologia
alias
payload
retea
.usrs
IP
107.182.129.219
45.139.105.222
185.225.74.231
212.193.30.11
Domini e URI
arhivehaceru[.]com
discord[.]com/api/webhooks/954295081765072926/Zu7Vu-LpfgRqSmCyFvz3BCkR1Lt7clYOJeayCFzZwtPmZlVn9og_6mPS_BJY-374m5Y3
discord[.]com/api/webhooks/1036206037373571082/9bs01KrT-TrcbSAPI_i-adV1Bhn56A4X4fxzCYEw3zMq95H1mFvlKWb6-KYzvEoVfTnS
discord[.]com/api/webhooks/1036205058456563722/1_saZM0fE7nLgYG668LmDfNmSvrWpD-6Z8nIXljm0qlm6YyMxAyYuZIu4LhN2gHsgSQy
discord[.]com/api/webhooks/965651135102865479/PFdU4u8yZrn0XhzIKShcaxL3_IaBjsstYmFEXlThF2_1XCnwXSAjKos3ptwKYpPyGqvI
discord[.]com/api/webhooks/848592916951203860/WeWBGYSVreTlE0aO_6alVN3Qrj6_aRxnaDpq4_6wD04V2aHlMFvgik2Z2h78Dstg9fZY
discord[.]com/api/webhooks/1036225255049531422/qyOrT3SxHaOC-9yS2NQiPxlSMYmRFFIpU-rMKzmcDv9pQyP4uaZEiZXDXioUtf0DJLUB
