Bitget ha perso circa 387,5 milioni di dollari il 24 settembre 2026, dopo che gli attaccanti hanno sfruttato un prodotto di sicurezza di terze parti, ottenuto credenziali interne di alto livello e inviato comandi di prelievo falsificati attraverso l’infrastruttura dei wallet dell’exchange.
L’incidente è il più grande furto di criptovalute del 2026 finora registrato e il più rilevante singolo furto attribuito alla Corea del Nord nel 2026, secondo recenti valutazioni analitiche. La prima stima di Bitget era di 351,6 milioni di dollari, ma la cifra è aumentata dopo che gli investigatori hanno tracciato ulteriori trasferimenti di Zcash e TRON. Le prime stime indipendenti sulla blockchain avevano collocato la perdita tra circa 174 milioni e 183 milioni di dollari.
Punto chiave: L’exploit di Bitget non è stato un furto tradizionale di chiavi private. Gli attaccanti hanno compromesso un livello di sicurezza affidabile, fatto sembrare legittimi comandi di prelievo malevoli durante il processo di autorizzazione e utilizzato wallet hot e warm per muovere circa 387,5 milioni di dollari prima che i controlli fermassero la perdita.
Come ha aggirato il hack di Bitget i controlli di sicurezza dell’exchange?
L’attacco a Bitget ha superato i controlli di sicurezza compromettendo un sistema backend critico collegato all’infrastruttura dei wallet, ottenendo credenziali interne, spoofando dati delle transazioni e iniettando comandi di prelievo fraudolenti. Bitget ha dichiarato che i comandi sono passati i controlli di rischio dell’exchange perché il processo di autorizzazione riceveva informazioni sulla transazione che sembravano rappresentare prelievi di routine e legittimi.
Bitget ha descritto la vulnerabilità di terze parti come un zero-day durante una livestream, mentre la spiegazione ufficiale ha usato un linguaggio più cauto. L’exchange non ha nominato il vendor. Bitget ha affermato di aver notificato il fornitore, condiviso dettagli sulla vulnerabilità e disabilitato la funzionalità interessata in attesa di una patch.
L’intera catena dell’attacco può essere rappresentata in cinque fasi collegate:
- Compromissione di terze parti: L’attaccante ha sfruttato una vulnerabilità di un prodotto di sicurezza utilizzato nell’ambiente di Bitget.
- Accesso alle credenziali: L’attaccante ha ottenuto credenziali interne di alto livello.
- Manipolazione del backend: L’attaccante ha compromesso un sistema backend critico all’interno dell’infrastruttura dei wallet.
- Spoofing delle transazioni: L’attaccante ha alterato o falsificato dati delle transazioni presentate al processo di autorizzazione.
- Esecuzione del prelievo: Comandi di prelievo falsificati hanno eluso i controlli di rischio e spostato asset da wallet hot e warm.
La differenza tra compromissione della chiave di firma e compromissione del livello di autorizzazione è significativa. Bitget ha dichiarato che i wallet cold, le chiavi private, i saldi degli account utente e il Wallet di Bitget auto custodito non sono stati compromessi. Le operazioni di trading e depositi sono continuate, sebbene i prelievi a livello di piattaforma siano stati bloccati dopo che il sistema di riconciliazione aveva rilevato una discrepanza.
L’attacco quindi ha mirato alla capacità dell’exchange di determinare se una richiesta di prelievo fosse affidabile o meno. Un comando dall’aspetto valido può essere pericoloso anche quando la firma crittografica è intatta. Se il sistema che prepara, descrive, instrada o approva una transazione viene compromesso, il processo di firma può autorizzare fedelmente un’istruzione che l’exchange non aveva mai voluto emettere.
“Dalla nostra esperienza di auditing di smart contract e infrastrutture di wallet in Soken, l’integrità dell’autorizzazione è più ampia della semplice protezione delle chiavi private. Un sistema può conservare le proprie chiavi e comunque perdere il controllo sui fondi quando dati backend compromessi vengono trattati come una descrizione autorevole di ciò che un firmatario sta approvando.”
L’incidente di Bitget ha anche incluso prove di attività anti-forensics. L’attaccante ha cancellato tracce dei comandi iniettati, cosa che Gracy Chen ha definito la parte più difficile dell’operazione. Questo comportamento evidenzia una particolare esigenza di risposta incidentale: gli exchange devono conservare registri indipendenti e resistenti alle manomissioni di creazione, approvazione, firma e broadcast dei comandi.
Un design sicuro non dovrebbe affidarsi a un singolo sistema interno per creare una richiesta di prelievo e descriverla all’approvatore. La ricostruzione indipendente delle transazioni, controlli di policy out-of-band, log di audit immutabili e una severa separazione tra strumenti di sicurezza e operazioni sui wallet rendono più facile individuare comandi falsificati.
Cosa è successo durante la timeline dello sfruttamento di Bitget?
L’exploit di Bitget si è sviluppato da piccoli trasferimenti di test a un drenaggio multi-chain prima che il sistema di riconciliazione automatica rilevasse una discrepanza. I primi trasferimenti non autorizzati sono apparsi alle 18:31 UTC del 24 settembre 2026. Il principale drenaggio ha continuato dalle 18:58 alle 20:09 UTC, con 17 transazioni su 8 chain, mentre l’ultimo trasferimento dell’attaccante è stato osservato alle 21:23 UTC.
| Ora o data | Evento dell’incidente di Bitget | Significato di sicurezza |
|---|---|---|
| 18:31 UTC, 24 settembre | Rilevati i primi trasferimenti non autorizzati da wallet hot e warm | Due trasferimenti di prova, 0,184 ETH e 193 TRX, rimasero sotto soglie di rischio |
| 18:58 - 20:09 UTC, 24 settembre | Esecuzione del drenaggio principale in 17 transazioni su 8 chain | Circa 361 milioni di dollari trasferiti durante la sequenza principale |
| 19:05 UTC, 24 settembre | Rilevata discrepanza nel sistema di riconciliazione | Prelievi a livello di piattaforma bloccati |
| 20:40 UTC, 24 settembre | Bitget ha iniziato a spostare i fondi rimanenti in cold storage | Esposizione residua dei wallet ridotta |
| 21:23 UTC, 24 settembre | Ultimo trasferimento dell’attaccante sulla blockchain | L’ultimo trasferimento è avvenuto a 2 ore e 52 minuti dal primo test |
| 21:44 UTC, 24 settembre | Servizi wallet e firma interrotti | Operazioni di firma sospese |
| 25 settembre, 08:43 UTC | Bitget ha identificato la causa principale | Indagine passata da contenimento a rimedio |
| 25 settembre, 13:42 UTC | Notificata alle forze dell’ordine | Inizio escalation dell’incidente da parte esterna |
| 28 settembre, 08:00 UTC | Ristartate le uscite in BTC | Inizio della riapertura graduale |
| 29 settembre, 08:00 UTC | Ristartano le uscite ETH | La fase successiva alla riapertura BTC |
| 30 settembre, 08:00 UTC | Sono previste le uscite USDT | L’esecuzione delle fasi successive non è stata confermata con le informazioni disponibili |
| 2 ottobre, 08:00 UTC | Sono previste altre attività su token, fiat e P2P | La riapertura copre altri servizi |
I due trasferimenti iniziali erano progettati per passare sotto soglie esistenti. Gli importi di test, 0,184 ETH e 193 TRX, non hanno attivato allarmi. Questo dimostra perché il monitoraggio basato solo su soglie è debole contro attacchi a fasi. Un attore malintenzionato può prima validare il funzionamento di un percorso di autorizzazione, poi aumentare le dimensioni delle transazioni una volta che il sistema appare stabile.
La timeline di Bitget e l’indagine sulla blockchain differiscono leggermente sui limiti esatti del drenaggio principale. Il CEO di Bitget ha descritto la sequenza centrale come dall’18:58 al 20:09 UTC, mentre i dati sulla blockchain mostrano flussi tra le 19:01 e le 19:16 UTC. Questi dettagli non modificano la conclusione fondamentale: l’attaccante aveva un percorso di prelievo funzionante per meno di tre ore prima che si osservasse l’ultimo trasferimento.
La prima ora dopo la riapertura dei prelievi BTC ha visto il processamento di più di 3.000 BTC, secondo quanto dichiarato dal CEO di Bitget. Questo dettaglio operativo importa perché riaprire un exchange dopo un incidente sui wallet crea un secondo problema di controllo. La piattaforma deve ripristinare l’accesso dei clienti senza reinserire il percorso di approvazione compromesso o permettere un’ondata di prelievi legittimi che possa coprire ulteriori attività non autorizzate.
Una riapertura in fasi è quindi più di un semplice calendario di servizio clienti. È una strategia di contenimento che permette di monitorare asset specifici, riconciliare i wallet, ruotare le credenziali e validare progressivamente i controlli di prelievo.
Quali asset sono stati colpiti e come si è sviluppata la perdita di 387,5 milioni di dollari?
L’ultima stima di perdita di Bitget si aggira intorno ai 387,5 milioni di dollari su 13 asset e 11 reti, sebbene i tracker indipendenti abbiano contato tra 7 e 11 reti interessate. XRP rappresentava l’esposizione singola più grande, con circa 102,98 milioni di XRP, valutati circa 157,8 milioni di dollari, mentre ETH rappresentava circa 126,6 milioni di dollari nella suddivisione on-chain.
Le comunicazioni pubbliche e le indagini sulla blockchain hanno riportato la seguente ripartizione approssimativa degli asset:
| Asset | Quantità o valore approssimativo | Dettaglio osservato |
|---|---|---|
| XRP | 102,98 milioni di XRP, circa 157,8 milioni di dollari | Esposizione singola più grande |
| ETH | Circa 126,6 milioni di dollari | Parte del drenaggio multi-chain |
| USDT su Arbitrum | Circa 19,7 milioni di dollari | Esposizione stablecoin su Arbitrum |
| AVAX | Circa 16,8 milioni di dollari | Includo nel breakdown degli asset tracciati |
| BNB | Circa 9,9 milioni di dollari | Includo nel breakdown degli asset tracciati |
| TRX | Circa 7,0 milioni di dollari | Dato confermato da più tracker |
| Perdita totale di Bitget | Circa 387,5 milioni di dollari | Rivista dopo aver tracciato trasferimenti di Zcash e TRON |
Gli asset rubati comprendevano XRP, ETH, USDT, ZEC, ATOM, USDC, BNB, AVAX, TRX, ALGO, TIA e XAUt. La prima stima pubblica di Bitget del 24 settembre era di 351,6 milioni di dollari. Dopo l’identificazione di ulteriori trasferimenti di Zcash e TRON, la stima è aumentata.
XRP ha rappresentato una sfida di recupero specifica perché XRP non può essere congelato dall’emittente. Entro il 26 settembre circa 83 milioni di dollari di XRP rubati erano passati fuori dai wallet di detenzione dell’attaccante. Una volta che i fondi lasciano un indirizzo di detenzione e entrano in rotte di conversione o cross-chain, gli investigatori devono seguire sia i fondi che i servizi che li processano.
Il pattern di riciclaggio si basi sulla rapida conversione di stablecoin in ETH, seguita da swap in BTC. Gli investigatori hanno identificato THORChain come la principale via per i BTC, con Chainflip, deBridge, SwapKit e Wasabi CoinJoin che compaiono anche nel percorso di riciclaggio. Il 28 settembre, un wallet collegato a un hacker ha scambiato circa 2.390 ETH, valutati circa 6,3 milioni di dollari, per 75,2 BTC tramite THORChain in batch di circa 100 ETH.
La risposta ha evidenziato una tensione politica tra infrastrutture decentralizzate e contenimento dell’incidente. THORChain ha rifiutato la richiesta di Bitget di bloccare l’hacker, affermando che “una sospensione non è una congelazione selettiva di fondi specifici.” Chen ha risposto che “la decentralizzazione è un principio di progettazione, non uno scudo per facilitare fondi già rubati.”
Quella conversazione mostra perché la coordinazione pre-incidente sia importante. I protocolli decentralizzati potrebbero non avere la capacità universale di individuare o bloccare una singola transazione senza influenzare un percorso più ampio. Gli exchange centralizzati, gli emittenti di stablecoin, gli operatori di bridge e i sistemi basati su intenti applicano regole di intervento diverse. Un exchange che aspetta di agire solo dopo un exploit ha meno opzioni durante le prime ore di riciclaggio.
C cosa rivela l’attacco di Bitget riguardo ai rischi di terze parti e livello di autorizzazione?
L’attacco di Bitget evidenzia che la sicurezza dell’exchange dipende tanto dal software di terze parti, dalle credenziali interne, dalla presentazione delle transazioni e dalle policy di rischio quanto dalla custodia delle chiavi crittografiche. Bitget, Bybit, DMM Bitcoin e WazirX mostrano un modello ricorrente: gli attaccanti hanno compromesso un fornitore affidabile o il livello di autorizzazione affinché una transazione malevola apparisse legittima al processo di firma o autorizzazione.
| Incidente | Data | Livello compromesso | Perdita o ambito segnalato | Lezione principale |
|---|---|---|---|---|
| Bitget | 24 settembre 2026 | Prodotto di sicurezza di terze parti e backend dei wallet | Circa 387,5 milioni di dollari | Comandi di prelievo falsificati bypassavano i controlli di rischio |
| Bybit | 21 febbraio 2025 | Macchina di sviluppo Safe{Wallet} e interfaccia di firma | Circa 1,46 miliardi di dollari | Codice malevolo modificava l’ambiente di approvazione delle transazioni |
| DMM Bitcoin | maggio 2024 | Dipendente del fornitore di software wallet e workflow di firma | Circa 305-308 milioni di dollari | Un compromesso del fornitore ha consentito attività wallet non autorizzate |
| WazirX | 18 luglio 2024 | Contratto di wallet multisig e workflow di custodia | Circa 235 milioni di dollari | I firmatari hanno approvato transazioni dopo la modifica del contratto |
| Coinbase | rivelato maggio 2025 | Agenti di supporto stranieri e dati clienti | Stima di remediation tra 180 e 400 milioni di dollari | La compromissione dei dati clienti può creare un’esposizione operativa importante senza furto di chiavi |
Il fallimento più ricorrente non è la distruzione della crittografia, bensì la perdita del contesto affidabile attorno a una transazione. Un firmatario può vedere una richiesta valida, un formato di destinazione familiare e un flusso di approvazione normale, mentre l’istruzione sottostante sia stata sostituita o manipolata.
Per gli exchange, ciò richiede controlli in diversi punti indipendenti:
- Isolamento dei vendor: I prodotti di sicurezza di terze parti non devono avere accesso inutile alla generazione di comandi wallet o a credenziali privilegiate.
- Separazione delle credenziali: Le credenziali interne devono essere limitate a funzioni specifiche, ruotando dopo attività sospette, e non autorizzare di default prelievi multi-chain ampi.
- Ricostruzione indipendente delle transazioni: L’interfaccia di approvazione dovrebbe derivare i dettagli della transazione da una fonte indipendente, anziché fidarsi dello stesso backend che ha creato la richiesta.
- Diversity di policy: Le grandi uscite dovrebbero passare attraverso regole gestite separatamente dal backend operativo dei wallet.
- Registri immutabili: I log devono essere conservati in ambienti esterni all’ecosistema compromesso e includere creazione, modifica, approvazione, firma e broadcast dei comandi.
- Transazioni canary: Piccoli trasferimenti di test non devono essere considerati sicuri solo perché sotto soglia. Test ripetuti, destinazioni insolite e pattern cross-chain richiedono correlazioni.
- Shutdown d’emergenza: L’exchange deve poter fermare la firma e isolare i servizi dei wallet senza mettere offline i sistemi di trading e deposito correlati.
Bitget ha affermato di aver isolato i server interessati, revocato e re-issuato le credenziali interne e ristrutturato l’accesso a sistemi sensibili. L’exchange ha inoltre dichiarato di aver corretto la vulnerabilità. Questi passaggi affrontano il contenimento, ma è necessario un controllo più approfondito per verificare se i dati di transazione possano ancora essere manipolati prima dell’approvazione.
I servizi di [smart contract audit e sicurezza blockchain] di Soken sono rilevanti perché l’infrastruttura dei wallet spesso combina smart contract, servizi di firma, API backend, sistemi di gestione delle chiavi e strumenti di terze parti. Una valutazione limitata al codice Solidity non testerebbe se un servizio compromesso possa alterare i dati che un firmatario vede.
Quanto sono state efficaci le misure di recupero e le dichiarazioni di attribuzione?
Le misure di recupero hanno prodotto pochi ristorni confermati entro il 29 settembre 2026, mentre l’attribuzione è rimasta probabilistica e non ufficiale. Circle e Tether hanno congelato circa 339.100 dollari totali, e NEAR Intents ha dichiarato di aver rigettato più di 50 milioni di dollari di trasferimenti collegati a Bitget e ha congelato 503.000 dollari. Finora nessun fondo rubato a Bitget è stato effettivamente recuperato.
Le azioni di recupero riportate erano:
| Entità o meccanismo di risposta | Azione segnalata | Importo |
|---|---|---|
| Circle e Tether | Congelato USDC e USDT | Circa 339.100 dollari totali |
| Saldi di stablecoin | 239.113,50 USDT e 99.989,91 USDC congelati | Inclusi nei 339.100 dollari |
| NEAR Intents | Rifiutate le transazioni di Bitget | Più di 50 milioni di dollari |
| NEAR Intents | Congelati tentativi di trasferimenti collegati a Bitget | 503.000 dollari |
| Bitget | Offerto bounty per intervento e recupero | 5% per il freezing più 5% per il recupero |
La differenza tra flusso rifiutato e fondi recuperati è cruciale. Un sistema di screening può impedire ai fondi di entrare in un determinato percorso senza restituire quelli già sotto controllo dell’attaccante. Allo stesso modo, i freeze degli emittenti coprono solo alcuni saldi di stablecoin, mentre XRP, ETH, BTC o asset in infrastrutture permissionless possono non essere bloccati.
Anche l’attribuzione richiede un linguaggio accurato. Le valutazioni analitiche descrivono l’attacco come molto probabile sia di origine nordcoreana e identificano sovrapposizioni con wallet coinvolti negli hack di Bybit e AFX Bridge. Un’altra analisi ha descritto un sindacato alla TraderTraitor, ma non ha attribuito in modo definitivo l’incidente di Bitget. Ad oggi, nessuna agenzia governativa ha attribuito formalmente l’attacco al 29 settembre 2026.
Il quadro più ampio è consistente. Con Bitget incluso, il furto di crypto collegato alla Corea del Nord del 2026 ha superato il miliardo di dollari in oltre 50 incidenti. Una stima del settore colloca la cifra totale a 1,04 miliardi di dollari, facendo del 2026 il secondo anno più grande dopo il 2025, stimato a 1,68 miliardi.
Il CEO di Bitget ha dichiarato che l’attaccante molto probabilmente era un gruppo nordcoreano. Questa affermazione rappresenta un indicatore di rischio operativo, non una attribuzione formale. I team di sicurezza dovrebbero usare le sovrapposizioni di wallet e i pattern di riciclaggio per guidare le rilevazioni, mantenendo l’incertezza nelle dichiarazioni pubbliche e nei processi legali.
Bitget ha anche dichiarato che il 100% dei fondi degli utenti era coperto dal Fondo di Protezione di Bitget, che deteneva 5.500 BTC, valutati circa 464 milioni di dollari all’epoca. L’exchange si è impegnato a reintegrare il fondo fino ad almeno 300 milioni di dollari entro una settimana, usando riserve societarie di oltre 1,4 miliardi di dollari. Questi impegni garantiscono la solvibilità dei clienti, ma non eliminano la necessità di riparare l’architettura di approvazione che ha permesso ai comandi di prelievo di passare.
Il token BGB è sceso di circa il 3%-7% dopo l’incidente, toccando un minimo intorno a 1,89-1,93 dollari, prima di recuperare a circa 1,97. La reazione di mercato riflette quindi sia il rischio di perdita di fiducia che la perdita diretta sui wallet.
La risposta di Bitget può essere seguita insieme alla più ampia ricerca sugli incidenti tramite il centro di ricerca di sicurezza di Soken, mentre le organizzazioni che revisionano la governance dell’exchange possono usare supporto di audit tecnico e risposta a incidenti per testare i limiti delle credenziali, l’integrità delle transazioni e i controlli di emergenza.