Il furto ai danni di Binance è iniziato con un colloquio di lavoro: l’accesso ha determinato il costo

A settembre, un ingegnere software di Binance ha sostenuto due colloqui di lavoro con un’azienda che non esisteva. Il primo è stato una videochiamata in diretta con una persona delle risorse umane, che ha condiviso un account personale sui social media, completo di foto e video, per dimostrare di essere una persona reale. Il secondo si è svolto su un’app di messaggistica, con qualcuno che si è presentato come amministratore delegato. Verso la fine, all’ingegnere è stato chiesto di scaricare un test di programmazione sul computer di lavoro.

Il 29 ottobre, gli aggressori hanno trasferito dai portafogli di Binance circa 6,34 miliardi di dollari, la maggior parte dei quali nell’arco di circa 20 minuti. L’FBI ha attribuito il furto a TraderTraitor, il gruppo nordcoreano ritenuto responsabile anche del furto di 1,5 miliardi di dollari ai danni di Bybit a febbraio 2025. È il più grande furto di criptovalute mai registrato.

Binance si è assunta la responsabilità e afferma che coprirà le perdite. Al 3 novembre, ha dichiarato di aver reintegrato il 98% degli asset in token interessati e che circa 2,85 miliardi di dollari erano stati congelati o intercettati.

La domanda che vale la pena porsi è: a quali risorse poteva accedere un singolo laptop compromesso, e ogni team può verificarlo oggi nel proprio ambiente?

Due punti di accesso e una campagna durata da giugno a ottobre

Nell’aggiornamento del 3 novembre di Binance non c’è nulla che indichi l’uso di deepfake o di altre tecniche basate sull’IA. Entrambe le vie d’accesso sono passate attraverso le persone: un ingegnere che si è fidato di un risultato di ricerca e un altro che si è fidato di un recruiter.

La campagna è durata almeno cinque mesi. A giugno, un ingegnere DevOps responsabile dei portafogli, alla ricerca di uno strumento di programmazione basato sull’IA, ha scaricato un programma di installazione di Homebrew manomesso. Il team di sicurezza di Binance ha rilevato l’anomalia, sostituito il dispositivo e rinnovato le credenziali. A quel punto, gli aggressori avevano già scoperto chi faceva parte del team responsabile dell’infrastruttura dei portafogli.

Tre mesi dopo, sono tornati da un’altra porta. L’ingegnere contattato a settembre aveva un profilo su una legittima piattaforma di ricerca di lavoro, in cui menzionava la sua esperienza presso Binance. Il test di programmazione conteneva un malware che si attivava durante la configurazione, sostituiva un componente legittimo di pyenv con uno dannoso, si collegava a un server controllato dagli aggressori e cancellava le proprie tracce. Binance afferma che il sistema di protezione degli endpoint non lo ha rilevato.

Il 20 ottobre, gli aggressori hanno usato quel laptop e uno strumento interno di IA per prendere il controllo dei computer di altri due ingegneri, uno dei quali apparteneva all’ingegnere DevOps compromesso a giugno. Su quel computer hanno trovato un token con autorizzazioni per la distribuzione di container. Il 29 ottobre, hanno effettuato l’accesso al computer dell’altro ingegnere, usato le credenziali rubate per distribuire un container ed eseguito lo script che ha dato inizio al furto.

Perché gli adescamenti dei recruiter funzionano ancora

I falsi recruiter e i test di programmazione compromessi fanno parte di un vecchio repertorio. Da anni gli operatori nordcoreani li usano contro gli sviluppatori, soprattutto nella campagna nota come Contagious Interview. Binance afferma di aver bloccato 57 tentativi sospetti collegati alla Corea del Nord nel solo 2026.

L’adescamento funziona perché chiede agli ingegneri di fare qualcosa che fanno ogni giorno. Eseguire un repository sconosciuto è una pratica normale durante un colloquio tecnico. Non c’è un indirizzo del mittente sospetto né un link su cui passare il cursore: solo un datore di lavoro plausibile, una persona in video e un’attività che sembra lavoro.

Il messaggio di un recruiter è anche uno dei pochi contatti non richiesti che le persone accolgono con favore. Nessun programma di sensibilizzazione può garantire che ogni ingegnere riconosca ogni messaggio convincente, quindi le misure di sicurezza devono partire dal presupposto che uno riuscirà a passare.

Come un laptop ha raggiunto i portafogli

La mia prima domanda riguarda i controlli di sicurezza presenti nell’ambiente di lavoro di quell’ingegnere. Usare un computer aziendale per svolgere una prova di programmazione esterna merita un esame approfondito. La preoccupazione più grande è capire come quella singola compromissione abbia consentito l’accesso ad altri sistemi e, infine, a infrastrutture finanziarie sensibili.

Ogni passaggio successivo all’infezione iniziale si è basato sulla fiducia già esistente all’interno di Binance. Uno strumento interno di IA ha accettato istruzioni provenienti da un computer compromesso e le ha trasformate in azioni sui dispositivi dei colleghi. Su un laptop di un ingegnere si trovava un token di distribuzione. Una distribuzione di container effettuata con credenziali valide ha movimentato miliardi. Non è stato necessario ricorrere a un altro adescamento.

Gli strumenti interni di IA meritano particolare attenzione. Spesso dispongono di ampie autorizzazioni su repository, endpoint e servizi, perciò chiunque controlli un computer in grado di impartire istruzioni a uno di questi strumenti ne eredita la portata.

Proteggere gli sviluppatori senza rallentare l’ingegneria

Gli sviluppatori devono scaricare pacchetti, eseguire codice sconosciuto e testare software. Bloccare i loro laptop come si farebbe con una postazione di lavoro finanziaria rallenterebbe l’ingegneria fino quasi a fermarla e spingerebbe gli ingegneri a cercare soluzioni alternative. Una regola che vieti di svolgere attività di ricerca di lavoro sui dispositivi aziendali è ragionevole, ma nessuno la rispetta sempre. L’obiettivo pratico è limitare ciò che un computer di uno sviluppatore compromesso può fare in seguito.

Una manciata di misure fa la differenza più grande. Il codice non attendibile dovrebbe essere eseguito in macchine virtuali usa e getta, senza accesso alle credenziali aziendali. Ove possibile, le credenziali di distribuzione dovrebbero avere una durata limitata, ambiti ristretti ed essere rilasciate a flussi di lavoro controllati per la distribuzione. Le chiavi di firma dei portafogli o le quote di chiave dovrebbero essere protette separatamente dalle postazioni di lavoro degli sviluppatori, con criteri di firma che limitino le transazioni e le autorizzazioni approvabili. Le azioni che interessano portafogli, pagamenti o sistemi di produzione dovrebbero richiedere l’approvazione di una seconda persona, da un dispositivo separato. Gli strumenti interni di IA dovrebbero funzionare con autorizzazioni minime e registrare le proprie attività.

Il rilevamento deve funzionare anche quando le credenziali sono legittime. Il monitoraggio comportamentale, segnalando una distribuzione avviata da una macchina insolita o a un’ora inaspettata, dà al team la possibilità di intervenire anche quando tutte le credenziali risultano valide. Binance afferma di aver potenziato questo tipo di rilevamento dopo l’incidente.

Dove si inserisce la threat intelligence

L’allerta era pubblica da sei settimane prima del furto. L’avviso congiunto su Contagious Interview descriveva operatori che si spacciavano per reclutatori di aziende del settore dell’IA, delle criptovalute e degli NFT per prendere di mira professionisti IT e rubare criptovalute. Il caso di Binance ha seguito lo stesso copione.

La threat intelligence ha un ruolo concreto in campagne come questa. Gli attori possono cambiare, ma le loro tattiche sono note. I team che li monitorano possono bloccare le infrastrutture note e avvisare gli ingegneri dei pretesti attualmente utilizzati.

L’intelligence indica anche chi, all’interno di un team, ha bisogno di maggiore protezione. Quando un incidente rivela chi dispone di accessi sensibili, come è avvenuto con la compromissione di Binance a giugno, queste persone dovrebbero essere considerate probabili bersagli per mesi, monitorando più da vicino i loro dispositivi e i tentativi di contatto che ricevono.

Cosa significa al di fuori del mondo delle criptovalute

Gli exchange di criptovalute sono un bersaglio ovvio, perché i fondi rubati si spostano rapidamente ed è difficile recuperarli. Lo stesso schema si ripete ovunque una postazione di lavoro per sviluppatori si trovi a pochi passaggi dai sistemi critici, che si tratti della catena di elaborazione dei pagamenti di una banca o del processo di compilazione e rilascio di un fornitore di software. I pretesti legati al reclutamento raggiungono gli ingegneri di tutti questi settori.

Per i responsabili della sicurezza che questa settimana stanno esaminando i propri ambienti, sono fondamentali due verifiche. Primo, mappare ciò a cui potrebbe accedere oggi un singolo portatile di uno sviluppatore compromesso, inclusi i token memorizzati, le chiavi SSH, le credenziali cloud e gli strumenti interni di IA. Secondo, verificare che le distribuzioni in produzione e le transazioni di valore elevato richiedano un’approvazione indipendente, che una singola identità compromessa non possa fornire.

Binance ha ricostruito i sistemi interessati e si è avvalsa di revisori indipendenti, prendendo decisioni dopo la perdita. Le organizzazioni che svolgono ora lo stesso esercizio possono prendere queste decisioni secondo i propri tempi.