Il furto da 285 milioni a Drift: cosa insegna al vCISO sulla gestione del rischio umano e tecnologico
Negli ultimi anni il mondo delle criptovalute e della DeFi è diventato un laboratorio di incidenti di sicurezza ad alto impatto, ma il caso di Drift è diverso. Nel primo aprile 2026, il protocollo di futures su Solana ha subito un accesso non autorizzato che ha portato alla sottrazione di circa 280–285 milioni di dollari in asset digitali. A prima vista, sembra “solo” un altro exploit di DeFi; in realtà, è un caso di governo del rischio fallito: un mix tra social engineering, complessità architetturale e mancanza di controlli procedurali sugli accessi privilegiati.
Contesto: cos’è Drift e perché il caso è rilevante
Drift è un decentralized exchange (DEX) specializzato in futures e leveraged trading su Solana, con una liquidità significativa e un’architettura fortemente automatizzata. In ambito vCISO, questo lo rende un esempio paradigmatico: un sistema complesso, con livelli diversi di trust, governance distribuita e componenti critici on‑chain (multisig, vault, oracoli) che interagiscono con un ambiente umano‑sociale (team, partner, sviluppatori, ecosistemi).
Il motivo per cui il caso Drift è interessante per un vCISO non è solo l’ammontare del danno, ma come il rischio è stato accumulato: attraverso fiducia, relazioni, accessi e processi apparentemente “normali”, prima che qualsiasi exploit tecnico saltasse all’occhio.
Cosa è successo dal punto di vista tecnico
L’attacco del 1° aprile 2026 non è partito da un bug di smart contract “classico”, ma da un compromettere le chiavi amministrative di un multisig critico associato a un vault spot. L’attore malevolo ha manipolato il prezzo di un token fittizio (CVT) tramite oracolo, ha usato meccanismi di cross‑margin e swap legittimi del protocollo e ha sottratto in pochi secondi asset reali come SOL, ETH, BTC, USDC e altri token di ecosistema Solana.
In termini vCISO, stiamo parlando di:
- Controllo di accesso privilegiato male gestito: una chiave multisig insufficientemente protetta diventa un single point of failure.
- Assenza di safeguard procedurali: nessun timelock, nessun circuit‑breaker, nessun controllo di governance umana prima dell’esecuzione di operazioni critiche.
- Architettura complessa usata male: un progetto DeFi ben progettato può diventare un vettore di perdita se il rischio operativo non è stato valutato.
Il ruolo del social engineering: il fattore umano
Analisi di cybersecurity e ricostruzioni della comunità indicano che il set di accessi compromessi è stato preparato tra fine 2025 e inizio 2026, durante conferenze internazionali e attività di networking. L’attore malevolo ha creato un progetto “facciata” nel medesimo ecosistema, depositando anche liquidità (oltre un milione di dollari) per apparire credibile come partner tecnico.
Durante i mesi successivi ha condiviso con il team sviluppatori link a strumenti, SDK e progetti in beta, arrivando all’installazione di un wallet beta tramite canali ufficiali come Apple TestFlight su dispositivi specifici. Da lì, l’accesso alle chiavi amministrative è stato ottenuto, e il drenaggio di 285 milioni è avvenuto in pochi secondi.
Cosa insegna il caso Drift a un vCISO
1. La vera “single point of failure” è il perimetro umano
Il caso Drift dimostra che il collo di bottiglia della sicurezza non è solo il codice, ma il processo di interazione con partner, sviluppatori e soluzioni terze. In ambito enterprise, il corrispettivo è:
- Vendor e partner con accessi privilegiati.
- sviluppatori con accesso a ambienti produttivi.
- strumenti di sviluppo e beta‑software usati in contesto operativo.
Il vCISO deve trattare questi elementi come asset critici e applicare a essi:
- Least privilege
- MFA e controlli di accesso forti anche su chiavi e wallet.
- Audit periodici sugli accessi e sui privilegi.
2. Supply chain e “human‑chain” devono essere gestiti insieme
Il social engineering in ambito Drift è un esempio di supply‑chain‑human‑chain attack: il vettore è entrato tramite:
- Conferenze e eventi.
- Collaborazioni tra progetti.
- Strumenti di sviluppo e beta app condivise.
Dal punto di vista vCISO, questo richiede:
- Framework di onboarding dei fornitori che includano anche aspetti di security awareness e controlli di accesso.
- Policy chiare su strumenti di sviluppo, beta software e dispositivi personali.
- Formazione mirata sui rischi di condivisione di credenziali, link cliccati e installazione di tool non approvati.
In un’azienda tradizionale, il rischio equivalente è l’installazione di SDK malevoli, plugin sospetti o strumenti di terze parti che portano accessi privilegiati.
3. Governance, timelock e controlli umani
Il dramma di Drift è che, una volta che l’accesso è stato ottenuto, il protocollo ha fatto esattamente quello che è stato progettato a fare: ha eseguito la transazione. Manca, però, un circuit‑breaker:
- Nessun timelock sulle operazioni critiche.
- Nessun livello di governance manuale che avrebbe potuto bloccare o rallentare l’operazione.
- Nessuna separazione sufficiente tra “chi può firmare” e “chi può decidere”.
Un vCISO dovrebbe chiedersi:
- Chi può decidere operazioni critiche e chi può semplicemente eseguirle?
- Quale processo di approvazione è richiesto per operazioni che muovono liquidità o asset critici?
- Esistono limiti temporali o di volumi per prevenire perdite massicce rapide?
Azioni operative per un vCISO (anche fuori dal mondo crypto)
Anche se non lavori direttamente nel mondo DeFi, il caso Drift offre spunti concreti da portare in azienda:
1. Mappare e controllare i punti critici
- Identificare tutti i punti di accesso privilegiato: chiavi, password, MFA, token, wallet, account di amministrazione.
- Definire chiavi critiche e strategie di protezione (rotazione, backup sicuro, uso di HSM o custodie esterne).
- Estendere la mappatura anche ai partner e fornitori che interagiscono con il sistema.
2. Applicare controlli procedurali robusti
- Introdurre timelock o meccanismi di approvazione per operazioni sensibili.
- Implementare controlli di auditing e monitoraggio in tempo reale delle attività: un’operazione anomala deve essere rilevata e bloccata.
- Pianificare procedure di incident response specifiche per la perdita di asset o accesso a chiavi critiche.
3. Sensibilizzare il team e il board
- Utilizzare casi come Drift come esempi didattici per sensibilizzare su:
- Rischi di social engineering.
- Importanza della governance e della sicurezza dei processi.
- Presentare al board scenari di perdita massiccia di asset e rischio reputazionale per rendere concreto il rischio.
Conclusione: verso una governance più matura del rischio
Il caso Drift è un campanello d’allarme per chi adotta architetture distribuite, automatizzate o decentralizzate, ma il suo valore reale è trasversale: dimostra che, anche in contesti altamente tecnologici, la vera linea di demarcazione è il governo del rischio. Un vCISO moderno deve:
- Mappare tutti i punti critici di accesso e di controllo.
- Filtrare la trusted base (team, partner, sviluppatori) con policy e controlli rigorosi.
- Introdurre meccanismi di timelock, approvazione e monitoring che trasformino “what can be done” in “what should be done”.
Fonti ufficiali e materiali di riferimento
Per documentare in modo rigoroso il caso Drift, puoi citare queste fonti (più orientate a comunicati ufficiali e analisi di sicurezza):
Comunicato ufficiale di Drift:
Link: https://cryptonews.net/news/security/32658115/
Drift Protocol ha pubblicato i risultati della propria investigazione sul furto da 285 milioni, descrivendolo come un’operazione di infiltrazione coordinata di circa sei mesi, con attacco tramite chiave amministrativa compromessa e non tramite vulnerabilità di smart contract.
Esposizione tecnica e analisi di Binance:
Link: https://www.binance.com/en/square/post/308374517714433
Binance ha riassunto l’evento evidenziando che l’incidente non è causato da bug di programma, ma da un attore che ha ottenuto “approvazioni di transazione travestite” e ha sfruttato il meccanismo del nonce e complesse operazioni di manipolazione.
Report di TRM Labs
TRM Labs, società di blockchain‑intelligence, ha analizzato l’attacco come il più grande DeFi hack del 2026, attribuibile a un gruppo hacker legato alla Corea del Nord, con preparazione di tre settimane prima dell’esecuzione.
Comunicazioni di Solana Foundation
Link: https://crypto.news/drift-protocols-285m-hack-exposes-social-engineering-threat-to-solana-defi/
Il CEO e il CPO di Solana hanno confermato tramite canali ufficiali che il vettore è stato il social engineering e il fallimento di security operativa, non una vulnerabilità nel codice di base.
Aggregazioni di sicurezza on‑chain e portali di notizie
Piattaforme come DefiLlama, analytics di sicurezza on‑chain e portali crypto‑news hanno documentato l’ammontare del danno, le tracce di money‑laundering e l’impatto sul TVL del protocollo, rendendo il caso facilmente verificabile.
CISO vs vCISO: Guida Strategica alla Governance della Cyber Security
