Un colloquio in video. Una persona che si presenta come responsabile delle risorse umane. Un secondo incontro con il presunto amministratore delegato. E poi una richiesta apparentemente normale per chi sviluppa software: scaricare un piccolo progetto e svolgere una prova tecnica.
Nel settembre 2026, secondo la ricostruzione pubblicata da Binance, dietro quella selezione non c’era un’opportunità professionale. C’era un’operazione di intrusione. Il codice consegnato al candidato conteneva componenti malevoli e fu eseguito sul suo computer di lavoro. Più di un mese dopo, al termine di una sequenza di compromissioni e accessi illeciti, dalla piattaforma furono trasferiti asset digitali per un valore iniziale stimato di circa 6,34 miliardi di dollari.
La cifra colpisce, ma non racconta tutto. La falsa selezione fu uno degli elementi di una campagna più ampia, iniziata mesi prima e proseguita attraverso dispositivi, credenziali, strumenti interni e servizi di firma. Per comprenderla bisogna resistere alla tentazione di cercare un unico colpevole tecnico o un unico clic fatale. Il caso mostra soprattutto come una catena di fiducia possa essere attraversata, un collegamento alla volta.
Questa ricostruzione distingue i fatti descritti dalla stessa Binance, le attribuzioni delle autorità statunitensi e le domande che restano aperte. I dettagli pubblicati sono preliminari: la società ha dichiarato che l’indagine continua e che alcune informazioni tecniche non vengono diffuse.
Una cronologia che comincia prima del colloquio
Nel rapporto iniziale del 3 novembre, Binance colloca una prima fase nel giugno 2026. Un tecnico del gruppo che si occupava dell’infrastruttura dei wallet, indicato qui come ingegnere A, cercò online uno strumento per installare un’applicazione di assistenza alla programmazione basata sull’intelligenza artificiale. Scaricò una versione alterata di un programma di installazione associato all’ecosistema Homebrew.
La società afferma che il proprio gruppo di sicurezza rilevò l’anomalia, sostituì il dispositivo e cambiò le credenziali collegate. Un intervento concreto, dunque, ci fu. Secondo l’indagine successiva, tuttavia, gli aggressori avevano già acquisito informazioni sul ruolo dell’ingegnere e su altri colleghi dell’area wallet. L’episodio mostra una distinzione importante: bonificare una macchina non annulla necessariamente le informazioni già osservate da chi vi è entrato.
Nel settembre successivo un altro sviluppatore, che Binance identifica come ingegnere B, fu contattato su una piattaforma legittima per la ricerca di lavoro. Il suo profilo riportava l’esperienza presso Binance. La persona che lo avvicinò si presentò come responsabile di progetto e organizzò una prima videochiamata con un presunto selezionatore. Seguì un secondo incontro con qualcuno che sosteneva di dirigere una società che, secondo l’indagine, era fittizia.
Verso la fine di quel percorso fu chiesto al candidato di scaricare un repository, cioè una raccolta organizzata di file di progetto, e utilizzarlo per un esercizio. Stando a Binance, durante la preparazione dell’ambiente si attivò codice malevolo. Il computer interessato era quello di lavoro. La distinzione conta perché una workstation aziendale può contenere sessioni attive, strumenti interni, configurazioni e accessi che non sarebbero presenti su una macchina isolata.
Il 20 ottobre, secondo il rapporto, l’intruso usò il computer dell’ingegnere B e uno strumento interno di intelligenza artificiale per ottenere il controllo di altre due postazioni: quella dell’ingegnere A e quella di un ulteriore sviluppatore, indicato come C. Binance riferisce che sul computer di A fu individuato un token con permessi di distribuzione di container. Il 29 ottobre l’attaccante utilizzò il computer di C e credenziali sottratte ad A per distribuire un container e avviare uno script malevolo.
Questa è la sequenza dichiarata dall’azienda, non una ricostruzione forense completa verificabile in ogni dettaglio dall’esterno. Le fonti pubbliche non spiegano tutti i passaggi relativi allo strumento IA interno, né consentono di determinare autonomamente ogni causa tecnica. È importante non trasformare i vuoti dell’indagine in un racconto inventato.
La sera dei trasferimenti
Il 29 ottobre, secondo Binance, l’accesso non autorizzato a un servizio interno di firma dei wallet fu utilizzato per avviare transazioni al di fuori del normale processo di prelievo. Tra le 20:05 e le 20:09 UTC, cinque hot wallet inviarono complessivamente 233,46 milioni di XRP a un indirizzo controllato dall’attaccante. L’azienda descrive inoltre trasferimenti su altre reti e segnala che il proprio sistema generò un allarme per movimenti di grande volume.
Un hot wallet è un portafoglio digitale connesso a sistemi online, utilizzato per operazioni che devono essere eseguite con relativa rapidità. Non equivale a un conto corrente nel senso bancario tradizionale: è un insieme di indirizzi e meccanismi di autorizzazione su reti blockchain. La sua esposizione operativa rende particolarmente rilevanti le regole che disciplinano la firma, i limiti, il monitoraggio e la risposta alle anomalie.
Binance riferisce di aver sospeso i prelievi, collaborato con partner per congelare alcuni token e intrapreso azioni per revocare autorizzazioni non consentite. Secondo la sua cronologia, l’ultimo trasferimento non autorizzato fu finalizzato sulla blockchain alle 23:56 UTC; era stato già trasmesso e rimase in attesa prima della finalizzazione. La distinzione fra momento di invio e conferma sulla rete è essenziale: non tutte le azioni registrate su una blockchain diventano definitive nello stesso istante in cui vengono richieste.
La società indica che alle 00:10 UTC del 30 ottobre fu eseguita una nuova autorizzazione per eliminare una delega associata a un wallet Ethereum. Nella ricostruzione ufficiale, difficoltà nella revoca delle autorizzazioni contribuirono a prolungare il contenimento. Questo è uno dei punti più importanti dell’intero caso: interrompere una normale funzione di prelievo non equivale automaticamente a revocare tutte le autorizzazioni che un aggressore ha già ottenuto.
Che cosa significa EIP-7702
Per spiegare una parte dell’attacco occorre parlare di EIP-7702, una specifica della rete Ethereum relativa alla possibilità per un account di delegare l’esecuzione a codice di contratto intelligente. La definizione è tecnica, ma il concetto può essere espresso così: un account può autorizzare determinati comportamenti attraverso un meccanismo di delega, secondo le regole previste dal protocollo.
Binance afferma che l’intruso sfruttò il proprio accesso al servizio di firma per autorizzare un contratto controllato dall’attaccante a esercitare poteri di esecuzione parziali su un hot wallet. Nella spiegazione della società, questo non richiedeva di esporre la chiave privata. «Non risultano prove di una fuga della chiave» e «nessuno ha potuto autorizzare operazioni» sono però due affermazioni diverse: un servizio di firma o un’autorizzazione possono essere abusati anche senza che una chiave venga copiata e pubblicata.
Non significa che EIP-7702 sia di per sé malware, né che ogni applicazione che utilizza questa funzionalità sia compromessa. Il punto specifico è l’interazione tra capacità legittime del protocollo, autorizzazioni applicative e accesso illecito ai servizi aziendali. Un controllo efficace deve considerare le operazioni effettivamente possibili, comprese le deleghe e la loro revoca, invece di concentrarsi esclusivamente sul trasferimento tradizionale.
I numeri: sottratto, congelato, sequestrato, recuperato
Nel rapporto del 3 novembre Binance quantifica in circa 6,34 miliardi di dollari gli asset interessati. Alla stessa data parla di circa 2,85 miliardi congelati o intercettati, con valori soggetti a riconciliazione e alle oscillazioni di mercato. Il 12 novembre l’FBI ha comunicato che gli Stati Uniti avevano sequestrato o ottenuto autorizzazione giudiziaria a vincolare oltre 1,2 miliardi; secondo Associated Press questa cifra faceva parte dei più ampi importi congelati con partner pubblici e privati.
Questi valori non vanno sommati automaticamente. «Congelato», «intercettato», «sottoposto a sequestro» e «restituito definitivamente» descrivono stati diversi. Alcuni importi possono sovrapporsi; le procedure legali richiedono tempo; il valore in dollari di un token può cambiare. Il totale trasferito all’inizio dell’incidente non equivale necessariamente alla perdita finale accertata.
Binance ha dichiarato che sosterrà l’impatto economico senza addebitarlo agli utenti e ha descritto il reintegro delle disponibilità e la ripresa graduale dei prelievi. Il 14 novembre Reuters riferiva l’obiettivo dichiarato dalla società di riaprire i prelievi sulle reti e sugli asset rimanenti entro la fine della settimana successiva. Si tratta di un programma annunciato, non di un risultato già raggiunto; chi utilizza il servizio deve verificare lo stato aggiornato sui canali ufficiali.
Il falso colloquio: la fiducia costruita a puntate
La scena più facile da ricordare è quella della prova tecnica. Ma fermarsi lì significa perdere la parte che la precede. Secondo Binance, i contatti avvennero attraverso un sito legittimo di ricerca di lavoro, furono organizzati più incontri e una persona condivise un profilo social con foto e video. Tutti questi elementi potevano contribuire a rendere verosimile la selezione.
Una piattaforma autentica, tuttavia, non garantisce che ogni interlocutore sia autentico. Un profilo curato non dimostra da solo che la società esista, che l’interlocutore ne faccia parte o che il codice inviato sia sicuro. Gli aggressori possono investire tempo nel presentarsi come persone credibili e attendere il momento in cui la richiesta insolita sembri una normale tappa del processo.
Per uno sviluppatore, scaricare un progetto e installare dipendenze è un’attività ordinaria. Questo la rende una copertura efficace: comandi che avviano programmi, script di configurazione e librerie esterne possono far parte di una prova legittima. Il rischio emerge quando quel materiale viene eseguito su un ambiente che possiede accessi preziosi o contiene dati aziendali. Non serve che il candidato inserisca una password in una pagina falsa perché si creino conseguenze.
La responsabilità organizzativa non si esaurisce nel dire al dipendente di «fare più attenzione». Il problema coinvolge la separazione degli ambienti, la gestione dei privilegi, la capacità di rilevare comportamenti insoliti e la possibilità di chiedere aiuto senza timore. Una misura proporzionata può includere regole chiare sull’uso di dispositivi aziendali, ambienti isolati per materiale non attendibile e canali rapidi per segnalare richieste sospette.
Un repository non è soltanto testo
La parola repository può suggerire un archivio passivo, come una cartella da leggere. In un progetto software, invece, alcuni file possono descrivere operazioni da svolgere durante l’installazione, il caricamento o l’esecuzione. Le dipendenze possono portare altro codice; un comando apparentemente destinato a preparare l’ambiente può avviare attività ulteriori. Le possibilità esatte dipendono dal linguaggio, dagli strumenti e dai file coinvolti.
Nel caso Binance, la società descrive codice malevolo eseguito durante la fase di configurazione e tecniche destinate a eludere i controlli. Le informazioni disponibili non autorizzano a sostenere che ogni repository pubblico sia pericoloso o che il solo fatto di visualizzare un progetto equivalga alla sua esecuzione. Scaricare, aprire, installare, compilare e avviare sono azioni differenti, con rischi differenti.
Una difesa pratica parte dalla provenienza: verificare chi richiede l’esercizio, come è stato ottenuto il collegamento e quale ambiente è appropriato. Poi occorre capire quali comandi verranno eseguiti, quali risorse esterne saranno contattate e se il progetto richiede permessi coerenti con il suo scopo. Per le aziende, le scelte tecniche vanno adattate all’ambiente e supportate da procedure sostenibili: una protezione che impedisce ogni lavoro legittimo finirà spesso per essere aggirata.
Anche l’isolamento deve essere progettato con cura. Una macchina virtuale o un contenitore non diventano automaticamente una barriera perfetta se condividono credenziali, file sensibili o dispositivi con il sistema principale. Il principio è ridurre ciò che il codice non attendibile può vedere e fare, limitando anche la durata degli accessi e la possibilità di raggiungere infrastrutture interne.
Il ruolo dell’intelligenza artificiale: ciò che sappiamo
Nel resoconto Binance l’IA compare in due punti distinti. A giugno, l’ingegnere A cercava di installare uno strumento popolare di assistenza alla scrittura del codice quando scaricò il programma alterato. In ottobre, l’intruso avrebbe sfruttato uno strumento interno di IA per passare dal computer di B ad altre postazioni. Sono due fatti diversi nella cronologia e non andrebbero confusi.
La formulazione pubblica non chiarisce esattamente quale funzione dello strumento interno sia stata usata, quali permessi avesse e quale sequenza di operazioni abbia permesso il passaggio alle altre macchine. Non possiamo quindi concludere che un modello abbia autonomamente progettato il furto, che un particolare prodotto commerciale sia stato vulnerabile o che la causa sia stata una specifica tecnica di prompt injection. Sono ipotesi che richiederebbero prove ulteriori.
La domanda generale, invece, è concreta: quali dati, comandi e integrazioni può raggiungere un assistente inserito in un’organizzazione? Un sistema che riassume un documento ha una superficie di rischio diversa da un agente autorizzato a consultare repository, eseguire comandi o interagire con servizi interni. La sicurezza dipende dalle capacità effettivamente concesse e dai controlli che le circondano.
Per valutarle conviene partire da un inventario: identità usata dall’assistente, servizi collegati, azioni consentite, autorizzazioni ai dati, registrazioni disponibili e modalità di revoca. Le operazioni sensibili possono richiedere un passaggio di approvazione o un secondo controllo tecnico; gli accessi dovrebbero essere limitati al compito e alla durata necessari. Questi sono principi di progettazione, non la descrizione di un rimedio già verificato per ogni dettaglio dell’incidente Binance.
Token e container: quando un permesso diventa un passaggio
Un token è una credenziale digitale che un sistema può utilizzare per riconoscere e autorizzare una richiesta. A seconda di come è progettato, può consentire operazioni limitate oppure offrire un accesso molto ampio. Chi lo possiede può, entro i suoi limiti e fino alla scadenza o revoca, presentarsi a un servizio senza dover ripetere necessariamente l’intero processo di accesso umano.
Binance riferisce che sul computer dell’ingegnere A fu trovato un token con permessi per distribuire container. Un container è un modo per preparare ed eseguire software insieme a una parte del suo ambiente operativo. Nelle infrastrutture moderne è uno strumento comune e legittimo. La sua utilità, però, implica che i permessi di distribuzione debbano essere trattati con attenzione: se consentono di collocare software in un ambiente importante, diventano un obiettivo di grande valore.
Non conosciamo dalle fonti pubbliche tutti i controlli applicati a quel token, la sua durata o l’esatto perimetro tecnico. Possiamo però formulare le domande che un’organizzazione dovrebbe porsi: il permesso è legato a una persona o a una funzione? Scade automaticamente? È utilizzabile soltanto da dispositivi e ambienti attesi? La distribuzione richiede verifiche indipendenti? Gli eventi vengono registrati e correlati con altri segnali?
La revoca deve essere praticabile anche sotto pressione. Un piano teorico che richiede di individuare manualmente decine di credenziali durante un incidente potrebbe rivelarsi troppo lento. Prove periodiche possono verificare quali sistemi continuino a funzionare dopo una revoca, chi abbia l’autorità di intervenire e quali dipendenze organizzative rallentino il contenimento.
Dal rilevamento alla risposta: i minuti che contano
Quando un sistema segnala un trasferimento anomalo, l’allarme è soltanto l’inizio. Qualcuno deve identificare l’evento, distinguere un’attività autorizzata da una illecita, individuare le operazioni in corso e agire sui componenti giusti. Nel frattempo le reti blockchain continuano a elaborare transazioni secondo le proprie regole e alcuni atti possono essere già stati trasmessi.
Un’azienda che gestisce asset digitali dovrebbe conoscere in anticipo le leve disponibili: sospensione dei processi ordinari, revoca di credenziali, blocco delle distribuzioni, modifica delle autorizzazioni, eventuale collaborazione con emittenti e piattaforme terze. Non tutti gli asset possono essere congelati nello stesso modo; non tutti i meccanismi dipendono dallo stesso soggetto; non tutte le transazioni possono essere annullate.
È altrettanto importante separare ciò che si può fermare internamente da ciò che richiede cooperazione esterna. Una decisione del team operativo, una procedura giudiziaria e un intervento di un emittente possono avere tempi e condizioni diverse. Le esercitazioni dovrebbero includere scenari nei quali una parte delle credenziali sia compromessa e alcuni sistemi di comunicazione o amministrazione non siano considerati affidabili.
Nel rapporto iniziale Binance dichiara di aver ricostruito l’ambiente wallet e lo strumento IA interessato, sostituito dispositivi e disattivato credenziali e token pertinenti. Sono azioni dichiarate dall’azienda. La loro efficacia nel tempo e la completezza della ricostruzione richiedono la verifica indipendente annunciata dalla stessa società.
Chi c’è dietro l’operazione?
L’FBI ha attribuito il furto a un gruppo nordcoreano noto come TraderTraitor. Binance richiama l’attribuzione statunitense; Reuters ha riferito che la Corea del Nord respinge la responsabilità. È corretto indicare chi formula l’accusa e distinguere il giudizio delle autorità dalle informazioni tecniche che il pubblico può esaminare direttamente.
Le attribuzioni possono basarsi su dati di intelligence, infrastrutture, strumenti, comportamenti e altre evidenze non tutte pubbliche. Un nome di gruppo è una classificazione investigativa, non necessariamente un’organizzazione con confini e membri visibili come quelli di un’azienda. Lo stesso insieme di strumenti può comparire in operazioni diverse; un’analogia tecnica, presa da sola, non dimostra chi abbia commissionato un attacco.
Nel dibattito pubblico è facile passare dalla formula «l’FBI attribuisce l’operazione a» alla frase «ogni dettaglio dell’operazione è stato dimostrato pubblicamente». Non sono equivalenti. Una lettura rigorosa può riferire l’attribuzione ufficiale senza fingere di aver esaminato prove non disponibili.
Che cosa può fare chi riceve una proposta di lavoro
Una proposta inattesa non è di per sé sospetta e non esiste un indicatore che distingua ogni selezione autentica da ogni truffa. Alcune verifiche riducono però la possibilità di affidarsi soltanto all’impressione prodotta da un profilo convincente. Si può cercare l’azienda tramite fonti indipendenti, verificare che la posizione esista sui canali ufficiali e contattare l’organizzazione usando recapiti trovati autonomamente, anziché soltanto quelli contenuti nel messaggio ricevuto.
Se viene proposto un progetto da eseguire, è ragionevole chiedere che cosa contenga, quali prerequisiti richieda e se sia possibile utilizzare un ambiente dedicato. Un recruiter legittimo può fornire chiarimenti e accettare una verifica proporzionata. Un tono pressante o una richiesta di disattivare protezioni meritano attenzione, ma anche l’assenza di questi segnali non garantisce la sicurezza del materiale.
Per chi lavora con sistemi aziendali la misura più immediata è rispettare le regole sull’uso della workstation e rivolgersi al proprio gruppo di sicurezza se un esercizio richiede l’esecuzione di codice esterno. È opportuno segnalare subito un’esecuzione dubbia, indicando quando è avvenuta e quali azioni sono state compiute, senza tentare cancellazioni o bonifiche improvvisate che potrebbero ostacolare l’analisi.
Le domande per le aziende
Una società che sviluppa o custodisce software può utilizzare il caso come esercizio, senza supporre di avere gli stessi strumenti o la stessa esposizione di Binance. Da quali postazioni si può raggiungere l’ambiente di produzione? Quali credenziali sono presenti sui computer degli sviluppatori? Chi può distribuire un container? Quali attività richiedono una seconda autorizzazione? Quali operazioni rimangono possibili se una sessione viene compromessa?
Un inventario dei permessi effettivi può rivelare differenze rispetto alle procedure scritte. Gli accessi temporanei possono restare attivi; un token nato per una prova può acquisire un ruolo operativo; una macchina di sviluppo può accumulare nel tempo connessioni e segreti. La revisione periodica deve includere sia gli account umani sia quelli usati da servizi, automazioni e assistenti.
La capacità di osservare conta quanto quella di bloccare. Registrazioni affidabili, conservate secondo le esigenze dell’organizzazione e protette da modifiche non autorizzate, aiutano a ricostruire accessi e distribuzioni. Gli allarmi devono essere associati a una risposta praticabile: chi riceve la segnalazione, quali informazioni vede, quale decisione può prendere e chi è reperibile fuori orario?
Infine bisogna verificare il ripristino. Sostituire una macchina non basta se la compromissione ha coinvolto credenziali, autorizzazioni persistenti o sistemi raggiunti successivamente. Una risposta completa considera il percorso dell’attaccante, i permessi concessi e l’eventuale riutilizzo delle informazioni raccolte in precedenza. I dettagli dipendono dall’incidente, ma il principio è applicabile ben oltre le criptovalute.
Il mistero che resta
Il rapporto di Binance offre una cronologia articolata, ma lascia aperti interrogativi. Quali controlli specifici hanno consentito all’intruso di usare lo strumento IA interno? Quali verifiche hanno individuato le autorizzazioni malevole? Come saranno valutate indipendentemente le misure introdotte dopo l’attacco? Sono domande legittime; le risposte non devono essere inventate in attesa di un rapporto più completo.
Quello che emerge già oggi è una catena: un programma scaricato da una fonte alterata, informazioni raccolte, una relazione professionale simulata, codice eseguito, accessi estesi, un token prezioso e un servizio di firma raggiunto. Ogni anello ha avuto un proprio contesto. Il risultato finale mostra quanto lontano possa arrivare un’intrusione quando i passaggi successivi non vengono contenuti in tempo.
La parte inquietante del falso colloquio non è la presenza di un’immagine sinistra sullo schermo. È la sua normalità: persone che parlano, una procedura plausibile, un incarico che assomiglia a molti altri. Dietro quel contesto, secondo l’indagine aziendale, c’era codice progettato per ottenere un accesso che il candidato non intendeva concedere.
Fonti e approfondimenti
Binance, rapporto iniziale sull’incidente del 29 ottobre, pubblicato il 3 novembre 2026: Initial Findings and Response Update.
Binance, aggiornamento del 30 ottobre 2026 sulle prime misure e sulla situazione degli utenti: Security Incident Update #2.
Reuters, stato della ripresa dei prelievi e obiettivi dichiarati dalla società, 14 novembre 2026: Binance targets full reopening of withdrawals by next week.
Associated Press, importi sottoposti a sequestro o vincolo e attribuzione dell’FBI, 12 novembre 2026: FBI says US has seized cryptocurrency stolen from Binance.
Quadro delle informazioni verificato il 14 novembre 2026. Alcune cifre e condizioni operative possono evolvere.