Hack Binance 2026: firme valide, prelievi criminali

Il denaro esce con una firma valida

La sera del 29 ottobre 2026, dagli hot wallet di Binance cominciano a uscire asset per miliardi di dollari. Un hot wallet è un portafoglio operativo con capacità di firma disponibile online: serve, per esempio, a elaborare i prelievi dei clienti.

Il dettaglio che merita attenzione è nelle firme. Secondo l'analisi di Hypernative del 30 ottobre, i trasferimenti usano firme valide dei wallet coinvolti. La blockchain accetta le operazioni. Il disastro avviene dentro il confine di fiducia che decide che cosa far firmare.

Stato della ricostruzione: 31 ottobre 2026, ore 07:36 italiane. L'incidente è ancora in corso di analisi. Le dichiarazioni dell'exchange e le osservazioni delle società di investigazione sono indicate separatamente; il post mortem tecnico completo resta atteso.

Che cosa sappiamo e chi lo dice

Le cifre pubblicate sono stime, con perimetri e momenti di osservazione diversi. Non vanno sommate né trasformate in un saldo definitivo.

Le fonti sono il primo aggiornamento Binance, l'analisi TRM e il rapporto Elliptic. Le divergenze richiedono una riconciliazione dei dati, non una media aritmetica tra i titoli.

Nel secondo comunicato, Binance colloca l'inizio intorno alle 20:05 UTC del 29 ottobre, le 21:05 in Italia. Dichiara prelievi sospesi, depositi operativi e l'impegno a coprire le perdite con SAFU e risorse aziendali. Sono informazioni e impegni dell'azienda: non equivalgono a una verifica indipendente del ripristino completo.

Il laptop è un indizio, la catena d'attacco è ancora aperta

Il primo comunicato ipotizza la compromissione del laptop di un ingegnere DevOps, l'accesso a un container di servizio e l'invio di richieste di prelievo non autorizzate. Il secondo aggiunge che sono emersi ulteriori punti d'intrusione. Fermarsi alla formula «è bastato un portatile» sarebbe già una semplificazione eccessiva.

Binance dichiara inoltre di non aver trovato, a quel momento, prove di fuga delle chiavi private. Questo non risolve il caso. Bisogna distinguere il possesso di una chiave dalla possibilità di ottenere firme attraverso un sistema che la usa.

Pensa a un servizio che custodisce un timbro e accetta richieste da altri programmi. Se un intruso riesce a impartirgli ordini, il timbro può restare nella cassaforte mentre i documenti sbagliati escono regolarmente timbrati. È un'analogia del rischio, non la descrizione verificata dell'infrastruttura interna di Binance.

EIP-7702: la delega che sopravvive alla singola operazione

Su Ethereum emerge un passaggio specifico. TRM descrive una delega EIP-7702 da un hot wallet di Binance a un contratto controllato dall'attaccante, progettato per trasferire gli asset. Le altre reti coinvolte non richiedono lo stesso meccanismo: EIP-7702 non spiega, da solo, l'intero attacco.

La specifica EIP-7702 permette a un account Ethereum controllato da chiave di autorizzare l'esecuzione del codice di un altro indirizzo nel proprio contesto. È una funzione pensata anche per operazioni raggruppate e commissioni pagate da terzi. Il rischio dipende dal codice delegato e dall'autorizzazione concessa.

La delega persiste finché viene sostituita o rimossa. Non scade automaticamente al termine della transazione che l'ha impostata. Un'autorizzazione di questo tipo ha quindi un effetto diverso da un semplice pagamento una tantum.

Hypernative ricostruisce trasferimenti ripetuti dal wallet delegato e la rimozione della delega alle 00:10 UTC del 30 ottobre. È una ragione concreta per monitorare anche i cambiamenti dei poteri di un account, oltre ai trasferimenti di denaro. Analisi Hypernative.

Congelato non significa restituito

Alcuni token consentono agli emittenti di bloccare gli asset su determinati indirizzi. Elliptic documenta congelamenti soprattutto di USDT e USDC e conversioni degli asset rubati in altre criptovalute. Rapporto del 30 ottobre.

Da qui tre voci da tenere separate:

• Congelato: il movimento di determinati asset è bloccato.
• Recuperato: gli asset sono stati effettivamente restituiti o riportati sotto il controllo pertinente.
• Coperto dall'exchange: l'operatore mette risorse proprie a fronte dell'ammanco.

Confondere queste voci fa sembrare conclusa una risposta all'incidente che può avere ancora molto lavoro davanti.

Chi c'è dietro: un'attribuzione, non un nome da dare per certo

TRM attribuisce l'operazione con elevata confidenza a TraderTraitor, gruppo legato alla Corea del Nord. È una valutazione della società basata su intelligence on-chain e off-chain; il comunicato Binance citato non identifica gli autori. Valutazione TRM.

La blockchain rende osservabili i trasferimenti. Collegare gli indirizzi a persone o organizzazioni richiede prove aggiuntive. Una sequenza riconoscibile può sostenere un'ipotesi, ma non trasforma da sola una somiglianza in identità.

Tre incidenti diversi: 2019, 2022 e 2026

Nel maggio 2019 Binance comunicò il furto di 7.000 BTC, associato alla compromissione di informazioni degli utenti, comprese chiavi API e codici 2FA. Comunicazione del 7 maggio 2019.

Nell'ottobre 2022 fu colpito il bridge BSC Token Hub: BNB Chain descrisse prove falsificate e il prelievo di due milioni di BNB. Aggiornamento BNB Chain.

L'attacco del 2026 riguarda gli hot wallet dell'exchange e la loro capacità di firma. Stesso ecosistema nel titolo, confini tecnici diversi. Mescolare i tre episodi produce una spiegazione che non corrisponde a nessuno dei tre.

Cosa controllare nei sistemi che firmano

Per uno sviluppatore o un sistemista, il caso suggerisce un esercizio utile anche fuori dalle criptovalute. Vale per certificati, release software, pagamenti e automazioni privilegiate: mappare il percorso dalla richiesta alla firma.

1. Chi può chiedere una firma? Elenca persone, servizi, credenziali e percorsi di emergenza. Un'autenticazione valida deve essere seguita da un controllo sull'operazione richiesta.
2. Quali limiti vengono applicati prima di firmare? Importo, destinazione, tipo di messaggio e poteri concessi devono essere comprensibili al sistema di autorizzazione.
3. Una delega richiede controlli diversi da un trasferimento? Un permesso persistente può cambiare anche le operazioni future.
4. Come si interrompe davvero l'abuso? Prova in un ambiente di test la revoca degli accessi e dei permessi persistenti. Spegnere l'interfaccia non garantisce che ogni percorso operativo sia chiuso.
5. I log collegano richiesta, approvazione e risultato? L'identificativo della transazione è solo un pezzo della storia. Servono anche identità del servizio, policy applicata ed esito del controllo.

Sono domande di progettazione difensiva, non un elenco di carenze già provate in Binance. La distinzione conta quanto i dettagli dell'attacco.

Lo stesso problema compare, su un altro terreno, nel significato del badge Verified di GitHub e delle firme sui commit. Per esercitarsi a ricostruire un incidente dai reperti, c'è il percorso sui laboratori Sherlocks e l'analisi dei log.

Il post mortem dovrà spiegare come sono state autorizzate le firme, quali confini siano stati attraversati e come siano stati rimossi i poteri concessi. È lì che questa storia diventa utile a chi costruisce sistemi: nel punto in cui un'operazione tecnicamente valida deve ancora dimostrare di essere legittima.