if ( !emtpy($headline_subheadline ) ) : ?>
Le rapport initial de l’entreprise soulève un certain nombre de questions sur ses politiques de sécurité, ses contrôles et ses formations de sensibilisation, ainsi que sur la manière dont elle régit les outils d’IA internes – une leçon clé pour les RSSI.
endif; ?>
Une chaîne de défaillances techniques et humaines évitables a permis le plus grand braquage de crypto-monnaie jamais enregistré, le vol d’environ 6,34 milliards de dollars auprès de Binance. La surveillance inappropriée et la portée de l’accès à un outil d’IA interne ont joué un rôle majeur en aidant les pirates informatiques et devraient servir d’avertissement aux RSSI d’entreprise pour qu’ils prennent la gouvernance de l’IA au sérieux.
Le rapport de conclusions initiales de Binance, publié le 3 novembre, décrit une campagne en plusieurs étapes d’un mois contre ses ingénieurs d’infrastructure de portefeuille qui a abouti à l’installation de logiciels malveillants sur les machines des développeurs lors de deux incidents distincts, dont un seul a été détecté. Les attaquants ont ensuite pu basculer via un outil d’IA interne vers des systèmes de développement supplémentaires, obtenir un jeton d’accès et déployer un conteneur sur l’infrastructure de Binance avant d’exécuter les retraits malveillants.
Bien que Binance décrit cette attaque comme très sophistiquée, de multiples failles de sécurité auraient pu être évitées, depuis des contrôles d’accès faibles ou absents jusqu’à des privilèges trop étendus, une mauvaise hygiène des informations d’identification et des manquements de sensibilisation à la sécurité des employés ou des violations des politiques.
« Les postes de travail des développeurs sont progressivement devenus l’un des actifs les plus privilégiés de l’entreprise, car ils contiennent des jetons de déploiement, des accès de signature et maintenant des outils d’IA qui peuvent agir sur les systèmes internes au nom d’un employé », prévient Joe Brinkley, directeur de la recherche et de la communauté en matière de sécurité offensive chez la société de sécurité Cobalt. « Une fois qu’un attaquant contrôle cette machine, un outil d’IA doté d’une large portée interne devient une voie de confiance supplémentaire qu’il peut utiliser. »
Il ajoute : « Les équipes de sécurité doivent traiter les ingénieurs disposant d’un accès à la production ou à la signature comme une surface d’attaque de grande valeur, tester le chemin du poste de travail à la production comme le ferait un adversaire et définir les autorisations des outils d’IA aussi étroitement que n’importe quel compte de service.
Deux compromis à des mois d’intervalle
Le FBI a attribué la violation de Binance à la Corée du Nord, identifiant l’unité de piratage comme étant TraderTraitor, que d’autres chercheurs considèrent comme faisant partie de l’opération plus large de Lazarus qui a volé des milliards de dollars sur les plateformes de cryptomonnaie au cours de la dernière décennie. Le propre rapport de Binance relaie la conclusion du FBI et note qu’au cours de l’année 2026, l’équipe de sécurité de l’entreprise a détecté et évité 57 cas suspectés de cybermenaces liés à la Corée du Nord.
Cela suggère que Binance a l’APT Lazarus dans son modèle de menace, comme il se doit, et est bien conscient des outils, techniques et procédures (TTP) du groupe, qui incluent des compromissions dans la chaîne d’approvisionnement logicielle, l’utilisation de logiciels malveillants se faisant passer pour des outils légitimes populaires, trompant les développeurs avec de faux entretiens d’embauche et des opérations d’ingénierie sociale à long terme. Pourtant, deux ingénieurs de Binance ont été victimes de ces astuces, soulevant des questions sur la formation de sensibilisation à la sécurité de l’entreprise ainsi que sur ses contrôles techniques.
En juin, un ingénieur en infrastructure de portefeuille a recherché sur le Web un outil de codage d’IA populaire et a téléchargé un programme d’installation Homebrew falsifié plutôt que d’obtenir le logiciel auprès d’une source fiable. Homebrew est un gestionnaire de packages et un canal de distribution pour les applications open source sur macOS. L’équipe de sécurité de Binance a détecté l’anomalie, remplacé l’appareil et modifié toutes les informations d’identification associées, mais les attaquants avaient déjà appris qui était l’ingénieur et qui d’autre travaillait dans l’équipe d’infrastructure du portefeuille.
C’est bien que Binance ait pu détecter rapidement la violation, mais l’incident soulève la question de savoir pourquoi un ingénieur installait un logiciel à partir d’un résultat de recherche. Binance a-t-elle une politique selon laquelle les employés installent des logiciels uniquement à partir de sources approuvées, et cette politique est-elle appliquée avec des contrôles techniques tels que la liste blanche des applications ?
Trois mois plus tard, les attaquants ont contacté un deuxième ingénieur via une plateforme de recherche d’emploi, se faisant passer pour un directeur de projet recrutant pour une entreprise qui n’existait pas. Deux entretiens par étapes ont suivi : l’un avec un prétendu représentant des ressources humaines qui a partagé un compte de réseau social rempli de photos et de vidéos personnelles pour instaurer la confiance, et l’autre avec quelqu’un prétendant être le PDG de l’entreprise.
À la fin du deuxième entretien, il a été demandé à l’ingénieur de télécharger une tâche de codage sur son ordinateur de travail à partir d’un référentiel. La mission incluait du code malveillant, et cette fois, les outils de protection des points finaux de Binance ne l’ont pas détecté. L’entreprise a décrit cela comme un malware zero-day, mais si les outils de protection des terminaux étaient uniquement capables de détecter les malwares connus, alors l’ensemble du secteur aurait un problème.
Quoi qu’il en soit, les actions du développeur soulèvent un certain nombre de questions concernant les politiques de sécurité, les procédures et la sensibilisation chez Binance, la première d’entre elles : pourquoi l’ingénieur effectuait-il des entretiens d’embauche et des tests sur son ordinateur de travail ? Pourquoi ont-ils cloné un référentiel directement sur leur système au lieu d’utiliser une machine virtuelle ? Si c’est quelque chose qu’ils font régulièrement, cela indique des lacunes dans la formation en matière de sécurité ou des violations intentionnelles des politiques. Et les entreprises ne peuvent pas uniquement compter sur les employés qui respectent toujours les politiques. Ils ont besoin de mécanismes de détection et d’application.
« L’ingénieur a commis plusieurs erreurs », déclare Tim Chase, vice-président adjoint pour la cybersécurité chez Fable Security, société de gestion des risques humains. « Un programme de gestion des risques moderne aurait dû garantir qu’il comprenait la surface (d’attaque) moderne de l’ingénierie sociale que les attaquants utilisent aujourd’hui. »
Un outil d’IA surprivilégié permet un mouvement latéral
Une fois que les attaquants ont exécuté un logiciel malveillant sur l’ordinateur de l’ingénieur, ils ont pu utiliser un outil d’IA interne présent sur celui-ci pour pivoter vers des machines supplémentaires appartenant à deux autres ingénieurs de l’équipe d’infrastructure du portefeuille.
Sur l’un des ordinateurs d’ingénierie supplémentaires, les attaquants ont trouvé un jeton avec l’autorisation de déployer de nouveaux conteneurs sur l’infrastructure de l’entreprise. Neuf jours plus tard, ils ont utilisé ce jeton sur un autre ordinateur d’ingénierie compromis pour déployer un conteneur avec un script malveillant qui interagissait avec le service de signature de portefeuille et initiait des retraits.
« Un outil d’IA interne capable d’accéder aux systèmes des ingénieurs bénéficie du même type d’accès qu’un employé privilégié, et la plupart des organisations ne le gèrent pas de cette façon », explique Justin Beals, PDG de Strike Graph. « Attendez-vous à ce que davantage de groupes copient ce manuel contre toute personne détenant des clés de signature, des jetons de déploiement ou un accès à la production. Les responsables de la sécurité devraient traiter les ingénieurs ayant un accès à la production et les outils d’IA que ces ingénieurs utilisent comme des identités privilégiées. Cela signifie restreindre ce qui est installé sur les machines de travail, expirer rapidement les jetons de déploiement, et enregistrer et examiner ce que font réellement les outils d’IA internes. «
Shlomi Salem, co-fondateur de Neo, une startup axée sur la sécurité des agents d’IA, a prédit le vecteur d’attaque de l’IA quelques jours avant que Binance ne publie ses conclusions. « Je ne serais pas surpris si les enquêteurs découvrent un colis empoisonné, un agent mal utilisé, ou les deux, au début de cette chaîne », a-t-il déclaré le 30 octobre après l’annonce de la brèche.
« Lorsqu’un outil d’IA peut atteindre d’autres systèmes au nom d’un employé, un attaquant qui contrôle la machine de cet employé peut hériter de tout ce que l’outil peut faire », explique-t-elle. « Cela change la question à laquelle les équipes de sécurité doivent répondre. Il ne s’agit pas seulement de savoir si le modèle donne de bonnes réponses, mais aussi de savoir ce qu’il fera et pour qui, lorsqu’une demande provient d’une session compromise. »
