Sality, interrotta dopo 23 anni la botnet P2P usata per furti di criptovalute

Un’operazione internazionale isola la rete criminale

Un’operazione internazionale ha interrotto l’infrastruttura di Sality, botnet peer-to-peer osservata per la prima volta nel 2003 e rimasta operativa per 23 anni. La rete ha distribuito nel tempo information stealer, servizi proxy, strumenti per attacchi DDoS e altri componenti malevoli.

Alla campagna hanno partecipato CrowdStrike, le autorità di contrasto di Stati Uniti, Bulgaria, Ungheria e Romania e la Shadowserver Foundation. Quest’ultima sta lavorando con provider Internet e CSIRT per identificare i sistemi ancora compromessi e coordinare le attività di bonifica.

L’intervento ha combinato due azioni. CrowdStrike ha manipolato il protocollo P2P per separare i bot dai nodi controllati dall’operatore, mentre le autorità hanno rimosso o disattivato gli URL che ospitavano i payload distribuiti dalla rete.

Secondo CrowdStrike, il responsabile di Sality non sarebbe più in grado di comunicare con le macchine infette. I sistemi ancora compromessi starebbero ora inviando il proprio traffico periodico verso sinkhole controllati dall’azienda.

La botnet è quindi stata neutralizzata sul piano operativo, ma non automaticamente eliminata dagli endpoint. Il malware può essere ancora presente sui dispositivi.

Perché Sality ha resistito così a lungo

La longevità di Sality dipendeva soprattutto dalla sua architettura distribuita. Invece di affidarsi a un singolo server di comando e controllo, la botnet utilizzava una rete P2P attraverso la quale i nodi ricevevano aggiornamenti, istruzioni e nuovi codici.

L’assenza di un’infrastruttura centrale rendeva più difficile un’operazione tradizionale di sequestro. La disattivazione di un singolo server non sarebbe stata sufficiente: i dispositivi infetti avrebbero potuto continuare a comunicare attraverso altri peer.

L’ossatura della rete era formata da macchine compromesse con il ruolo di super peer. Ogni bot manteneva una lista di questi nodi e ne controllava periodicamente la raggiungibilità.

Il protocollo adottava un sistema di reputazione operativo. Un super peer che continuava a rispondere guadagnava affidabilità, mentre un nodo irraggiungibile perdeva progressivamente reputazione fino a essere rimosso dalla lista. In questo modo Sality poteva aggiornare autonomamente la propria topologia e conservare percorsi di comunicazione funzionanti.

Anche la propagazione contribuiva alla persistenza. Sality operava come file infector, inserendo il proprio codice negli eseguibili archiviati sui dischi e sui supporti rimovibili. Un file alterato e trasferito su un altro computer poteva quindi estendere l’infezione oltre il sistema originario.

Questa caratteristica complica anche la bonifica. Non basta interrompere il processo malevolo o cancellare un singolo file: occorre individuare gli eseguibili modificati e verificare i supporti che potrebbero aver trasportato il malware.

Il punto debole nascosto nel protocollo P2P

La stessa architettura che aveva protetto Sality per oltre due decenni conteneva una debolezza strutturale. Il protocollo si fidava dei peer senza applicare meccanismi di autenticazione o controlli affidabili sulla loro identità.

CrowdStrike ha sfruttato questa fiducia per intervenire direttamente sulle liste usate dai bot. L’operazione ha progressivamente eliminato i riferimenti ai super peer dell’infrastruttura criminale, sostituendoli con nodi destinati al sinkholing.

Un sinkhole è un sistema controllato dai difensori che riceve il traffico precedentemente diretto verso l’infrastruttura malevola. Non disinfetta il computer, ma impedisce o limita il contatto con l’operatore e permette di osservare le comunicazioni residue.

Nel caso di Sality, la manipolazione delle liste ha isolato gradualmente le macchine compromesse. Quando i bot hanno aggiornato la propria visione della rete, i nodi controllati dai difensori hanno preso il posto dei super peer usati dall’operatore.

L’azione sugli URL ha completato l’intervento. Rimuovendo le risorse dalle quali Sality scaricava i payload, le autorità hanno impedito ai dispositivi già infetti di ricevere nuovi componenti attraverso quei canali.

Non si tratta di una vulnerabilità software classificata pubblicamente. Non è stato indicato alcun identificativo CVE, né risultano coinvolti prodotti o versioni specifiche da aggiornare con una patch. Il difetto sfruttato per la disruption riguardava il modello di fiducia del protocollo P2P della botnet.

EggJagger e il furto tramite gli appunti

Negli ultimi otto anni, Sality sarebbe stata utilizzata soprattutto per distribuire EggJagger, uno strumento di clipjacking associato al furto di criptovalute.

Questa tecnica prende di mira il contenuto copiato negli appunti del sistema operativo. Durante una transazione, un utente può copiare l’indirizzo del portafoglio del destinatario per incollarlo nell’applicazione o nel sito usato per il trasferimento.

Il malware intercetta quel valore e lo sostituisce con un indirizzo controllato dall’attaccante. Se la vittima non confronta attentamente la stringa incollata con quella originale, la transazione viene autorizzata verso il portafoglio sbagliato.

Una volta confermato il trasferimento sulla blockchain, il recupero dei fondi può essere estremamente difficile. EggJagger avrebbe sottratto almeno 150.000 dollari in Bitcoin ed Ethereum. La somma è una stima minima e potrebbe non riflettere tutti i proventi ottenuti attraverso la campagna.

L’impatto di Sality, tuttavia, non si limita alle criptovalute. La botnet ha sostenuto attività di spionaggio delle informazioni, distribuzione di proxy abusivi e attacchi DDoS, offrendo all’operatore una piattaforma adattabile a differenti finalità criminali.

Disruption non significa rimozione del malware

L’isolamento della rete riduce la capacità dell’operatore di impartire ordini e distribuire nuovi payload. Non cancella però Sality dai computer già compromessi, né ripristina gli eseguibili modificati dal file infector.

Le organizzazioni dovrebbero quindi controllare gli endpoint potenzialmente esposti, prestando particolare attenzione ai sistemi più vecchi, ai file eseguibili trasferiti tra dispositivi e ai supporti rimovibili utilizzati su più macchine. Questi ultimi possono conservare copie infette e reintrodurre il malware dopo una bonifica incompleta.

È inoltre opportuno verificare eventuali anomalie nelle applicazioni dedicate alle criptovalute. Gli indirizzi dei wallet devono essere confrontati prima di autorizzare ogni transazione, soprattutto quando sono stati inseriti tramite copia e incolla.

Non sono stati pubblicati nomi di file, hash, domini, indirizzi IP o altre stringhe utilizzabili direttamente come indicatori di compromissione. Non sono note neppure firme operative o procedure universali per rimuovere l’infezione.

Quando i dati sui sinkhole saranno disponibili ai difensori, il traffico diretto verso tali sistemi potrà aiutare a individuare endpoint ancora attivi. Una comunicazione con un sinkhole costituisce infatti un possibile segnale di infezione residua, non la prova che la macchina sia già stata ripulita.

La bonifica passa da ISP, CSIRT e fornitori di sicurezza

La Shadowserver Foundation sta collaborando con ISP e CSIRT per associare le connessioni osservate ai sistemi vittima e avvisare utenti e organizzazioni. Chi riceve una segnalazione dovrebbe trattarla come un’indicazione concreta di compromissione e avviare un’analisi dell’endpoint.

In assenza di strumenti e firme di rimozione resi pubblici, la remediation deve essere coordinata con il proprio provider, il CSIRT competente o un fornitore di sicurezza. L’analisi dovrebbe comprendere gli eseguibili, i supporti rimovibili e gli altri dispositivi che hanno scambiato file con la macchina infetta.

Può essere necessario sostituire i file alterati con copie integre o ripristinare completamente il sistema. La scelta dipende dall’estensione dell’infezione, che un file infector può rendere difficile da delimitare con certezza.

L’operazione ha tolto all’autore di Sality il controllo della rete e ha bloccato i canali noti per la distribuzione dei payload. La fase successiva è meno visibile ma decisiva: trovare le macchine ancora infette e rimuovere il codice rimasto operativo dopo 23 anni di propagazione.