Anatomia dei cryptominer: un'analisi dettagliata
Analisi riassuntiva
Siamo alla seconda parte della nostra serie di blog Anatomia dei cryptominer, costituita da tre parti. Nella prima parte, abbiamo discusso delle criptovalute in generale, dei relativi attributi e di cosa rende alcune di esse più allettanti di altre per i criminali.
In questa parte, approfondiremo l'analisi di vari esempi di cryptominer per capire il loro meccanismo interno, focalizzandoci sui cryptominer che stanno eseguendo il mining di Monero e Zephyr, due delle monete che abbiamo scoperto potrebbero essere adatte per attività dannose. In questo blog, discuteremo dei seguenti argomenti:
L'utilizzo della rete di blockchain per identificare le comunicazioni di mining sospette provenienti da un potenziale malware di cryptominer
Quattro case study di esempio che utilizzano diverse topologie per mantenere le campagne attive e persistenti per un lungo periodo di tempo
Un caso interessante di una campagna lunga e persistente con migliaia di vittime che ha generato 5,50 dollari di ricavi ogni ora
Criminali che utilizzano più valute in una sola campagna
Il rilevamento tramite le attività di rete e i riferimenti incrociati alla rete di blockchain
Il rilevamento tramite l'analisi della memoria dei processi insieme al fingerprinting dell'algoritmo di consenso
Abbiamo incluso anche un elenco degli indicatori di compromissione (IoC) ricavati dai case study illustrati in questo blog per aiutare i team addetti alla sicurezza a proteggere le loro risorse.
Concluderemo questo post esaminando le tecniche di rilevamento basate sugli algoritmi resistenti agli ASIC, nonché per il rilevamento delle attività di cryptomining. Il rilevamento si focalizza sugli elementi fondamentali del mining e può essere applicato al livello della rete o del sistema operativo.
Analisi della rete di Monero
La rete di Monero viene creata tramite il protocollo Levin per implementare la comunicazione P2P (Peer-to-Peer) tramite i nodi della rete e utilizza il protocollo per distribuire le operazioni della blockchain, come nuove transazioni e nuovi blocchi. Inoltre, consente alla rete di autosostenersi in maniera decentralizzata tramite la pubblicazione dei nodi peer e di eliminare gli attacchi tramite gli algoritmi di consenso.
Anche se abbiamo usato Monero come esempio, l'individuazione della rete di una blockchain dovrebbe essere possibile nella maggior parte delle criptovalute grazie alla natura distribuita delle reti delle blockchain, di cui potete trovare ulteriori informazioni nel nostro blog precedente.
Individuazione della rete
Poiché la rete di Monero è una rete P2P decentralizzata di singoli utenti, risulta di facile connessione. Associando la rete di Monero, possiamo ottenere IoC affidabili (come gli indirizzi IP dei nodi) e individuare la potenziale attività degli hub dei nodi più connessi di altri.
È possibile usare queste informazioni per rilevare ed esaminare le operazioni di mining, nonché per verificare eventuali vulnerabilità e rischi per la rete di subire attacchi alla blockchain. La Figura 1 è una rappresentazione visiva della rete di mining di Monero, in cui la mappa termica mostra la densità dei nodi per area geografica. I nodi aperti pubblicamente a livello globale sono contrassegnati con dei puntini rossi.
Poiché la rete è costituita da nodi peer distribuiti, ogni cryptominer deve interagire direttamente o indirettamente con uno dei circa 30.000 server dislocati nel mondo che si trovano sulla nostra mappa. Come vedremo, la mappa si è rivelata molto preziosa per la ricerca di esempi di cryptominer, nonché per il rilevamento di connessioni di reti dirette alle blockchain (per ulteriori informazioni, potete consultare il nostro archivio GitHub, incluso il codice sorgente per il crawling della blockchain e la generazione di mappe).
Riferimenti incrociati dei cryptominer alla rete
Tramite i diversi indicatori ottenuti tramite l'associazione della rete di Monero, è possibile identificare alcuni esempi che interagiscono con la rete della blockchain. Ad esempio, tramite VirusTotal Livehunt, possiamo identificare file contenenti indirizzi di nodi noti, che ci aiutano a rilevare le campagne di cryptominer attive (Figura 2).
Proprio come tutto ciò che riguarda la sicurezza, non si tratta di una tecnica di ricerca valida per tutti i casi. Utilizzare solo questo approccio può condurre a falsi positivi se il server non è un nodo esclusivo della blockchain e ad una mancanza di visibilità perché la mappa non riesce ad individuare tutti i nodi. Tuttavia, combinando questa tecnica con altri indicatori, si migliora la percentuale di rilevamento dei veri positivi.
La mappa contiene nodi accessibili pubblicamente insieme a nodi recentemente accessibili. Alcuni dei nodi sono utilizzati per più nodi di Monero, ad esempio per eseguire il mirroring dell'archivio PyPi di Python o di altri servizi. Nella Figura 3, viene illustrato l'esempio di un server che fornisce più servizi, causando molti problemi nel processo di ricerca. Questi server sono stati eliminati dalla nostra analisi per ridurre il numero dei potenziali falsi positivi.
Nella ricerca delle minacce, eliminare gli esempi irrilevanti è altrettanto importante quanto includere gli esempi rilevanti. L'analisi della rete combinata con un approccio basato sui riferimenti incrociati può rivelare cryptominer e intere campagne di mining organizzate tramite le bot. Incorporando ulteriori tecniche di analisi statica, come l'associazione degli indirizzi del wallet integrati nel codice sorgente, possiamo focalizzarci in modo efficiente sugli esempi dannosi più rilevanti.
Analisi degli esempi di cryptominer
A causa della sua natura "fastidiosa", le operazioni di cryptomining possono essere facilmente rilevate anche ad "occhio nudo". Un attento esperto IT può rilevare le anomalie generate dai cryptominer senza richiedere sofisticati strumenti anti-malware. Anche chi non dispone di competenze tecniche è consapevole delle performance di base del proprio computer, che, quindi, se rallenta il suo funzionamento, fa analizzare da un esperto allo scopo di individuare la causa del problema. Pertanto, molti cryptominer non si preoccupano di proteggere i malware dalle operazioni di analisi e rilevamento, ma, invece, operano adottando una strategia che prevede l'infezione di massa di tutti i sistemi.
Nei case study riportati di seguito, verranno descritti alcuni esempi di cryptominer che abbiamo identificato in rete e verranno esaminate alcune caratteristiche interessanti del loro funzionamento e del loro comportamento. Per individuare questi case study, sono stati usati due fattori principali: (1) una valuta rilevante, come descritto nel primo blog di questa seriee (2) la topologia di mining che viene sfruttata.
Case study 1: una campagna persistente e massiccia
Come parte di questa ricerca, abbiamo analizzato vari esempi di cryptominer, di cui uno di essi è stato rappresentato da una campagna durata 6 anni. Come succede solitamente per le campagne di lunga durata, questa campagna sembra essere un'operazione organizzata o un servizio di distribuzione di malware che utilizza il cryptominer per conto di terzi.
Dall'analisi dell'esempio, è emerso che il cryptominer contenendo più proxy ha accumulato un hashrate di 5,6 Mh/s, che equivale a migliaia di computer compromessi (Figura 4). Si tratta di un attacco massiccio e persistente e, poiché l'hashrate rimane stabile, il malware, probabilmente, non viene rilevato dalla maggior parte delle sue vittime, continuando ad essere eseguito senza impedimenti. Questo tipo di attacco è una campagna estremamente redditizia per un criminale.
La campagna è attiva almeno da giugno 2018 e contiene indicazioni (ad es., la lingua utilizzata negli esempi) che potrebbero far supporre un'azione congiunta tra criminali russi e cinesi. Anche l'analisi dei server C2 (Command and Control) ha sostenuto questa teoria, che, tuttavia, alla data di questa pubblicazione, non è stata ancora pienamente confermata.
Alla data della stesura di questa pubblicazione, il criminale ha accumulato almeno 1702 XMR, che sono valutati circa 280.000 dollari al cambio odierno. Facendo il calcolo per sei anni, ciò implica una media di quasi 47.000 dollari all'anno per una sola campagna.
La maggior parte degli esempi correlati a questa campagna utilizza un linguaggio di script che corrisponde al sistema operativo della vittima come loader/downloader iniziale, in quanto opera perlopiù instradando e sviando le connessioni di rete, probabilmente in un tentativo di scollegare il file dannoso dal server C2.
Dopo aver analizzato gli esempi della campagna, abbiamo osservato un suo utilizzo di PowerShell per lanciare un eseguibile denominato loader in modalità "nascosta" tramite il rootkit r77. Anche senza analizzare il dropper complesso, possiamo notare che esistono più versioni di questo cryptominer.
In alcune versioni, lo stesso cryptominer contiene il file config.json , che include la configurazione di mining. In altri esempi, lo script OracleLoader rilascia il cryptominer e imposta la configurazione. Inoltre, il malware dispone di un meccanismo di aggiornamento con cui potrebbe recuperare la botnet in caso di violazione (Tabella 1).
Caratteristica |
Valore |
Nota |
---|---|---|
Nome malware |
Oracle Loader |
|
Versione corrente |
1.1.72.0 |
<5.133.65.53>/Oracle/ver$77_loader.exe.txt |
Componenti correlati |
|
Tabella 1. Caratteristiche di Oracle Loader
Il malware è anche in ascolto sulla porta 999, rendendo visibile l'API HTTP di XMRig. In tal modo, il criminale può accedere al miner della vittima e aiutarla a monitorare il processo di mining. Se il computer della vittima è direttamente connesso a Internet e non è protetto da un router NAT (Network Address Translation) o da un firewall esterno, in teoria potremmo individuare le vittime tramite servizi di monitoraggio delle reti, come Shodan. Nella Figura 5, viene illustrato il risultato di una query Shodan utilizzata per rilevare le potenziali vittime.
Utilizzando l'app web di monitoraggio del worker XMRig per monitorare i miner delle vittime, possiamo scoprire informazioni su di essi, come il modello della CPU e l'hashrate. Questa interfaccia ci consente solo di richiedere informazioni, quindi, anche se possiamo vedere un'attività, non siamo in grado di controllare il miner tramite di essa né di interromperlo (Figura 6).
Poiché abbiamo visibilità sul dashboard del pool di mining, l'hashrate stabile suggerisce che le vittime siano sparse in tutto il mondoperché, in caso contrario, ci dovremmo aspettare un hashrate variabile in base alle diverse attività del fuso orario. Un'altra spiegazione potrebbe essere rappresentata dal fatto che il criminale prende di mira i server e non i consumatori come avviene in altre campagne di cryptominer.
Case study 2: topologia del pool pubblico utilizzata da un cryptominer Zephyr
Anche se esistono criminali sofisticati e altamente motivati che sferrano campagne di lunga durata in grado di racimolare enormi profitti, come abbiamo visto nel case study 1, questi tipi di attacchi non rappresentano la maggior parte delle minacce. I cryptominer che utilizzano i pool pubblici sono, invece, i tipi di attacco più comuni. Questi cryptominer non contengono funzioni sofisticate, come le tecniche di offuscamento o anti-analisi, il loro modus operandi tipico consiste nel contattare direttamente il pool con l'indirizzo di un wallet in un formato non crittografato, e, di solito, il loro impatto e i profitti generati sono inferiori rispetto ad altre minacce.
Il mercato delle criptovalute offre ai criminali varie opzioni tra cui scegliere, con diversi tipi di redditività del mining e del valore delle valute. Nonostante l'aspetto di natura intrinsecamente finanziaria del cryptomining, la redditività del mining di una valuta non è, apparentemente, la considerazione più importante per molti criminali. La moneta Zephyr, che è meno redditizia di Monero, viene utilizzata molto comunemente dai criminali. La volatilità del criptomercato è un aspetto considerato dai criminali come anche dagli acquirenti legittimi di criptovalute. Il valore potenziale nel lungo termine potrebbe attrarre sia criminali che acquirenti ad utilizzare una criptovaluta anziché un'altra.
La più grande campagna Zephyr che abbiamo osservato ha più di 1400 vittime attive con un hashrate totale di 800 Kh/s e un profitto totale di 906,3 ZEPH, che equivalente, attualmente a 2.528 dollari.
Possiamo stabilire quando un criminale prende di mira specifiche aree geografiche esaminando l'hashrate della botnet nel corso del tempo, di cui un esempio è rappresentato da un'altra campagna da noi osservata che utilizza i proxy insieme al malware connesso direttamente, le cui vittime sembrano essere rappresentate da utenti russi (Figura 7).
I cambiamenti periodici possono indicare che la maggior parte delle vittime è costituita da utenti e non da server perché è più probabile che i PC vengano spenti di tanto in tanto. Se analizziamo la frequenza dell'hashrate, possiamo vedere che il ciclo dura 24 ore e, supponendo che il valore minore si raggiunga durante la notte, è possibile individuare il fuso orario in cui risiede la maggior parte delle vittime (Figura 8).
Gli intervalli di tempo da soli non forniscono una prova sufficiente riguardo alla posizione della vittima, tuttavia la nostra teoria è stata supportata dalla funzione di ricerca della geolocalizzazione dell'IP offerta dal pool Hashvault. Combinando questa funzione con l'analisi del malware e i nomi di delivery del malware che sono correlati ai giochi, come Fortnite e Solara Executor per Roblox, possiamo giungere ad un'ipotesi più attendibile: il malware si spaccia per un motore di trucchi inducendo i giocatori a trovarloe si diffonde, come sospettiamo, tramite i social media e le applicazioni di messaggistica, tra cui Telegram e Discord.
Case study 3: un cryptominer che utilizza la topologia di un proxy di mining
Abbiamo usato la mappa della rete di Monero per raccogliere informazioni su più di 25.000 nodi, ma siamo riusciti a raggiungere direttamente solo il 10% di essi. Al contrario, abbiamo usato questa mappa anche per escludere eventuali cryptominer noti che non contattano la rete, come nel caso di una campagna da noi individuata e attiva da aprile 2022.
Nella Figura 9, vengono illustrati i vettori di attacco del malware, che utilizza un proxy di mining, come il proxy XMRig, e distribuisce il suo cryptominer tramite un software piratato, come il sistema IDM (Internet Download Manager) violato.
Il flusso dell'attacco è simile nei vari esempi di malware della campagna: di solito, inizia con un download di tipo drive-by dal sito crackingcity.com, che imposta una catena di payload, quindi, nell'ultima fase, utilizza il cryptominer dlIhost.exe che si connette ad un proxy ospitato in custompool.xyz. Il criminale utilizza le variabili di ambiente per passare le stringhe come argomenti al suo processo figlio, principalmente file batch, come tecnica di elusione, che funziona decrittografando gli archivi incorporati ed eseguendo script o file dopo aver manipolato l'elenco di esclusione degli addetti alla sicurezza.
Il criminale ha registrazione il dominio del proxy con il nome di custompool.xyz il 29 aprile 2022, solo tre giorni dopo dal primo rilevamento in VirusTotal. Il primo esempio, denominato VScan.exe, è un archivio auto-estraente che utilizza due file batch. Il primo è il file main.bat, che utilizza una password nascosta nelle variabili di ambiente per estrarre il secondo file batch, denominato VS.bat. Possiamo estrarre le informazioni nascoste tramite un debugger in due modi: quando si accede alla variabile di ambiente denominata "l3" (Figura 10) o ad ogni modifica delle variabili di ambiente.
Tramite la password un#912345678@rar, possiamo estrarre il loader della seconda fase che si connette all'altro dominio C2, crackingcity.com. Nella fase finale, il malware esegue il file dlIhost.exe (essenzialmente, un client XMRig modificato con una configurazione incorporata al pool custompool.xyz ), che, a questo punto, è l'indirizzo IP diretto (Figura 11).
Ora rimane la questione relativa al tipo di server: si tratta di un pool privato, di un proxy di mining o di un tipo di nodo personalizzato che consideriamo uguale ad un pool privato? Per rispondere a questa domanda, dobbiamo trovare un modo per estrarre alcuni identificatori dal server. Il mining indipendente tramite un nodo dedicato richiede al miner di operare in modalità daemon (in cui la richiesta RPC viene trasmessa tramite HTTP), che non è presente in questa configurazione, quindi, ovviamente, non si tratta del nostro caso.
La struttura JSON viene preservata nella serializzazione, che ci consente di provare ad ottenere risposte dal server inviando vari metodi Stratum supportati dal proxy XMRig. Se le risposte provenienti dal server corrispondono all'ordine delle chiavi e dei valori, ciò potrebbe indicare nettamente che il server utilizza o si basa sul proxy XMRig.
XMRig supporta tre metodi di protocollo Stratum:
- Login : la prima richiesta avviata dal worker di mining, che, di solito, contiene il wallet come login
- Keepalived : mantiene la connessione attiva
- Submit : invia il risultato se viene trovata una condivisione valida
Se viene richiesto un metodo non valido, il proxy XMRig risponde con un messaggio di errore (Figura 12), che può indicare il tipo di server perché altri servizi, come i pool, ignorano la richiesta dannosa anziché considerarla un errore. Combinando tutti questi aspetti, arriviamo alla conclusione secondo cui si tratta del proxy XMRig.
Abbiamo suddiviso il metodo di invio in tre casi che dovrebbero restituire errori espliciti da un proxy XMRig (Tabella 2).
Una condivisione semplice si verifica quando il miner invia un hash con un valore inferiore al target previsto.
Un valore nonce non valido è il risultato di un valore nonce che non rientra nell'intervallo stabilito dalla progettazione nicehash.
Un hash molto complesso è l'hash appositamente creato per soddisfare l'obiettivo di un lavoro. In questo caso, abbiamo creato un metodo per eludere la verifica della complessità del proxy XMRig e l'abbiamo trasmesso direttamente al pool, che ha restituito il messaggio di errore.
Richiesta |
XMRig-proxy |
MoneroOcean |
HashVault |
Nanopool |
SupportXMR |
C3Pool |
Login |
(base) |
✕ |
✕ |
✕ |
✕ |
✕ |
Keepalived |
(base) |
≈ |
✅ |
≈ |
✕ |
≈ |
Sconosciuta |
(base) |
✕ |
✕ |
✕ |
✕ |
✕ |
Submit: semplice |
(base) |
✕ |
✕ |
✕ |
✕ |
✕ |
Submit: valore nonce non valido |
(base) |
NA: IP bloccato |
✕ |
✕ |
✕ |
✕ |
Submit: complesso |
Ripetizione del messaggio di risposta del pool |
NA: IP bloccato |
✅ |
✕ |
✅ |
✅ |
Tabella 2. Confronto tra le richieste del protocollo Stratum nel proxy XMRig e quelle in vari pool pubblici; ✅ indica un valore base, ✕indica dati diversi e ≈ indica un diverso ordine degli stessi dati
Possiamo distinguere non solo il proxy XMRig dai pool comunemente usati, ma anche un pool dall'altro. Queste informazioni potrebbero risultare utili durante l'instradamento di un pool tramite altri componenti di rete, come il proxy inverso. In questo caso, quando inoltriamo i risultati del mining con la massima difficoltà, viene visualizzato l'errore dal pool di back-end anziché dal proxy. Utilizzando queste informazioni, possiamo stabilire che il criminale utilizza Nanopool, ma, poiché non disponiamo dell'indirizzo del wallet, non possiamo conoscere il numero di vittime di questa campagna o il suo profitto.
Case study 4: comunicazione della blockchain nascosta con una topologia di un proxy Stratum
Il proxy del protocollo Stratum opera al livello di rete inoltrando le richieste del protocollo Stratum direttamente ad un altro server senza modificare gli indirizzi del wallet. In tal modo, si garantisce che il lavoro di ogni miner venga attribuito al rispettivo wallet. È possibile implementare un proxy Stratum tramite un proxy di rete a livello di trasporto.standard o di un'applicazione specializzata in grado di comprendere e gestire il protocollo.
Abbiamo individuato una campagna attiva che utilizza questa topologia e si connette ad un pool pubblico tramite un proxy Stratum. Non siamo riusciti a stabilire se si tratta di un proxy inverso sul livello di rete o se intercetta il protocollo Stratum e funge da proxy di un'applicazione. In ogni caso, i messaggi Stratum vengono reindirizzati per nascondere il nodo o il pool di back-end. La scansione dei pool pubblici per il wallet fornito rivela i suoi contatti con il pool pubblico MoneroOcean .
La campagna è attiva da almeno quattro mesi e il suo profitto totale è pari a 1.158 XMR (circa 180 dollari). Di per sé, non è una campagna di grande successo, ma lo sforzo apparente dell'autore dell'attacco fa supporre piani potenziali di maggiore portata, che includono lo sviluppo di tutti gli elementi della campagna: l'infrastruttura, il cryptominer e i diversi file dannosi da rilasciare. I criminali distribuiscono anche la stessa campagna senza affidarsi a terze parti, implementando, al contempo, meccanismi di progettazione non basati sul reverse engineering, tra cui la crittografia, l'offuscamento e la prevenzione dell'utilizzo di strumenti di monitoraggio (Figura 13).
Anche se la campagna potrebbe risultare un po' "pigra", possiamo notare un'esecuzione attenta del malware, soprattutto nel processo di offuscamento. Il malware tenta di nascondere il payload scaricando un archivio durante il runtime ed eseguendo i processi con i nome dei file system legittimi.
Rilevamenti
Esistono varie strade da percorrere quando si tratta di sistemi di rilevamento in generale. Ogni metodo potrebbe non essere sufficiente da solo, ma lo diventa se viene utilizzato insieme ad altri meccanismi di rilevamento. I cryptominer non fanno eccezione, anzi possono essere parti di malware difficili da rilevare per le loro caratteristiche benigne in quanto utilizzano l'unico elemento che non richiede un'autorizzazione speciale nella maggior parte dei sistemi operativi: il tempo di elaborazione (o tempo della CPU).
Collegamenti alla rete
Per rilevare questi miner, possiamo effettuare dei riferimenti incrociati tra la rete della blockchain (come la rete di Monero che abbiamo trattato in precedenza) e i dati ricavati da uno strumento di visibilità della rete, come un firewall o una soluzione di segmentazione. Poiché ogni nodo o pool deve interagire con la blockchain Monero, fornisce agli amministratori di rete preziose informazioni sul loro traffico in uscita e, se combinata con le porte di rete, semplifica notevolmente il rilevamento poiché la maggior parte dei cryptominer utilizza numeri di porte separati, come 999, 3333 o 7777. Anche se la rete di Monero viene utilizzata in questo case study, l'associazione della rete della blockchain può essere usata in tutte le reti basate sulle PoW (Proof-of-Work).
È importante notare, tuttavia, che non tutto il traffico diretto ai nodi di Monero fa necessariamente parte del cryptomining poiché questi nodi, a volte, forniscono più di un servizio. Ad esempio, l'IP 157[.]90[.]212[.]53 viene riportato nella nostra mappa della rete di Monero, ma è anche un nodo di uscita per la rete Tor. Ci potrebbero essere molte spiegazioni sul perché un nodo di Monero fornisce altri servizi in quanto può essere violato o semplicemente utilizzato per più scopi. In ogni caso, l'utilizzo della connessione alla rete senza ulteriori informazioni potrebbe indicare una connessione debole alla blockchain e generare falsi positivi. Ecco un'altra ragione per cui le informazioni sul numero delle porte sono fondamentali per garantire un rilevamento accurato.
Un altro motivo che può generare falsi positivi è rappresentato dalla bassa frequenza di aggiornamento della mappa. È possibile assegnare ad un server legittimo un indirizzo IP utilizzato in precedenza da un nodo di Monero e causare la generazione di un falso positivo se la mappa non è aggiornata.
Questo tipo di rilevamento non è sufficiente da solo, ma consente di attivare un'indagine o una logica di rilevamento più completa. Tutte le operazioni del cryptominer devono includere la comunicazione con un server Stratum per l'assegnazione di un processo di mining, che, di solito, opera con pool di mining pubblicamente noti, ma, in alcuni casi, può essere nascosta tramite un proxy non visibile sulla mappa della rete.
Rilevamento di esecuzione dell'algoritmo
I cryptominer utilizzano in modo intensivo le risorse di elaborazione della vittima, pertanto il monitoraggio del sistema per i picchi di utilizzo potrebbe indicare un'infezione, ma, proprio come i riferimenti incrociati della mappa della rete, non è sufficiente da solo come sistema accurato di rilevamento.
Combinando più IoC rilevabili, si aumenta l'affidabilità del rilevamento; in altre parole, si riduce il numero di falsi positivi. Per eseguire un'efficace operazione di mining, alcune controparti sono fondamentali. I cryptominer devono eseguire il mining della valuta selezionata utilizzando il relativo algoritmo di consenso come PoW (Proof-of-Work). Ogni algoritmo come questo presenta una propria "impronta digitale" univoca nel sistema durante il runtime e l'estrazione di queste funzioni può creare un metodo affidabile per il rilevamento dei cryptominer dannosi.
Gli algoritmi resistenti agli ASIC, come RandomX, di solito, implementano una serie complessa di operazioni che può essere identificata in modo univoco. Ad esempio, lo sviluppatore di RandomX ha creato uno strumento di rilevamento basato esattamente su questa supposizione. Iterando i thread eseguiti nel sistema, possiamo analizzarne lo stato, inclusi i valori dei registri della CPU. Poiché RandomX viene implementato utilizzando molte delle moderne funzioni delle CPU, l'utilizzo delle configurazioni di Rounding Control come nello strumento di rilevamento creato dallo sviluppatore di RandomX è un modo per eseguire questa operazione.
In realtà, combinandolo con altri indicatori, come le operazioni AES dell'hardware e la configurazione hugepage , si migliora il tasso di rilevamento. In breve, il rilevamento può essere eseguito cercando le chiavi AES univoche nei registri SSE o interrogando, rispettivamente, i privilegi del token di accesso del thread.
Possiamo estendere questi metodi anche ad altri sistemi operativi perché la maggior parte dei cryptominer mira a rendersi indipendente dalla piattaforma e a comportarsi nello stesso modo anche su diversi sistemi operativi. Non essere classificata in un sistema operativo consente ad una campagna di avere potenzialmente più successo visto che le cifre prefissate aumentano drasticamente in tal modo.
Individuazione del wallet nella memoria di elaborazione
Quando i cryptominer comunicano direttamente con il pool di mining anziché tramite un proxy, il wallet del miner deve risiedere nella memoria deiprocessi perché il protocollo Stratum richiede al miner di autenticare il server e di informarlo sull'account da ricompensare per l'invio di condivisioni valide. Di solito, viene usato l'indirizzo di un wallet e, per il mining di Monero, nello specifico, il miner sarà, probabilmente, basato sul software XMRig. Sulla base di queste supposizioni, possiamo individuare e intercettare il wallet quando viene inviato al pool mediante una connessione alle API del socket o (teoricamente) possiamo usare un attacco MITM (Machine-In-The-Middle) per intercettare il messaggio di autenticazione inviato dal miner.
Possiamo anche usare una semplice ricerca Regex all'interno della memoria allocata del processo per individuare l'indirizzo del wallet di 95 caratteri che segue un formato rigido: inizia con 4 o 8 ed è costituito da caratteri BASE58 validi. Pertanto, il modello /[48][1-9A-HJ-NP-Za-km-z]{94}/ potrebbe non essere sufficiente in questo caso e può essere incorporato anche in una regola YARA. È possibile condurre una scansione in qualsiasi momento dopo la prima connessione del cryptominer al pool perché il miner deve rendere l'indirizzo del wallet disponibile nel caso in cui sia necessario ristabilire la connessione.
Infine, possiamo usare una delle tecniche citate per individuare altre stringhe correlate al protocollo Stratum, da cui poi analizzare il wallet. Tali indicatori dovrebbero ridurre il numero di falsi positivi poiché la struttura JSON del protocollo è molto più univoca. Ad esempio, nella richiesta di accesso illustrata nella Figura 14, possiamo creare una firma più complessa che contiene più chiavi allo scopo di eseguire un rilevamento più accurato.
{
"id": 1,
"jsonrpc": "2.0",
"method": "login",
"params": {
"login": "<wallet address>",
"pass": "<Usually the worker name>",
"agent": "<Usually xmrig agent>",
"algo": [
"rx/0"
]
}
}
Figura 14. Esempio di una richiesta di accesso; associare il modello può fornire un rilevamento più accurato
Conclusioni
I ricercatori di Akamai continueranno a divulgare le campagne dannose e i loro autori, nonché ad identificare gli IoC nell'intento di aiutare a proteggere i propri clienti e il pubblico in generale.
In questa seconda parte della nostra serie di blog sui cryptominer in tre parti, abbiamo illustrato una serie di tecniche per fornire ulteriori informazioni su varie campagne, tra cui l'identificazione di un pool di mining alla base di un proxy di mining o l'individuazione dell'area geografica della campagna analizzando l'hashrate della botnet del cryptominer nel corso del tempo.
Abbiamo osservato vari cryptominer utilizzare Zephyr insieme alla ben nota valuta Monero. Utilizzando diverse topologie di mining, i cryptominer sono riusciti a nascondere alcune informazioni e a minimizzare il numero di identificazioni e indicatori compromettenti.
Dopo aver compreso l'anatomia dei diversi cryptominer e il processo di mining, in generale ci si chiede come sia possibile fermare l'attività di mining della botnet del cryptominer. Fermare l'attività di mining in modo efficace significa arrestare i cryptominer che infettano i computer delle vittime e consumano le loro risorse. Cercheremo di rispondere a questa domanda nell'ultima parte della nostra serie.
Per tenervi aggiornati su questa serie e su altre nuove ricerche sulla sicurezza, potete consultare la nostra pagina relativa alle ricerche sulla sicurezza e seguirci sui social media.