Le vol de Binance a commencé par un entretien d’embauche : l’accès a déterminé le coût

En septembre, un ingénieur logiciel de Binance a passé deux entretiens d’embauche avec une entreprise qui n’existait pas. Le premier était un appel vidéo en direct avec une personne des ressources humaines, qui a partagé un compte personnel sur les réseaux sociaux, avec photos et vidéos à l’appui, pour prouver qu’elle était bien réelle. Le second s’est déroulé sur une application de messagerie, avec une personne qui se présentait comme le PDG. Vers la fin, l’ingénieur a été invité à télécharger un exercice de programmation sur son ordinateur professionnel.

Le 29 octobre, des attaquants ont transféré environ 6,34 milliards de dollars depuis des portefeuilles Binance, pour l’essentiel en une vingtaine de minutes. Le FBI a attribué le vol à TraderTraitor, le groupe nord-coréen également tenu pour responsable du vol de 1,5 milliard de dollars commis contre Bybit en février 2025. Il s’agit du plus important vol de cryptomonnaies jamais recensé.

Binance a accepté d’assumer la responsabilité de l’incident et affirme qu’elle couvrira les pertes. Au 3 novembre, l’entreprise déclarait avoir reconstitué 98 % des actifs en jetons concernés et avoir fait geler ou intercepter environ 2,85 milliards de dollars.

La question qui mérite d’être posée est la suivante : à quoi un seul ordinateur portable compromis pouvait-il accéder, et chaque équipe peut-elle tester cela dès aujourd’hui dans son propre environnement ?

Deux points d’entrée et une campagne qui s’est étendue de juin à octobre

Rien dans la mise à jour de Binance du 3 novembre ne laisse penser que des hypertrucages ou d’autres techniques assistées par l’IA aient été utilisés. Les deux intrusions sont passées par des personnes : un ingénieur qui s’est fié à un résultat de recherche et un autre qui a fait confiance à un recruteur.

La campagne a duré au moins cinq mois. En juin, un ingénieur DevOps chargé des portefeuilles, qui cherchait un outil de programmation assistée par l’IA, a téléchargé un programme d’installation Homebrew modifié. L’équipe de sécurité de Binance a repéré l’anomalie, remplacé l’appareil et renouvelé les identifiants. À ce stade, les attaquants avaient déjà découvert qui faisait partie de l’équipe chargée de l’infrastructure des portefeuilles.

Trois mois plus tard, ils sont revenus en passant par une autre porte. L’ingénieur approché en septembre avait un profil sur une plateforme légitime de recherche d’emploi, où figurait son expérience chez Binance. L’exercice de programmation qu’il avait reçu contenait un logiciel malveillant qui s’exécutait pendant l’installation, remplaçait un composant légitime de pyenv par un composant malveillant, se connectait à un serveur contrôlé par les attaquants et effaçait ses traces. Binance affirme que sa protection des terminaux ne l’a pas détecté.

Le 20 octobre, les attaquants se sont servis de cet ordinateur portable et d’un outil d’IA interne pour prendre le contrôle des machines de deux autres ingénieurs, dont celle de l’ingénieur DevOps compromis en juin. Sur cette machine, ils ont trouvé un jeton autorisant le déploiement de conteneurs. Le 29 octobre, ils se sont connectés à l’ordinateur de l’autre ingénieur, ont utilisé les identifiants volés pour déployer un conteneur et ont exécuté le script qui a déclenché le vol.

Pourquoi les pièges tendus par de faux recruteurs fonctionnent encore

Les faux recruteurs et les tests de programmation piégés sont une vieille tactique. Depuis des années, des agents nord-coréens l’emploient contre des développeurs, notamment dans le cadre de la campagne connue sous le nom de Contagious Interview. Binance affirme avoir stoppé à elle seule 57 tentatives présumées liées à la Corée du Nord en 2026.

Le piège fonctionne parce qu’il demande aux ingénieurs de faire quelque chose qu’ils font tous les jours. Exécuter le code d’un dépôt inconnu fait partie du déroulement habituel d’un entretien technique. Il n’y a ni adresse d’expéditeur suspecte ni lien sur lequel passer le curseur, seulement un employeur plausible, une personne en vidéo et une tâche qui ressemble à du travail.

Un message de recruteur est aussi l’une des rares sollicitations spontanées que les gens accueillent favorablement. Aucun programme de sensibilisation ne peut garantir que chaque ingénieur repérera tous les messages convaincants ; les mesures de protection doivent donc partir du principe que l’un d’eux passera entre les mailles du filet.

Comment un seul ordinateur portable a permis d’accéder aux portefeuilles

Ma première question porte sur les mesures de sécurité en place dans l’environnement de cet ingénieur. L’utilisation d’un ordinateur professionnel pour réaliser un test de programmation externe mérite un examen attentif. La préoccupation plus importante est de comprendre comment cette compromission unique a ouvert l’accès à d’autres systèmes puis, à terme, à une infrastructure financière sensible.

Chaque étape suivant l’infection initiale reposait sur une confiance déjà établie au sein de Binance. Un outil d’IA interne a accepté les instructions d’une machine compromise et les a relayées aux appareils de collègues. Un jeton de déploiement se trouvait sur l’ordinateur portable d’un ingénieur. Un déploiement de conteneur effectué avec des identifiants valides a permis de transférer des milliards. Aucun autre piège n’a été nécessaire.

Les outils d’IA internes méritent une attention particulière. Ils disposent souvent de droits étendus sur les dépôts, les terminaux et les services ; quiconque contrôle une machine capable de leur donner des instructions hérite donc de leur portée.

Protéger les développeurs sans freiner l’ingénierie

Les développeurs doivent pouvoir télécharger des paquets, exécuter du code inconnu et tester des logiciels. Verrouiller leurs ordinateurs portables comme des postes de travail du service financier ralentirait considérablement le travail d’ingénierie et pousserait les ingénieurs à chercher des contournements. Une politique interdisant les recherches d’emploi sur les appareils de l’entreprise est raisonnable, mais personne ne la respecte systématiquement. En pratique, l’objectif est de limiter ce qu’un ordinateur de développeur compromis peut faire ensuite.

Quelques mesures font toute la différence. Le code non fiable devrait être exécuté dans des machines virtuelles jetables, sans accès aux identifiants de l’entreprise. Les identifiants de déploiement devraient être de courte durée, avoir une portée strictement limitée et, dans la mesure du possible, être délivrés à des processus de déploiement contrôlés. Les clés de signature de portefeuille ou leurs fragments devraient être protégés séparément des postes de travail des développeurs, et les politiques de signature devraient limiter les transactions et les autorisations pouvant être approuvées. Toute action touchant aux portefeuilles, aux paiements ou aux systèmes de production devrait nécessiter l’approbation d’une deuxième personne sur un appareil distinct. Les outils d’IA internes devraient fonctionner avec le minimum de droits et consigner leurs activités.

La détection doit aussi fonctionner lorsque les identifiants sont légitimes. La surveillance comportementale, qui signale un déploiement effectué depuis une machine inhabituelle ou à une heure inhabituelle, donne à l’équipe la possibilité d’intervenir même lorsque tous les identifiants semblent valides. Binance affirme avoir renforcé ce type de détection depuis l’incident.

Le rôle du renseignement sur les menaces

L’avertissement a été rendu public six semaines avant le vol. L’avis conjoint sur Contagious Interview décrivait des opérateurs se faisant passer pour des recruteurs d’entreprises spécialisées dans l’IA, les cryptomonnaies et les NFT afin de cibler des professionnels de l’informatique et de voler des cryptomonnaies. L’affaire Binance a suivi le même scénario.

Le renseignement sur les menaces joue un rôle concret dans ce type de campagne. Les acteurs peuvent changer, mais leurs tactiques sont connues. Les équipes qui les suivent peuvent bloquer les infrastructures connues et avertir les ingénieurs des prétextes actuellement utilisés.

Le renseignement permet également de déterminer qui a besoin d’une protection renforcée. Dès qu’un incident révèle qui détient des accès sensibles, comme l’a fait la compromission de Binance en juin, ces personnes devraient être considérées comme des cibles potentielles pendant plusieurs mois, et leurs appareils ainsi que les sollicitations qu’elles reçoivent devraient faire l’objet d’une surveillance accrue.

Les conséquences au-delà des cryptomonnaies

Les plateformes d’échange de cryptomonnaies sont des cibles évidentes, car les fonds volés circulent rapidement et sont difficiles à récupérer. Le même schéma se retrouve partout où le poste de travail d’un développeur n’est qu’à quelques étapes de systèmes critiques, qu’il s’agisse de la chaîne de traitement des paiements d’une banque ou du processus de compilation et de mise en production d’un éditeur de logiciels. Les prétextes liés au recrutement ciblent les ingénieurs dans tous ces secteurs.

Pour les responsables de la sécurité qui passent en revue leurs propres environnements cette semaine, deux vérifications sont prioritaires. Premièrement, cartographiez les ressources auxquelles un seul ordinateur portable de développeur compromis pourrait accéder aujourd’hui, notamment les jetons enregistrés, les clés SSH, les identifiants cloud et les outils d’IA internes. Deuxièmement, vérifiez que les déploiements en production et les transactions de grande valeur nécessitent une approbation indépendante qu’une seule identité compromise ne peut pas fournir.

Binance a reconstruit les systèmes touchés et fait appel à des évaluateurs indépendants, les décisions ayant été prises après la perte. Les organisations qui mènent le même exercice dès maintenant peuvent prendre ces décisions selon leur propre calendrier.