Bitget, la zero-day era nel perimetro di sicurezza: 387,5 milioni di dollari

Il 2 ottobre 2026 Bitget ha reso pubblica la ricostruzione forense del furto che il 24 settembre ha svuotato i suoi hot e warm wallet. Le indagini condotte da SlowMist e Mandiant indicano una causa che inverte la logica ordinaria della difesa informatica: la compromissione è avvenuta attraverso una vulnerabilità zero-day in prodotti di sicurezza di terze parti, strumenti cioè che dovrebbero proteggere l'infrastruttura e che invece ne hanno costituito il punto di ingresso.

La catena di compromissione: dal nodo Product A al wallet job server

Secondo SlowMist, il primo segnale di attività malevola nei log disponibili risale al 31 agosto 2026. Un servizio in esecuzione su uno dei nodi di "Product A" — la denominazione usata nei report per l'appliance di sicurezza di terze parti il cui vendor non è stato identificato — è stato colpito da una vulnerabilità zero-day. L'attaccante ha eseguito uno script nascosto sotto il processo del servizio, ha lanciato un comando per leggere la variabile d'ambiente contenente la password del database e si è connesso al database stesso.

Il 24 settembre 2026, come documenta Mandiant, l'attore della minaccia ha ottenuto accesso privilegiato non autorizzato alle appliance di sicurezza A e B. Sull'appliance B è stata deployata una web shell con stabilita una connessione Command-and-Control (C2). Sfruttando l'accesso persistente, l'attaccante si è spostato lateralmente verso il production wallet job server di Bitget, dove ha installato pacchetti malevoli.

Il nucleo dell'operazione risiede nel tool di prelievo recuperato da SlowMist dai file cancellati. Il software è descritto come "altamente customizzato" e costruito attorno alla logica di prelievo del wallet system di Bitget. Ha forgiato parametri di prelievo senza compromettere le chiavi private. Mandiant ha esplicitamente escluso che le chiavi private di Bitget siano state compromesse e che i cold wallet siano stati coinvolti.

"Forensic findings indicate that on September 24, 2026, a threat actor gained unauthorised privileged access to Bitget's third party security appliances A and B. The threat actor deployed a web shell onto the security appliance B and established a Command-and-Control (C2) connection." — Mandiant, riportato da BleepingComputer

La finestra temporale: 24 giorni di persistenza, 2 ore e 52 minuti di esfiltrazione

La durata dell'accesso persistente — circa tre settimane tra il primo ingresso e l'esfiltrazione dei fondi — rappresenta uno degli elementi più significativi della ricostruzione. L'attaccante ha operato in modalità stealth attraverso infrastrutture di sicurezza che, per definizione, dispongono di privilegi elevati e di visibilità ampia sulla rete interna.

La fase on-chain è stata rapida e intensiva. Il primo trasferimento verificato è stato alle 18:31 UTC del 24 settembre: 93 TRX, seguiti dopo 11 secondi da 0,84 ETH. Secondo SlowMist, l'intera sequenza di esfiltrazione è durata circa 2 ore e 52 minuti, concludendosi alle 21:23 UTC. In questo lasso di tempo l'attaccante ha distribuito asset su 11 blockchain: Ethereum, XRP Ledger, Zcash, TRON, Arbitrum, Optimism, Base, BNB Smart Chain, Avalanche, Algorand e Celestia.

Attribuzione, impatto e fondi congelati

Bitget attribuisce l'attacco a threat actor nordcoreani basandosi su pattern di comportamento degli IP e analisi on-chain. Secondo il report di BleepingComputer, Elliptic e TRM Labs hanno segnalato sovrapposizioni di wallet utilizzati per riciclare proventi illeciti ottenuti da attacchi precedenti. L'attribuzione rimane una teoria di lavoro: non risulta conferma ufficiale governativa.

L'impatto finanziario è stato quantificato in 387,5 milioni di dollari, revisionato da una stima iniziale di 351,6 milioni dopo l'aggiunta di ZEC e TRON. Circa 1,1 milione di dollari in asset è stato congelato da Circle, Tether e NEAR Intents. Il User Protection Fund di Bitget, con oltre 464 milioni di dollari al momento dell'incidente, copre la perdita. Bitget ha offerto una bounty del 5% per il recupero o il congelamento dei fondi rubati.

Analisi: il paradosso della sicurezza come superficie di attacco

L'incidente Bitget solleva questioni strutturali sulla governance della sicurezza. Le appliance di sicurezza di terze parti operano con privilegi elevati, spesso con accesso a segmenti di rete critici. Quando questi strumenti diventano vettori di compromissione, il perimetro di difesa si trasforma in superficie di attacco.

Il tool di prelievo customizzato — costruito attorno alla logica del wallet system — indica una fase di ricognizione precedente all'attacco. La fonte non specifica come l'attaccante abbia ottenuto o forgiato l'identità del dipendente interno. L'identità del vendor dei prodotti "Product A" e "Product B" non è stata resa pubblica; non emergono CVE assegnati, advisory ufficiali o conferme di patch disponibili.

Cosa cambia

L'incidente lascia domande aperte che riflettono i limiti attuali del dossier:

• Il vendor dei prodotti di sicurezza di terze parti non è stato identificato; non è disponibile un CVE o un advisory ufficiale per la zero-day.
• Non è nota la durata esatta dell'accesso persistente tra il 31 agosto e il 24 settembre, né come l'attaccante abbia mantenuto la persistenza.
• L'attribuzione a threat actor nordcoreani non è confermata da fonti governative ufficiali.
• Non risulta confermata la percentuale precisa di fondi congelati, recuperati o ancora in movimento oltre i dati riportati.

Questa ricostruzione si basa principalmente sul report di CryptoTimes che ha convertito la timeline UTC; le citazioni di SlowMist e Mandiant sono riportate attraverso testate editoriali e non da comunicati primari dei vendor.

Chiusura editoriale

Il caso Bitget documenta un pattern ricorrente nel settore: la compromissione di strumenti di difesa come via di accesso primaria. La persistenza di 24 giorni attraverso appliance di sicurezza, seguita da un'esfiltrazione on-chain di meno di tre ore, evidenzia un disequilibrio tra tempo di preparazione dell'attaccante e tempo di risposta della vittima. Che questo pattern sia sistemico o circoscritto all'architettura specifica di Bitget non è determinabile dal materiale disponibile.