Come un programma segreto di spionaggio della Corea del Nord, durato sei mesi, costringe la comunità crypto a ripensare la sicurezza

Quando Drift ha reso pubblici i dettagli dell’attacco che ha portato alla perdita di circa 270 milioni di dollari, la parte più inquietante non è stata tanto la dimensione economica del furto, quanto il modo in cui è stato eseguito.

Secondo il team del protocollo, non si è trattato di un difetto nei smart contract né di una semplice manipolazione di codice: è stata una campagna di sei mesi che ha coinvolto identità fasulle, incontri in persona in diversi Paesi e la costruzione deliberata di fiducia. Gli aggressori — indicati come operativi della Corea del Nord — non si sono limitati a trovare una falla nel sistema: si sono inseriti al suo interno.

Un’operazione di intelligence più che un “hack”

Alexander Urbelis ha detto:

“Dobbiamo smettere di chiamarli ‘hack’ e cominciare a chiamarli per quello che sono: operazioni di intelligence. Persone che si presentano a conferenze, che incontrano contributori di Drift in persona in più Paesi, che depositano milioni per costruire credibilità: quella è tradecraft, il lavoro di un case officer, non l’azione di un semplice hacker.”

Se questa lettura è corretta, l’incidente di Drift segna l’emergere di un nuovo playbook: attaccanti che agiscono come operatori pazienti, inserendosi socialmente nel tessuto di progetto prima di compiere il colpo sulla catena.

Tattiche evolute e precedenti

Le tattiche non sono del tutto inedite. Indagini precedenti avevano già messo in luce come operatori statali si siano infiltrati in società crypto presentandosi come sviluppatori, superando colloqui e ottenendo posizioni con identità false. Tuttavia, il caso Drift indica un’escalation: dall’accesso tramite canali di assunzione a operazioni di relazione dal vivo durate mesi, finalizzate all’attacco.

Questo cambiamento preoccupa molti responsabili della sicurezza: anche un protocollo sottoposto ai più severi audit può fallire se un contributore chiave viene compromesso.

La vulnerabilità umana come tallone d’Achille

David Schwed ha detto:

“I protocolli devono capire cosa hanno davanti. Non sono semplici exploit: sono operazioni pianificate, della durata di mesi, con risorse dedicate, identità fabbricate e un elemento umano deliberato. Quel fattore umano è il tallone d’Achille per molte organizzazioni.”

Molti team di DeFi restano piccoli, rapidi e basati sulla fiducia: quando poche persone detengono accessi critici, comprometterne una può essere sufficiente a compromettere l’intero progetto. Secondo Schwed, la risposta richiede un aggiornamento sostanziale delle pratiche di difesa: programmi di sicurezza che proteggano non solo la tecnologia, ma anche le persone e i processi.

Adattamenti operativi nelle piattaforme

Alcuni protocolli stanno già modificando le loro contromisure. Su Jupiter, una delle maggiori piattaforme DeFi sull’ecosistema Solana, gli audit e la verifica formale rimangono fondamentali, ma non più sufficienti da soli.

Kash Dhanda ha detto:

“Chiaramente, assicurare il codice con audit indipendenti, open source e verifica formale è il punto di partenza. La superficie di attacco si è però notevolmente ampliata.”

Per questo motivo Jupiter ha rafforzato l’uso di multisig e timelock, investendo inoltre in sistemi di rilevamento e nella formazione interna. Come osserva Dhanda, la componente umana è spesso più vulnerabile del codice e richiede aggiornamenti continui alle pratiche di opsec.

Anche per protocolli come dYdX l’episodio conferma una realtà difficile da eliminare con l’ingegneria: progetti crypto sono sempre più mirati da attori statali e sofisticati.

David Gogel ha detto:

“È un fatto spiacevole che i progetti crypto siano sempre più presi di mira da attori statali. Gli sviluppatori devono adottare precauzioni per prevenire e mitigare compromissioni da social engineering, ma anche gli utenti devono essere consapevoli che con l’aumentare della sofisticazione il rischio non può essere azzerato.”

Gogel sottolinea come la responsabilità si stia in parte spostando sugli utenti: chi partecipa attivamente alla DeFi dovrebbe comprendere l’architettura tecnica dei protocolli che custodiscono i propri fondi e valutare i rischi legati a eventuali multisig o altri meccanismi di governance che potrebbero essere compromessi.

Modellare la minaccia e partire dalla resilienza

Per alcuni founder l’attacco a Drift porta a una conclusione scomoda: la fiducia stessa è diventata una vulnerabilità.

Lucas Bruder ha detto:

“L’exploit di Drift non era una vulnerabilità del codice. È stata un’operazione di intelligence di sei mesi che ha sfruttato la fiducia tra le persone.”

In termini pratici, questo significa progettare sistemi che presumano la possibilità di compromessi non solo tecnici ma anche umani. Gli audit dei smart contract restano imprescindibili, ma la vera superficie d’attacco include il team, i firmatari delle multisig e ogni dispositivo collegato alle loro attività quotidiane.

Per avviare questo cambiamento culturale è fondamentale partire da un modello di minaccia: chiedersi non soltanto come funziona un protocollo, ma come potrebbe fallire. Qual è il raggio d’azione se uno degli owner del progetto viene compromesso? Quali sono le contromisure per limitare danni e tempo di reazione?

Conclusioni e prospettive

L’esperienza di Drift potrebbe essere ricordata meno per i fondi sottratti che per la lezione strategica che ha impartito: i rischi maggiori nella DeFi potrebbero non risiedere più nel codice, ma nelle persone che la governano. Questo mutamento richiederà investimenti continui in sicurezza operativa, governance resilienti, formazione e una maggiore consapevolezza da parte degli utenti.