Bitget: credenziali rubate e una falla in un prodotto di sicurezza all’origine del furto da 388 milioni di dollari

L’exchange di criptovalute Bitget afferma che un attaccante ha sfruttato una vulnerabilità zero-day in un prodotto di sicurezza di terze parti non identificato, ottenendo accesso privilegiato ai sistemi interni e sottraendo circa 388 milioni di dollari.

Secondo le prime conclusioni dell’indagine dell’exchange, l’intrusione non ha coinvolto la compromissione delle chiavi private dei wallet. L’attaccante avrebbe invece ottenuto credenziali interne di alto livello e sfruttato le legittime procedure amministrative di Bitget per inviare istruzioni di prelievo fraudolente.

I fondi sono stati sottratti da alcuni wallet hot e warm dell’exchange. I wallet cold offline non sono stati coinvolti.

Le credenziali rubate hanno aperto l’accesso ai servizi dei wallet

La CEO di Bitget, Gracy Chen, ha descritto la vulnerabilità del prodotto di terze parti come una zero-day: quando l’attaccante l’ha sfruttata, l’exchange non disponeva ancora di una correzione fornita dal produttore. Bitget non ha identificato il prodotto, il suo sviluppatore né le versioni interessate.

La mancata divulgazione lascia senza risposta diverse domande tecniche. Non è noto quale tipo di vulnerabilità sia stato sfruttato, se l’autenticazione sia stata aggirata o in che modo la falla abbia esposto le credenziali privilegiate di Bitget.

Non è stato comunicato alcun identificativo CVE. Di conseguenza, non ci sono informazioni confermate neppure sullo stato della vulnerabilità nel catalogo Known Exploited Vulnerabilities della Cybersecurity and Infrastructure Security Agency statunitense.

Secondo quanto riferito, l’exploit ha consentito di accedere a un sistema di gestione interno e a credenziali di alto livello. Queste hanno poi permesso all’intruso di raggiungere i servizi backend coinvolti nelle transazioni dei wallet.

In precedenza Bitget aveva dichiarato che un componente critico del backend dei wallet era stato compromesso e manipolato per generare dati di transazione falsi e avviare le approvazioni. Le informazioni più recenti chiariscono il punto d’ingresso iniziale: una vulnerabilità nel software fornito da un’azienda esterna specializzata in sicurezza.

L’attaccante ha comunque dovuto muoversi all’interno del flusso di transazioni di Bitget. I trasferimenti dovevano essere approvati prima della firma, quindi l’accesso a un singolo componente del wallet non era necessariamente sufficiente per spostare i fondi.

Prima del furto principale sono stati effettuati piccoli trasferimenti di prova

I prelievi fraudolenti sono iniziati il 24 settembre. Invece di tentare subito un trasferimento ingente, l’attaccante ha prima verificato la procedura con due piccole transazioni, alle 18:31 UTC.

Entrambe sono rimaste al di sotto della soglia dei controlli di rischio di Bitget e non hanno generato alcun avviso. I prelievi più consistenti sono iniziati circa 30 minuti dopo.

L’uso di credenziali interne valide è stato determinante per l’attacco. Il backend legato ai wallet ha accettato i comandi di prelievo come legittimi e li ha inoltrati attraverso la normale procedura di approvazione. Chen ha dichiarato che l’attività era stata configurata in modo da sembrare una normale operazione amministrativa, riducendo la probabilità che i controlli automatici o i dipendenti la riconoscessero come malevola.

L’attaccante ha anche cercato di cancellare le tracce dell’operazione. Non è noto quanto fosse estesa questa attività né se gli investigatori siano riusciti a recuperare le prove eliminate.

Questo percorso aiuta a capire perché le misure di protezione dei wallet non abbiano fermato i trasferimenti. L’avversario non ha dovuto falsificare un accesso dall’esterno né sottrarre direttamente le chiavi crittografiche: ha agito attraverso identità interne considerate affidabili, inviando comandi in un formato previsto dai sistemi di Bitget.

I controlli basati soprattutto sull’importo delle transazioni, sulla validità delle credenziali o su comportamenti amministrativi apparentemente normali possono rivelarsi inefficaci in uno scenario del genere. I primi due trasferimenti sono serviti a verificare se sarebbero intervenuti prima di procedere con lo spostamento di somme più ingenti.

La perdita ha riguardato i wallet hot e warm

Gli asset sottratti provenivano da alcuni wallet hot e warm di Bitget, più accessibili rispetto alla conservazione offline perché servono a garantire la liquidità operativa e a gestire i prelievi.

Bitget afferma che i wallet cold non sono stati coinvolti. La società sostiene inoltre di non aver trovato prove della compromissione delle chiavi private dei wallet, anche se le indagini sono ancora in corso.

Questa distinzione è importante per definire la portata dell’incidente. Una chiave privata rubata potrebbe consentire a un attaccante di firmare transazioni senza passare dai sistemi interni dell’exchange. In questo caso, invece, l’attacco segnalato si è basato sull’accesso all’infrastruttura backend di Bitget e ai suoi meccanismi di approvazione.

L’exchange dichiara che i saldi dei clienti sono rimasti intatti. Il Protection Fund, una riserva destinata a coprire le perdite legate a incidenti di sicurezza, coprirà gli asset mancanti.

Agli utenti non viene chiesto di reimpostare le credenziali, trasferire i fondi o adottare altre misure correttive. Al momento non ci sono indicazioni che gli account dei singoli clienti siano stati il punto d’ingresso.

I prelievi di Bitcoin sono ripresi lunedì. Quelli degli altri asset torneranno gradualmente entro il 2 ottobre.

Sistemi isolati mentre il fornitore interviene sulla vulnerabilità

Bitget ha informato il produttore del prodotto non identificato e ha disattivato la funzionalità interessata. Non ha specificato se il fornitore abbia rilasciato una patch o un’altra correzione definitiva.

Senza il nome del prodotto, le informazioni sulla versione o un identificativo della vulnerabilità, le altre organizzazioni non possono stabilire se utilizzino la stessa tecnologia interessata. Non possono neppure verificare in modo indipendente se sia disponibile un aggiornamento.

Bitget ha isolato i sistemi coinvolti nell’incidente, revocato le credenziali interne e ne ha emesse di nuove. Ha inoltre limitato gli accessi interni, introdotto verifiche indipendenti sui prelievi e potenziato il monitoraggio delle attività anomale.

L’exchange intende rivedere i criteri con cui seleziona, valuta e implementa i prodotti di sicurezza di terze parti. L’incidente mette in luce un rischio complesso legato alla catena di fornitura: il software installato per proteggere infrastrutture sensibili può diventare a sua volta una porta d’accesso a quegli ambienti.

Una convalida indipendente dei prelievi potrebbe ridurre i rischi legati alla compromissione di un singolo livello di gestione, soprattutto se la seconda verifica si basa su credenziali, dati di telemetria e confini di fiducia separati. Bitget non ha reso nota l’architettura dei nuovi controlli.

Mandiant e SlowMist stanno collaborando alle indagini. Bitget prevede di pubblicare un rapporto formale sull’incidente nel corso della settimana: il documento potrebbe chiarire quale componente sia stato sfruttato, come siano state ottenute le credenziali e in quale sequenza siano avvenute le approvazioni.

L’attribuzione alla Corea del Nord non è confermata

In precedenza Bitget aveva dichiarato che i responsabili fossero probabilmente hacker nordcoreani. Chen ha detto a The Hacker News che l’exchange continua a sospettare lo stesso attore, ma non ha voluto indicare un gruppo specifico prima della pubblicazione del rapporto sull’incidente.

TRM Labs ha rilevato sovrapposizioni tra gli asset rubati e wallet già utilizzati per riciclare i proventi di furti attribuiti alla Corea del Nord. La società di intelligence blockchain ha affermato che l’attività rimandava a TraderTraitor, senza però formulare un’attribuzione definitiva.

La sola sovrapposizione delle transazioni non basta a stabilire chi abbia condotto l’intrusione. L’uso della stessa infrastruttura di riciclaggio, di servizi intermediari o di indirizzi già impiegati può contribuire a una valutazione, ma non dimostra necessariamente che a compiere la compromissione iniziale siano stati gli stessi operatori.

Il passaggio dei fondi attraverso bridge e servizi di swap cross-chain rende più difficile tracciarli. Questi servizi possono modificare sia la rete sia l’asset coinvolto, rendendo insufficiente il semplice monitoraggio dei trasferimenti diretti.

Indirizzi dei destinatari e tracciamento delle esposizioni indirette

Il 25 settembre Bitget ha pubblicato gli indirizzi dei destinatari, insieme a una dashboard di tracciamento in tempo reale e a un portale per il recupero dei fondi. Ha chiesto a exchange, custodi, emittenti di stablecoin, bridge e altri operatori dell’infrastruttura di segnalare le attività correlate.

Gli indirizzi divulgati sono:

• Reti Ethereum ed EVM: 0x770b10b273fc44fe9197d6bf20f145c2e98463ee
• XRP: rwNhefsz1UQEusxhCvHip3RANinWi4CTck
• Zcash: t1WgMdtND8NF7NDUuYmq8MpMj1NTCXkMDVG
• TRON: TBWNguTTgezw9dVorX441C6nDrZpRxYwKD

TRM ha raccomandato alle aziende di criptovalute di non limitare i controlli ai depositi inviati direttamente da questi indirizzi. Gli investigatori si aspettano che i fondi rubati arrivino dopo essere passati per diversi wallet intermediari e attraverso più reti.

I team di compliance dovrebbero quindi monitorare gli indirizzi a valle contrassegnati e le esposizioni indirette, soprattutto dopo attività che coinvolgono bridge o swap cross-chain. È più probabile che un deposito provenga da un indirizzo a diversi passaggi di distanza dal furto originale che da un indirizzo di destinatario identificato pubblicamente.

Per gli altri potenziali utilizzatori del prodotto di sicurezza vulnerabile, al momento non sono disponibili indicazioni specifiche. Non sono stati divulgati il nome del fornitore, le versioni interessate, lo stato delle patch né gli indicatori tecnici.