6,3 miliardi in 20 minuti: come è stato drenato Binance

Poco dopo le 20:00 GMT di giovedì 29 ottobre 2026, dal wallet (il portafoglio digitale) di Binance cominciano a partire criptovalute. Venti minuti dopo il conto è di circa 6,34 miliardi di dollari. Non è un colpo nato da una falla sconosciuta nel codice dell'exchange (la piattaforma di scambio), il maggiore al mondo per volumi. È l'ultimo passaggio di una storia cominciata a giugno, con un installer scaricato da un motore di ricerca, e proseguita a settembre con un colloquio di lavoro che non esisteva. Per un'azienda che non tratta cripto, la parte da studiare non è il bottino: è la sequenza.

Quattro passaggi, tutti normali

La ricostruzione del co-CEO Richard Teng e del report di sicurezza di Binance descrive quattro passaggi. A giugno un ingegnere del team wallet scarica un'installazione Homebrew (il gestore di pacchetti usato su macOS) manomessa, per installare un popolare strumento di coding basato su AI trovato su un motore di ricerca. A settembre un secondo ingegnere sostiene quelli che sembrano colloqui di lavoro e chiude il processo con un esercizio di coding che contiene malware (software malevolo) nascosto, progettato per eludere i controlli. Da lì gli attaccanti si muovono attraverso gli strumenti di AI interni e raggiungono il sistema che autorizza le transazioni.

Nessuno di questi passaggi, preso da solo, è un attacco sofisticato. È questo il punto. Un pacchetto scaricato, un candidato valutato, un assistente AI che legge repository e documentazione, un sistema che firma trasferimenti: sono cose normali in qualsiasi azienda che sviluppa software. La sofisticazione sta nel collegarle, e nel fatto che ogni passaggio rende il successivo più semplice.

Giugno: il primo errore è un installer

L'ingegnere stava facendo il proprio lavoro: installare uno strumento diffuso, seguendo un risultato di ricerca che sembrava legittimo. La manomissione era nell'installazione di Homebrew, cioè nel passaggio che precede il software vero e proprio.

Qui c'è la lezione meno intuitiva. Un'organizzazione può avere codice impeccabile, revisioni rigorose e un team di sicurezza competente, e venire compromessa da un file che nessuno considera parte del proprio perimetro. La filiera degli strumenti di sviluppo, dai package manager alle estensioni dell'editor, è infrastruttura critica quanto il data center. Chi non la inventaria non può difenderla: il tema è lo stesso che trattiamo in supply chain e terze parti.

La contromisura non è vietare gli strumenti. È governarne la provenienza: fonti autorizzate, mirror interno, verifica delle firme, un elenco di ciò che è ammesso installare e un canale dove segnalare ciò che non lo è.

Settembre: il colloquio come porta d'ingresso

Il secondo passaggio è più scomodo, perché sposta l'attacco fuori dall'IT. Un finto processo di selezione non richiede di forzare un firewall: richiede pazienza, un profilo credibile e la disponibilità dell'azienda a far eseguire codice a uno sconosciuto, spesso con istruzioni del tipo "esegui questo test e mandaci il risultato".

In quel momento l'azienda sospende, di fatto, le regole che applica ai dipendenti. Il candidato non ha un contratto, non ha un dispositivo gestito, non ha ancora un'identità verificata, ma riceve accesso a un ambiente, a un repository o a una macchina su cui gira il test. Il malware nell'esercizio era progettato per eludere i controlli: qualcuno aveva studiato l'ambiente prima di prepararlo.

La selezione è una catena di fornitura di persone, e va trattata come tale: verifica dell'identità, test in ambiente isolato, nessuna credenziale reale consegnata al candidato, codice eseguito in sandbox (ambiente separato e sacrificabile) e non sulla macchina di lavoro.

Il ponte: gli strumenti AI interni

Il passaggio che rende questo caso diverso dai precedenti è il terzo. Gli attaccanti non hanno cercato un server dimenticato: si sono mossi attraverso gli strumenti di AI interni. Un assistente aziendale ha di solito un accesso ampio, perché deve poter leggere codice, ticket, documentazione e conversazioni per essere utile. Spesso gira con un'identità di servizio, un account non umano, e gode di una fiducia che nessuno contestualizza.

Per un attaccante è una mappa: un assistente ben collegato racconta com'è fatta l'azienda. Ed è anche un ponte, perché quella stessa identità può raggiungere sistemi che l'utente compromesso non toccherebbe mai direttamente. Il doppio taglio dell'AI non è teorico: è la differenza tra uno strumento che aumenta la produttività e uno che aumenta la superficie d'attacco, come argomentiamo in AI come arma a doppio taglio.

Il principio dei privilegi minimi vale anche per le identità non umane. Un assistente che legge tutto è comodo e pericoloso. Un assistente che legge ciò che serve al compito è meno spettacolare e molto più difficile da usare come scala.

Venti minuti: cosa dice la velocità

Il quarto passaggio è il sistema che autorizza le transazioni. Arrivarci non basta: bisogna riuscire a farlo funzionare. Oltre sei miliardi in venti minuti significano un numero di operazioni che nessun comitato umano può approvare in quel tempo.

Due spiegazioni sono possibili, e non si escludono. La prima: i controlli a più firme esistevano sulla carta ma sono stati soddisfatti con credenziali compromesse. La seconda: i controlli non c'erano, e un singolo accesso bastava. In entrambi i casi il problema è architetturale. Se un portatile di sviluppo può raggiungere il sistema che firma i trasferimenti, il controllo più importante dell'azienda dipende dalla macchina più esposta.

La velocità è anche il segnale che mancava. Un monitoraggio che guarda solo chi accede non vede nulla; uno che guarda valore, frequenza, orario e sequenza delle operazioni vede una curva che nessuna attività legittima produce. Il firewall aziendale, in questa storia, non avrebbe aiutato: nessuno ha forzato il perimetro di rete. Ha protetto un confine che l'attacco non ha mai attraversato, come spieghiamo in firewall.

L'FBI, Pyongyang e il 98%

Sul piano dell'attribuzione, i fatti vanno tenuti separati dalle ipotesi. L'FBI ha collegato l'attacco al gruppo TraderTraitor, ricondotto ad hacker nordcoreani. Teng non ha attribuito direttamente l'operazione alla Corea del Nord. Pyongyang nega e parla di "provocazione politica". Chi scrive deve dire tutte e tre le cose, nell'ordine in cui sono verificabili.

Sul recupero, Binance ha dichiarato di aver ricostituito il 98% dei beni colpiti. Ha localizzato circa 3 miliardi di dollari; Tether ne ha congelati 1,57 miliardi, Circle oltre 0,8 miliardi, e Ripple e World Liberty Financial hanno partecipato al congelamento. L'exchange ha temporaneamente limitato alcuni prelievi, sostituito dispositivi e credenziali e incaricato un esperto indipendente di rivedere l'accaduto.

"Ricostituito" non significa "recuperato". Un conto può tornare intero perché l'azienda ci mette risorse proprie, mentre una parte dei fondi resta bloccata altrove e una parte è perduta. Il 98% misura la capacità di Binance di reggere l'impatto, non la sconfitta degli attaccanti. Il congelamento di 3 miliardi è la parte più interessante da studiare, perché dipende da rapporti con emittenti di stablecoin (criptovalute ancorate a una valuta) e con altri exchange, attivati in poche ore. Nessuna azienda improvvisa quelle telefonate durante un incidente: o le ha preparate prima, o non le ha.

Cosa resta a un'azienda normale

Questo caso non va ridotto a una lista di buone intenzioni. Il valore sta nei collegamenti. Se Binance avesse chiuso uno solo dei quattro passaggi, la catena si sarebbe spezzata.

Le misure che seguono valgono per ogni impresa che sviluppa software, assume persone e muove denaro. Vanno lette nell'ordine della catena, non come un elenco della spesa.

1. Inventaria la provenienza degli strumenti di sviluppo. Fonti autorizzate, mirror interno dei package manager, verifica delle firme, registro di ciò che è installato. Se non sai da dove arriva un installer, non sai cosa contiene.
2. Tratta la selezione come un accesso. Test in ambienti isolati, nessuna credenziale reale, verifica dell'identità del candidato, codice eseguito in sandbox. Il colloquio è un ingresso, non una cortesia.
3. Applica i privilegi minimi anche a chatbot, agenti e account di servizio. Un assistente AI che legge tutto è una mappa gratuita per chi lo compromette.
4. Monitora il comportamento, non solo gli accessi. Valore, frequenza, orario, sequenze anomale, tentativi di esportazione. Un alert che scatta dopo venti minuti non ferma un furto da sei miliardi.
5. Prepara il congelamento prima di averne bisogno. Contatti con exchange, emittenti e istituzioni, ruoli decisionali, soglie di intervento, comunicazione verso i clienti. È la parte di incident response che si scrive a freddo, non durante l'incidente.

Lunedì mattina

Lunedì mattina chiedi tre cose, e pretendi risposte verificabili. Primo: l'elenco delle fonti software autorizzate e chi le approva. Secondo: chi ha accesso amministrativo ai sistemi che muovono denaro, e da quali macchine. Terzo: quando è stata l'ultima volta che il piano di risposta è stato provato con una simulazione, non solo riletto.

Se una delle tre risposte è "non lo sappiamo" o "lo chiediamo al fornitore", il problema non è Binance. È la stessa catena, con un anello già aperto. Il caso del 29 ottobre è la versione da 6,3 miliardi di un rischio che si presenta ogni giorno in formato più piccolo: uno strumento scaricato, un candidato valutato in fretta, un assistente AI con troppi permessi. La differenza tra un incidente gestito e un disastro è quasi sempre la stessa: quanto presto qualcuno se ne accorge, e quanto è pronto a rispondere.