Il 24 settembre 2026 Bitget ha perso circa 387,5 milioni di dollari dopo che gli attaccanti hanno sfruttato un prodotto di sicurezza di terze parti, ottenuto credenziali interne di alto livello e fatto passare comandi di prelievo falsificati attraverso l’infrastruttura wallet dell’exchange.
Secondo recenti valutazioni di società di analisi, l’incidente è finora il più grande furto di criptovalute del 2026 e il più grande furto singolo attribuito alla Corea del Nord nel 2026. La prima stima di Bitget era di 351,6 milioni di dollari, ma la cifra è salita dopo che gli investigatori hanno tracciato ulteriori trasferimenti su Zcash e TRON. Le prime stime on-chain indipendenti avevano collocato la perdita tra circa 174 milioni e 183 milioni di dollari.
In sintesi: l’exploit di Bitget non è stato un furto convenzionale di chiavi private. Gli attaccanti hanno compromesso un livello di sicurezza considerato affidabile, hanno fatto apparire legittime al processo di autorizzazione istruzioni di prelievo malevole e hanno usato hot wallet e warm wallet per spostare circa 387,5 milioni di dollari prima che i controlli fermassero lo svuotamento.
In che modo l’hack di Bitget ha aggirato i controlli di sicurezza dell’exchange?
L’hack di Bitget ha aggirato i controlli di sicurezza dell’exchange compromettendo un sistema backend critico collegato all’infrastruttura wallet, ottenendo credenziali interne, falsificando i dati delle transazioni e iniettando comandi di prelievo fraudolenti. Bitget ha dichiarato che i comandi hanno superato i controlli di rischio dell’exchange perché il processo di autorizzazione ha ricevuto informazioni sulle transazioni che sembravano corrispondere a prelievi ordinari e legittimi.
Durante una diretta streaming Bitget ha descritto la vulnerabilità di terze parti come uno zero-day, mentre nella spiegazione ufficiale ha usato un linguaggio più cauto. L’exchange non ha reso noto il nome del fornitore. Bitget ha dichiarato di aver avvisato il fornitore, di aver condiviso i dettagli della vulnerabilità e di aver disattivato la funzionalità interessata in attesa di una correzione.
La catena d’attacco può essere rappresentata in cinque fasi collegate:
- Compromissione di terze parti: l’attaccante ha sfruttato una vulnerabilità in 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 wallet.
- Falsificazione delle transazioni: l’attaccante ha alterato o falsificato i dati delle transazioni presentati al processo di autorizzazione.
- Esecuzione dei prelievi: comandi di prelievo falsificati hanno aggirato i controlli di rischio e spostato asset da hot wallet e warm wallet.
La distinzione tra compromissione delle chiavi di firma e compromissione del livello di autorizzazione è rilevante. Bitget ha dichiarato che i cold wallet, le chiavi private, i saldi dei conti degli utenti e Bitget Wallet, il wallet self-custody, non sono stati compromessi. Trading e depositi hanno continuato a funzionare, anche se i prelievi sono stati bloccati sull’intera piattaforma dopo che il sistema di riconciliazione ha rilevato una discrepanza.
L’attacco ha quindi preso di mira la capacità dell’exchange di stabilire se una richiesta di prelievo fosse affidabile. Un comando dall’aspetto valido può essere pericoloso anche quando la firma crittografica resta integra. Se il sistema che prepara, descrive, instrada o approva una transazione è compromesso, il processo di firma può autorizzare fedelmente un’istruzione che l’exchange non ha mai inteso emettere.
“Nella nostra esperienza di audit di smart contract e infrastrutture wallet in Soken, l’integrità dell’autorizzazione va oltre la protezione delle chiavi private. Un sistema può conservare le proprie chiavi e perdere comunque il controllo dei fondi quando dati di backend compromessi vengono trattati come una descrizione autorevole di ciò che un firmatario sta approvando.”
L’incidente di Bitget ha mostrato anche tracce di attività anti-forense. L’attaccante ha cancellato le tracce dei comandi iniettati, aspetto che Gracy Chen ha definito la parte più insidiosa dell’operazione. Questo comportamento fa emergere un requisito specifico per la risposta agli incidenti: gli exchange devono conservare registri indipendenti e resistenti alle manomissioni di creazione, approvazione, firma e trasmissione dei comandi.
Un’architettura sicura non dovrebbe affidarsi a un unico sistema interno sia per costruire una richiesta di prelievo sia per descriverla a chi la approva. La ricostruzione indipendente delle transazioni, i controlli di policy fuori banda, i log di audit immutabili e una rigorosa separazione tra strumenti di sicurezza e operatività dei wallet possono rendere più facile individuare istruzioni falsificate.
Che cosa è successo nella cronologia dell’exploit di Bitget?
L’exploit di Bitget è passato da piccoli trasferimenti di prova a uno svuotamento multi-chain prima che la riconciliazione automatica rilevasse una discrepanza. I primi trasferimenti non autorizzati sono comparsi alle 18:31 UTC del 24 settembre 2026. Lo svuotamento principale si è poi svolto dalle 18:58 alle 20:09 UTC in 17 transazioni su 8 chain, mentre l’ultimo trasferimento dell’attaccante è stato osservato alle 21:23 UTC.
| Ora o data | Evento dell’incidente Bitget | Rilevanza per la sicurezza |
|---|---|---|
| 18:31 UTC, 24 settembre | Rilevati i primi trasferimenti non autorizzati da hot wallet e warm wallet | Due trasferimenti di prova, 0,184 ETH e 193 TRX, sono rimasti sotto le soglie di rischio |
| Dalle 18:58 alle 20:09 UTC, 24 settembre | Lo svuotamento principale si è svolto in 17 transazioni su 8 chain | Circa 361 milioni di dollari spostati durante la sequenza principale |
| 19:05 UTC, 24 settembre | Il sistema di riconciliazione ha rilevato una discrepanza | I prelievi sono stati bloccati sull’intera piattaforma |
| 20:40 UTC, 24 settembre | Bitget ha iniziato a spostare i fondi rimanenti nel cold storage | L’esposizione residua dei wallet è stata ridotta |
| 21:23 UTC, 24 settembre | Ultimo trasferimento dell’attaccante osservato on-chain | L’ultimo trasferimento è avvenuto 2 ore e 52 minuti dopo il primo test |
| 21:44 UTC, 24 settembre | I servizi wallet e la firma sono stati disattivati | Le operazioni di firma sono state interrotte |
| 25 settembre, 08:43 UTC | Bitget ha individuato la causa principale | L’indagine è passata dal contenimento alla remediation |
| 25 settembre, 13:42 UTC | Le forze dell’ordine sono state informate | È iniziata l’escalation esterna dell’incidente |
| 28 settembre, 08:00 UTC | Sono ripresi i prelievi in BTC | È iniziata la riapertura graduale |
| 29 settembre, 08:00 UTC | Era prevista la ripresa dei prelievi in ETH | La fase successiva seguiva la riapertura dei prelievi in BTC |
| 30 settembre, 08:00 UTC | Erano previsti i prelievi in USDT | L’esecuzione delle fasi successive non risultava confermata nelle informazioni disponibili |
| 2 ottobre, 08:00 UTC | Erano previsti altri token, valute fiat e P2P | Il piano di riapertura copriva servizi aggiuntivi |
I due trasferimenti iniziali erano stati concepiti per passare sotto le soglie esistenti. Gli importi di prova, 0,184 ETH e 193 TRX, non hanno fatto scattare alcun allarme. Questo dimostra perché un monitoraggio basato soltanto sulle soglie è debole contro gli attacchi a più fasi. Un attore malevolo può prima verificare che un percorso di autorizzazione funzioni e poi aumentare l’importo delle transazioni una volta che il sistema appare stabile.
La cronologia di Bitget e l’indagine on-chain divergono leggermente sui confini precisi dello svuotamento principale. La CEO di Bitget ha descritto la sequenza centrale come compresa tra le 18:58 e le 20:09 UTC, mentre i dati on-chain hanno mostrato raffiche intorno alle 19:01 e alle 19:16 UTC. Questi dettagli non cambiano la conclusione centrale: l’attaccante ha avuto a disposizione un percorso di prelievo funzionante per meno di tre ore prima che venisse osservato l’ultimo trasferimento.
Nella prima ora dopo la riapertura dei prelievi in BTC sono stati elaborati più di 3.000 BTC, secondo la CEO di Bitget. Questo dettaglio operativo è importante perché riaprire un exchange dopo un incidente ai wallet crea un secondo problema di controllo. La piattaforma deve ripristinare l’accesso dei clienti senza reintrodurre il percorso di approvazione compromesso e senza permettere che un’ondata di prelievi legittimi nasconda ulteriori attività non autorizzate.
Una riapertura graduale è quindi più di un calendario pensato per l’assistenza clienti. È una strategia di contenimento che consente il monitoraggio per singolo asset, la riconciliazione dei wallet, la rotazione delle credenziali e la validazione progressiva dei controlli sui prelievi.
Quali asset sono stati colpiti e come si è arrivati alla perdita di 387,5 milioni di dollari?
La stima finale della perdita di Bitget è stata di circa 387,5 milioni di dollari su 13 asset e 11 reti, anche se i tracker indipendenti hanno contato tra 7 e 11 reti coinvolte. XRP ha rappresentato la maggiore esposizione su un singolo asset, con circa 102,98 milioni di XRP per un valore di circa 157,8 milioni di dollari, mentre ETH ha pesato per circa 126,6 milioni di dollari nella ripartizione on-chain.
Le comunicazioni pubbliche e le indagini on-chain 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 | Maggiore esposizione su un singolo asset |
| ETH | Circa 126,6 milioni di dollari | Parte dello svuotamento multi-chain |
| USDT0 su Arbitrum | Circa 19,7 milioni di dollari | Esposizione in stablecoin su Arbitrum |
| AVAX | Circa 16,8 milioni di dollari | Incluso nella ripartizione degli asset tracciati |
| BNB | Circa 9,9 milioni di dollari | Incluso nella ripartizione degli asset tracciati |
| TRX | Circa 7,0 milioni di dollari | Cifra confermata da più tracker |
| Perdita totale di Bitget | Circa 387,5 milioni di dollari | Rivista dopo il tracciamento dei trasferimenti su Zcash e TRON |
L’insieme degli asset sottratti comprendeva XRP, ETH, USDT, ZEC, ATOM, USDC, BNB, AVAX, TRX, ALGO, TIA e XAUt. La prima stima pubblica di Bitget, il 24 settembre, era di 351,6 milioni di dollari. La stima è aumentata dopo l’individuazione di ulteriori trasferimenti su Zcash e TRON.
XRP ha posto una difficoltà specifica per il recupero, perché XRP non può essere congelato dal suo emittente. Al 26 settembre circa 83 milioni di dollari degli XRP sottratti avevano lasciato i wallet di appoggio dell’attaccante. Una volta che gli asset escono da un indirizzo di appoggio ed entrano in percorsi di conversione o cross-chain, gli investigatori devono seguire sia i fondi sia i servizi che li elaborano.
Lo schema di riciclaggio si è basato sulla rapida conversione delle stablecoin in ETH, seguita da swap in BTC. Gli investigatori hanno individuato THORChain come canale principale verso BTC, mentre nel percorso di riciclaggio compaiono anche Chainflip, deBridge, SwapKit e Wasabi CoinJoin. Il 28 settembre un wallet collegato all’hacker ha scambiato circa 2.390 ETH, per un valore di circa 6,3 milioni di dollari, con 75,2 BTC tramite THORChain, in tranche da circa 100 ETH.
La risposta ha messo in luce una tensione, sul piano delle policy, tra infrastruttura decentralizzata e contenimento degli incidenti. THORChain ha respinto la richiesta di Bitget di bloccare l’hacker, affermando che “Una sospensione non è un congelamento selettivo di fondi specifici.” Chen ha replicato che “La decentralizzazione è un principio di progettazione, non uno scudo per agevolare il transito di fondi notoriamente rubati.”
Questo scambio mostra perché il coordinamento prima dell’incidente è importante. I protocolli decentralizzati potrebbero non disporre di una capacità universale di identificare o congelare un singolo trasferimento senza incidere su un percorso più ampio. Exchange centralizzati, emittenti di stablecoin, operatori di bridge e sistemi basati su intent applicano ciascuno regole di intervento diverse. Un exchange che aspetta il dopo-exploit per capire queste regole ha meno opzioni nelle prime ore del riciclaggio.
Che cosa rivela l’hack di Bitget sul rischio legato a terze parti e al livello di approvazione?
L’hack di Bitget rivela che la sicurezza di un exchange dipende dal software di terze parti, dalle credenziali interne, dalla presentazione delle transazioni e dalle policy di rischio tanto quanto dalla custodia crittografica delle chiavi. Bitget, Bybit, DMM Bitcoin e WazirX mostrano uno schema ricorrente: gli attaccanti hanno compromesso un fornitore o un livello di approvazione considerato affidabile, così che una transazione malevola apparisse legittima al processo di firma o di autorizzazione.
| Incidente | Data | Livello compromesso | Perdita o portata dichiarata | 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 hanno aggirato i controlli di rischio |
| Bybit | 21 febbraio 2025 | Macchina di uno sviluppatore di Safe{Wallet} e interfaccia di firma | Circa 1,46 miliardi di dollari | Codice malevolo ha alterato l’ambiente di approvazione delle transazioni |
| DMM Bitcoin | Maggio 2024 | Dipendente del fornitore del software wallet e flusso di firma | Da circa 305 milioni a 308 milioni di dollari | La compromissione di un fornitore ha consentito attività non autorizzate sui wallet |
| WazirX | 18 luglio 2024 | Contratto del wallet multisig e flusso di custodia | Circa 235 milioni di dollari | I firmatari hanno approvato transazioni dopo l’alterazione del contratto |
| Coinbase | Reso noto a maggio 2025 | Addetti all’assistenza all’estero e dati dei clienti | Stima dei costi di remediation da 180 milioni a 400 milioni di dollari | La compromissione dei dati dei clienti può creare una forte esposizione operativa senza furto di chiavi |
Il punto debole comune non è la violazione della crittografia. È la perdita di un contesto affidabile attorno alla transazione. Un firmatario può vedere una richiesta valida, un formato di destinazione familiare e un flusso di approvazione dall’aspetto normale, mentre l’istruzione sottostante è stata sostituita o manipolata.
Per gli exchange questo richiede controlli in più punti indipendenti:
- Isolamento dei fornitori: i prodotti di sicurezza di terze parti non dovrebbero avere accessi non necessari alla generazione dei comandi dei wallet o a credenziali privilegiate.
- Compartimentazione delle credenziali: le credenziali interne dovrebbero essere limitate a singole funzioni, ruotate dopo attività sospette e, per impostazione predefinita, non in grado di autorizzare ampi prelievi multi-chain.
- Ricostruzione indipendente delle transazioni: l’interfaccia di approvazione dovrebbe ricavare i dettagli della transazione da una fonte indipendente, anziché fidarsi dello stesso backend che ha creato la richiesta.
- Diversità delle policy: i prelievi di importo elevato dovrebbero passare attraverso regole gestite separatamente dal backend operativo dei wallet.
- Log immutabili: i log dovrebbero essere conservati al di fuori dell’ambiente compromesso e includere gli eventi di creazione, modifica, approvazione, firma e trasmissione dei comandi.
- Trasferimenti canary: i piccoli trasferimenti di prova non dovrebbero essere considerati sicuri solo perché restano sotto una soglia monetaria. Test ripetuti, destinazioni insolite e schemi cross-chain richiedono un’analisi di correlazione.
- Arresto di emergenza: l’exchange deve poter fermare la firma e isolare i servizi wallet senza mettere offline i sistemi di trading e di deposito non coinvolti.
Bitget ha dichiarato di aver isolato i server interessati, revocato e riemesso le credenziali interne e ristrutturato l’accesso ai sistemi sensibili. L’exchange ha inoltre affermato che la vulnerabilità è stata corretta. Queste misure riguardano il contenimento, ma una revisione solida deve verificare se gli stessi dati delle transazioni possano ancora essere manipolati prima dell’approvazione.
I servizi di audit di smart contract e di sicurezza blockchain di Soken sono pertinenti a questo perimetro di controllo, perché l’infrastruttura wallet combina spesso smart contract, servizi di firma, API di backend, sistemi di gestione delle chiavi e strumenti di terze parti. Una valutazione limitata al codice Solidity non verificherebbe se un servizio compromesso possa alterare i dati che un firmatario vede.
Quanto sono state efficaci le misure di recupero e le ipotesi di attribuzione?
Al 29 settembre 2026 le misure di recupero avevano prodotto restituzioni confermate limitate, mentre l’attribuzione restava probabilistica e non ufficiale. Circle e Tether hanno congelato in totale circa 339.100 dollari, e NEAR Intents ha dichiarato che il proprio screening ha respinto tentati trasferimenti collegati a Bitget per oltre 50 milioni di dollari e ha congelato 503.000 dollari. Non era stato confermato alcun recupero di fondi sottratti a favore di Bitget.
Le azioni di recupero segnalate sono state:
| Soggetto o meccanismo intervenuto | Azione segnalata | Importo |
|---|---|---|
| Circle e Tether | Congelamento di USDC e USDT | Circa 339.100 dollari in totale |
| Saldi in stablecoin | 239.113,50 USDT e 99.989,91 USDC congelati | Inclusi nel totale di 339.100 dollari |
| NEAR Intents | Respinti tentati trasferimenti collegati a Bitget | Oltre 50 milioni di dollari |
| NEAR Intents | Congelati tentati trasferimenti collegati a Bitget | 503.000 dollari |
| Bitget | Offerta una ricompensa per l’intervento e il recupero | 5% per il congelamento più 5% per il recupero |
La differenza tra flussi respinti e fondi recuperati è cruciale. Un sistema di screening può impedire agli asset di entrare in un determinato canale senza restituire i fondi già controllati dall’attaccante. Allo stesso modo, i congelamenti da parte degli emittenti riguardano determinati saldi in stablecoin, non XRP, ETH, BTC o asset che si muovono attraverso infrastrutture permissionless.
Anche l’attribuzione richiede una formulazione attenta. Le valutazioni delle società di analisi hanno descritto l’attacco come molto probabilmente collegato alla Corea del Nord e hanno individuato sovrapposizioni con wallet usati negli hack di Bybit e AFX Bridge. Un’altra valutazione ha descritto un gruppo simile a TraderTraitor, senza però attribuire in modo definitivo l’incidente di Bitget. Al 29 settembre 2026 nessuna agenzia governativa aveva attribuito formalmente l’attacco.
Il quadro più ampio è rilevante. Con Bitget incluso, i furti di criptovalute tracciati e collegati alla Corea del Nord nel 2026 hanno superato 1 miliardo di dollari in più di 50 incidenti. Una stima di settore ha collocato il totale a 1,04 miliardi di dollari, il che fa del 2026 il secondo anno per entità dopo il 2025, stimato a 1,68 miliardi di dollari.
La CEO di Bitget ha dichiarato che l’attaccante era molto probabilmente un gruppo nordcoreano. Questa affermazione è un segnale di rischio operativo, non un sostituto dell’attribuzione formale. I team di sicurezza dovrebbero usare le sovrapposizioni tra wallet e gli schemi di riciclaggio disponibili per orientare il rilevamento, preservando l’incertezza nelle dichiarazioni pubbliche e nei procedimenti legali.
Bitget ha inoltre dichiarato che il 100% dei fondi degli utenti era coperto dal Bitget Protection Fund, che deteneva 5.500 BTC, per un valore di circa 464 milioni di dollari in quel momento. L’exchange si è impegnato a ricostituire il fondo ad almeno 300 milioni di dollari entro una settimana attingendo a riserve aziendali superiori a 1,4 miliardi di dollari. Questi impegni riguardano la solvibilità verso i clienti, ma non eliminano la necessità di riparare l’architettura di approvazione che ha permesso ai comandi di prelievo di passare.
Dopo l’incidente il token BGB ha perso all’incirca tra il 3% e il 7%, toccando un minimo compreso tra circa 1,89 e 1,93 dollari prima di risalire a circa 1,97 dollari. La reazione del mercato ha quindi riflesso un rischio di fiducia oltre alla perdita diretta sui wallet.
La risposta di Bitget può essere seguita insieme a ricerche più ampie sugli incidenti attraverso l’hub di ricerca sulla sicurezza di Soken, mentre le organizzazioni che riesaminano la governance degli exchange possono avvalersi del supporto per audit tecnici e risposta agli incidenti per verificare i perimetri delle credenziali, l’integrità delle transazioni e i controlli di emergenza.
Che cosa dovrebbero cambiare gli exchange dopo l’exploit di Bitget?
Gli exchange dovrebbero trattare l’exploit di Bitget come una falla nell’integrità dell’autorizzazione e testare ogni sistema che crea, trasforma, visualizza, approva, firma o trasmette un prelievo. Proteggere cold wallet e chiavi private resta necessario, ma l’incidente di Bitget mostra che il rischio di hot wallet e warm wallet dipende anche da metadati delle transazioni affidabili e da percorsi di approvazione indipendenti.
Un programma post-incidente concreto dovrebbe procedere in quest’ordine:
- Ricostruire il percorso dei comandi. Mappare l’intero tragitto dalla richiesta di prelievo alla trasmissione, includendo prodotti di terze parti, account di servizio, code, API, sistemi di firma e riconciliazione.
- Revocare le credenziali in modo esteso. Bitget ha revocato e riemesso le credenziali interne. Gli altri exchange dovrebbero individuare permessi ereditati, account di servizio inattivi e credenziali condivise tra ambienti diversi.
- Separare la costruzione delle transazioni dalla loro approvazione. L’interfaccia di approvazione dovrebbe verificare in modo indipendente destinazione, asset, importo, chain, nonce e classificazione di policy.
- Conservare le prove fuori dalla produzione. Poiché l’attaccante ha cancellato le tracce dei comandi iniettati, i log di audit devono essere replicati in un ambiente che gli amministratori operativi non possano riscrivere.
- Ritestare le soglie di rischio. I trasferimenti di prova da 0,184 ETH e 193 TRX sono passati sotto le soglie. Il rilevamento dovrebbe combinare valore, novità della destinazione, tempistica, ripetizione, comportamento cross-chain e contesto delle credenziali.
- Provare la procedura di arresto. Bitget ha isolato i server, spostato i fondi rimanenti nel cold storage e disattivato la firma. Queste azioni dovrebbero essere provate prima di un incidente, non improvvisate mentre è in corso.
- Definire in anticipo l’escalation esterna. Emittenti di stablecoin, bridge, sistemi di intent, fornitori di analisi e forze dell’ordine dovrebbero essere inclusi nei playbook di gestione degli incidenti.
- Riaprire per fasi controllate. Una riapertura asset per asset consente al monitoraggio di validare ogni percorso dei wallet prima che riprendano prelievi più ampi.
Un obiettivo di controllo utile è semplice: nessun singolo backend compromesso dovrebbe essere in grado di creare una richiesta di prelievo, descriverla a chi la approva, soddisfare il motore di rischio e attivare la firma. Questo obiettivo vale sia che l’exchange utilizzi wallet multifirma, moduli di sicurezza hardware, vault basati su smart contract o infrastrutture di custodia di terze parti.
L’incidente di Bitget avvalora anche una distinzione più ampia tra sicurezza della custodia e sicurezza dell’autorizzazione. La sicurezza della custodia si chiede se un attaccante possa ottenere le chiavi. La sicurezza dell’autorizzazione si chiede se il sistema possa essere indotto ad approvare la transazione sbagliata usando chiavi legittime. Gli exchange che misurano solo la prima categoria possono riferire che le chiavi private restano al sicuro mentre perdono il controllo dei fondi che quelle chiavi autorizzano.
Il calendario di riapertura di Bitget, gli impegni sul Protection Fund e la remediation delle credenziali riguardano la continuità operativa e la tutela dei clienti. La prossima domanda tecnica è se l’exchange sia in grado di dimostrare che i dati delle transazioni mostrati a chi approva vengono ora generati e verificati in modo indipendente dal backend compromesso. Queste evidenze dovrebbero far parte di qualsiasi report pubblico post-incidente.
La perdita di Bitget, lo svuotamento multi-chain in 17 transazioni e il limitato recupero confermato indicano tutti la stessa lacuna di controllo: il software considerato affidabile e il contesto delle transazioni considerato affidabile devono essere trattati come superfici d’attacco. Il passo concreto successivo per chi gestisce un exchange è tracciare un prelievo dall’inizio alla fine e poi tentare di alterarne i dati di transazione visualizzati senza modificare la richiesta di firma finale. Se i livelli di monitoraggio e di approvazione non rilevano questa discordanza, l’architettura dei wallet resta esposta.
Soken può supportare questo lavoro con valutazioni di sicurezza per exchange e penetration test, concentrando la revisione sul percorso di autorizzazione che collega gli strumenti di terze parti all’operatività di hot wallet e warm wallet.