Piratage de Binance : comment deux ingénieurs ont été piégés et comment empêcher une attaque similaire

Le piratage de Binance du 29 octobre 2026, estimé à environ 6,3 milliards de dollars, révèle une méthode d’infiltration particulièrement inquiétante. Les attaquants n’auraient pas commencé par forcer les protections cryptographiques des portefeuilles. Ils auraient d’abord compromis les ordinateurs d’ingénieurs, exploité leurs accès professionnels, puis détourné des mécanismes internes permettant d’autoriser des transactions.

Le 3 novembre, Binance a détaillé une opération préparée pendant plusieurs mois. Un premier ingénieur avait installé un logiciel compromis en juin. Un deuxième a été piégé en septembre par une fausse procédure de recrutement. Les pirates auraient ensuite utilisé un outil d’intelligence artificielle interne pour progresser dans les systèmes de l’entreprise, avant de dérober des identifiants et d’exécuter leur attaque.

En bref

• Binance décrit une infiltration en plusieurs étapes, commencée avant le vol du 29 octobre.
• Le détournement des autorisations ne démontre pas, à lui seul, une fuite des clés privées.
• Les protections doivent séparer postes de travail, déploiements et décisions de signature.

1. Binance infiltré pendant plusieurs mois

Juin 2026 : un logiciel compromis ouvre la première porte

L’attaque commence plusieurs mois avant le vol des cryptomonnaies. Elle montre pourquoi la sécurité d’un portefeuille crypto dépend aussi des systèmes qui préparent les opérations.

Cette affaire mérite une analyse technique approfondie. Comment un simple entretien d’embauche peut-il compromettre une plateforme qui protège des milliards de dollars ? Quel rôle l’IA a-t-elle réellement joué ? Pourquoi les dispositifs de sécurité n’ont-ils pas arrêté les transferts immédiatement ? Et surtout, quelles protections permettraient d’empêcher qu’une compromission de poste de travail se transforme en catastrophe financière ?

Selon le compte rendu du briefing publié par CoinDesk, Binance affirme que les pirates ont détourné ses accès internes. Dans sa communication officielle du 30 octobre, la plateforme indiquait ne pas avoir trouvé de preuve de fuite des clés privées.

En juin 2026, un ingénieur de Binance cherche un outil lié à l’intelligence artificielle. Dans le cadre de cette recherche, il installe un composant logiciel compromis associé à Homebrew.

Homebrew est un gestionnaire de paquets très utilisé sur macOS et Linux. Il permet aux développeurs d’installer des logiciels, des bibliothèques et des outils de programmation depuis leur terminal, sans devoir télécharger et configurer manuellement chaque application.

Par exemple, une commande comme brew install suivie du nom d’un logiciel permet de demander son installation.

Le problème ne vient pas nécessairement de Homebrew lui-même. Les attaquants peuvent détourner la chaîne de distribution d’un outil, proposer un paquet malveillant ou manipuler la source depuis laquelle un programme est récupéré.

Dans le cas de Binance, les informations publiques indiquent que l’ingénieur a installé un composant altéré. Elles ne suffisent pas à établir que l’infrastructure officielle de Homebrew a été piratée.

Binance affirme avoir détecté le logiciel malveillant et remplacé l’ordinateur. Pourtant, les attaquants avaient déjà obtenu des renseignements utiles sur la fonction de cet ingénieur et sur ses collègues travaillant sur les portefeuilles de cryptomonnaies.

C’est une distinction essentielle en cybersécurité. Supprimer un malware ne supprime pas les informations que l’attaquant a déjà récupérées.

Un pirate peut conserver des renseignements sur l’organisation, les noms des employés, les outils internes, les processus de déploiement ou les relations entre différentes équipes. Ces informations lui permettent de préparer une attaque plus ciblée.

Septembre : un faux recrutement piège un deuxième ingénieur

Quelques mois plus tard, un autre ingénieur logiciel reçoit une proposition professionnelle par l’intermédiaire d’une véritable plateforme de recrutement.

L’interlocuteur se présente comme directeur de projet d’une entreprise. Une personne jouant le rôle de responsable des ressources humaines organise un entretien vidéo. Le faux recruteur partage également un profil sur les réseaux sociaux, accompagné de photographies personnelles.

L’objectif est de construire une relation crédible.

Un deuxième entretien est ensuite organisé avec une personne présentée comme le directeur général de l’entreprise.

À l’issue de cet échange, le candidat est invité à télécharger un dépôt de code contenant un exercice technique.

Cette étape est courante dans le recrutement informatique. Les candidats doivent parfois examiner un projet, corriger des erreurs, écrire des tests ou développer une fonctionnalité.

Les pirates exploitent précisément cette habitude.

Le dépôt contient un malware que Binance présente comme ayant échappé aux protections de l’ordinateur professionnel. Le compte rendu de CoinDesk emploie le terme « zero-day malware ». Cette formulation ne permet pas, à elle seule, d’identifier une vulnérabilité précise ou un numéro CVE. Les éléments publics consultés ne détaillent pas le mécanisme ayant permis de contourner la protection du poste.

Le piège fonctionne parce que l’ingénieur pense réaliser un exercice professionnel légitime. Il ne cherche pas à contourner la sécurité de Binance. Il répond à une demande qui ressemble à une étape ordinaire d’un recrutement.

C’est ce qu’on appelle l’ingénierie sociale : manipuler une personne pour qu’elle accomplisse elle-même une action facilitant l’intrusion.

Octobre : les pirates utilisent l’IA pour progresser

Le 20 octobre, selon les explications du responsable de la sécurité de Binance, les attaquants utilisent l’ordinateur compromis lors du faux recrutement ainsi qu’un outil d’IA interne pour accéder aux systèmes de deux ingénieurs travaillant sur les portefeuilles.

Cette information est particulièrement importante.

Il ne s’agit pas simplement d’un chatbot public auquel les pirates auraient demandé comment voler des cryptomonnaies. Les informations rapportées évoquent l’utilisation d’un outil interne dans le cadre d’une intrusion déjà engagée.

Un assistant d’IA intégré à un environnement professionnel peut, selon ses autorisations, consulter du code, rechercher des fichiers, interagir avec des outils de développement ou exécuter certaines opérations.

Si l’ordinateur depuis lequel cet assistant fonctionne est compromis, ses capacités peuvent devenir utiles à l’attaquant.

Cependant, Binance n’a pas publiquement détaillé toutes les commandes exécutées par l’outil d’IA ni démontré que celui-ci aurait pris des décisions malveillantes de manière autonome.

Il serait donc incorrect d’affirmer que l’IA a piraté Binance toute seule. Les pirates restent les acteurs de l’attaque. L’IA aurait été un instrument facilitant leur progression.

29 octobre : le vol est exécuté

Le 29 octobre, les attaquants passent à la phase financière.

Selon Binance, ils utilisent un ordinateur compromis et des identifiants dérobés à un autre ingénieur pour déployer un conteneur informatique et exécuter un script malveillant.

Un conteneur est un environnement logiciel permettant de faire fonctionner une application avec ses dépendances. Il est très utilisé pour déployer des services informatiques de façon reproductible.

Dans une entreprise comme Binance, certains services internes communiquent avec les infrastructures qui gèrent les transactions et les portefeuilles.

À 20 h 05 UTC, les fonds commencent à sortir. Les attaquants exploitent notamment une fonctionnalité d’Ethereum appelée EIP-7702 pour détourner les autorisations d’exécution d’un portefeuille connecté à Internet.

Les sorties liées à ce mécanisme ne sont complètement contenues que vers 00 h 10 UTC, le 30 octobre, selon les explications rapportées par CoinDesk.

Chronologie de l’intrusion, selon Binance

1. Juin 2026 : Premier ingénieur compromis par un logiciel altéré.
2. Septembre 2026 : Deuxième ingénieur piégé par un faux recrutement.
3. 20 octobre : Progression vers les systèmes de l’équipe des portefeuilles avec l’aide d’un outil d’IA interne.
4. 29 octobre : Utilisation d’identifiants volés et déploiement d’un script malveillant.
5. 29-30 octobre : Transferts non autorisés, confinement de l’incident et opérations de gel des actifs.
6. 3 novembre : Binance rend publique une chronologie plus détaillée de l’attaque.

2. Comment les pirates ont contourné la sécurité des portefeuilles

Le vol d’un jeton de déploiement n’est pas le vol d’une clé privée

Pour comprendre cette attaque, il faut distinguer trois éléments souvent confondus : les identifiants professionnels, les jetons de déploiement et les clés privées des portefeuilles crypto.

Une clé privée est un secret cryptographique permettant de signer des transactions. Celui qui la possède peut, selon le type de portefeuille et ses règles de fonctionnement, autoriser le transfert des fonds.

Un jeton de déploiement est différent. Il sert à authentifier un utilisateur ou un service auprès d’une infrastructure informatique pour effectuer certaines opérations, comme publier une nouvelle version d’application, lancer un conteneur ou mettre à jour un service.

Ce jeton peut être extrêmement sensible lorsque le service auquel il donne accès intervient dans le traitement des transactions financières.

Imaginons une banque disposant d’un coffre-fort protégé par plusieurs clés. Les employés n’ont pas forcément accès directement à ces clés. Ils utilisent cependant un système informatique qui prépare les opérations, demande les autorisations et transmet les instructions au coffre.

Si un pirate parvient à manipuler ce système, il peut essayer de lui faire préparer ou approuver une opération frauduleuse.

C’est le risque illustré par l’affaire Binance.

Les informations publiées décrivent l’utilisation d’identifiants volés pour déployer un conteneur et exécuter un script malveillant. Elles ne permettent pas encore de reconstituer entièrement le rôle précis de chaque jeton dans la chaîne d’exploitation.

Il faut donc éviter une simplification trompeuse : le vol d’un jeton de déploiement n’équivaut pas automatiquement à une autorisation de vider un portefeuille.

Pour que l’attaque aboutisse, d’autres conditions doivent être réunies, notamment des droits excessifs, une faiblesse dans la validation des opérations ou la compromission de composants de confiance.

Pourquoi le MPC ne suffit pas à valider une intention légitime

Binance utilise notamment des mécanismes de calcul multipartite, appelés MPC (Multi-Party Computation), pour protéger certaines opérations cryptographiques.

Le principe consiste à répartir le processus de signature entre plusieurs parties, comme l’explique le NIST sur la cryptographie à seuil. Il ne faut pas le confondre avec une multisignature utilisant plusieurs clés distinctes.

Au lieu de conserver une clé privée complète sur un seul ordinateur, le système permet à plusieurs composants de participer à la production d’une signature valide, sans nécessairement reconstituer la clé en un seul endroit.

C’est une protection importante.

Mais elle ne résout pas tous les problèmes.

Si un attaquant compromet les composants qui décident quelles transactions doivent être signées, il peut chercher à faire approuver des opérations frauduleuses par un système dont les clés cryptographiques restent pourtant protégées.

La signature peut alors être techniquement valide, alors que l’opération ne correspond à aucune intention légitime.

Dans le cas de Binance, l’attaque a également exploité une particularité d’Ethereum.

EIP-7702 : une fonctionnalité légitime détournée

L’EIP-7702 est une évolution du protocole Ethereum introduite avec la mise à niveau Pectra en mai 2025.

La spécification EIP-7702 permet à des comptes Ethereum classiques de déléguer leur exécution à du code de smart contract au moyen d’une autorisation signée. Cette délégation persiste jusqu’à sa modification ou sa révocation : elle n’expire pas automatiquement à la fin de la transaction.

Un smart contract est un programme exécuté sur la blockchain. Il peut appliquer automatiquement des règles, transférer des actifs ou interagir avec d’autres contrats.

Cette fonctionnalité présente des usages légitimes, notamment pour améliorer l’expérience des utilisateurs et la gestion des comptes. Ces évolutions s’inscrivent dans le développement des wallets intelligents et de l’account abstraction.

Les pirates ont toutefois exploité ce mécanisme pour obtenir des droits d’exécution sur un portefeuille chaud de Binance.

Un portefeuille chaud, ou hot wallet, reste connecté à des systèmes accessibles en ligne afin de traiter rapidement les dépôts et retraits.

Dans son analyse on-chain de l’attaque, TRM Labs décrit plusieurs autorisations EIP-7702 préalablement signées, afin de pouvoir en utiliser une au moment opportun.

Pourquoi plusieurs autorisations ?

Sur Ethereum, les transactions d’un compte utilisent un compteur appelé nonce. Ce mécanisme aide notamment à empêcher la réutilisation de certaines transactions.

Dans un portefeuille très actif, ce compteur évolue rapidement.

Préparer plusieurs autorisations correspondant à différentes valeurs possibles permet à un attaquant de s’adapter au compteur du portefeuille au moment de l’exploitation.

D’après TRM Labs, les pirates avaient préparé 50 autorisations couvrant une succession de valeurs de nonce. L’une d’elles a pu être utilisée.

Le mécanisme a ensuite permis de détourner l’exécution du portefeuille pour transférer ses actifs.

Cela ne signifie pas que l’EIP-7702 constitue, en lui-même, une faille de sécurité. Il s’agit d’une fonctionnalité dont les autorisations doivent être particulièrement bien protégées.

Pourquoi arrêter les retraits n’a pas immédiatement suffi

Lorsqu’une plateforme crypto détecte un piratage, sa première réaction consiste généralement à suspendre les retraits.

Cette mesure empêche normalement les utilisateurs et les acteurs malveillants de demander de nouveaux transferts par les interfaces habituelles.

Cependant, toutes les opérations sur la blockchain ne passent pas nécessairement par ces interfaces.

Si un attaquant a déjà obtenu des autorisations valides ou détourné un composant capable de signer des transactions, il peut parfois continuer à agir directement au niveau de la blockchain.

C’est l’une des difficultés rencontrées par Binance.

CoinDesk rapporte que la révocation de l’autorisation malveillante sur Ethereum était compliquée par l’architecture MPC utilisée pour protéger les signatures. Le confinement de ce mécanisme a donc nécessité plusieurs heures. L’analyse indépendante d’Hypernative situe également la révocation vers 00 h 10 UTC le 30 octobre.

Une précision s’impose : les premières communications de Binance évoquaient l’arrêt des sorties après la suspension des retraits. Les explications techniques ultérieures font apparaître une situation plus complexe concernant les autorisations EIP-7702. Ces déclarations doivent être replacées dans leur chronologie, plutôt que considérées comme un compte rendu technique unique et définitif.

L’ampleur financière de l’attaque

Bilan communiqué au 3 novembre 2026

6,3 Md$

Montant approximatif des actifs touchés

2,85 Md$

Actifs gelés selon Binance

98 %

Tokens affectés reconstitués selon l’entreprise

10

Blockchains suivies dans le périmètre de TRM Labs

Chiffres rapportés par Binance et les médias spécialisés. Le gel d’actifs ne signifie pas nécessairement leur récupération définitive.

Binance affirme que les pertes des utilisateurs seront couvertes et que les actifs concernés ont été largement reconstitués grâce aux fonds de l’entreprise.

Il faut distinguer trois opérations financières.

La première est le gel des cryptomonnaies. Certaines entreprises émettrices de stablecoins peuvent bloquer les jetons qu’elles contrôlent lorsqu’une transaction est liée à une activité frauduleuse.

La deuxième est la récupération effective des actifs. Elle peut nécessiter des procédures judiciaires, une coopération internationale ou l’intervention d’autres plateformes.

La troisième est le remboursement ou la reconstitution des réserves avec les fonds propres de l’entreprise.

Une plateforme peut donc protéger ses clients contre une perte financière sans avoir récupéré les cryptomonnaies initialement volées.

Qui se cache derrière l’attaque ?

Dans une alerte publiée le 31 octobre, le FBI attribue l’opération à la Corée du Nord et désigne l’activité sous le nom TraderTraitor.

Des entreprises spécialisées dans l’analyse des transactions blockchain ont également relevé des similitudes avec les méthodes du groupe TraderTraitor, associé à des opérations nord-coréennes.

Pyongyang conteste cette attribution.

L’attribution d’une cyberattaque repose généralement sur un ensemble d’indices : infrastructures utilisées, logiciels malveillants, méthodes d’infiltration, mouvements de fonds et ressemblances avec des opérations antérieures.

Elle ne doit pas être confondue avec une identification judiciaire définitive de chaque participant.

3. Comment réduire le risque d’une nouvelle attaque de ce type

L’enseignement le plus important de cette affaire est qu’une entreprise peut disposer d’une excellente cryptographie tout en restant vulnérable à une attaque contre ses collaborateurs et ses outils de développement.

Pour empêcher une opération comparable, il faut renforcer plusieurs niveaux de sécurité simultanément.

1. Isoler les ordinateurs des ingénieurs

Le premier problème est la possibilité d’utiliser un ordinateur professionnel sensible pour installer ou exécuter du code provenant d’une source extérieure.

Dans une organisation financière, tous les ordinateurs ne devraient pas avoir les mêmes droits.

Un développeur chargé d’applications ordinaires peut avoir besoin d’installer des bibliothèques et d’exécuter des projets externes. Un ingénieur qui intervient sur l’infrastructure de signature des portefeuilles doit travailler dans un environnement beaucoup plus restrictif.

La protection peut reposer sur une séparation entre deux postes ou environnements.

Poste de développement

Tests, recrutement, logiciels externes

Environnement critique

Signatures, déploiements, portefeuilles

Les fichiers et programmes non approuvés ne doivent pas pouvoir passer librement du premier environnement au second.

Dans la pratique, cette séparation peut être obtenue avec des machines dédiées, des postes virtuels sécurisés ou des environnements d’administration isolés.

Le principe est simple : un ordinateur utilisé pour tester un projet inconnu ne doit jamais disposer directement des privilèges nécessaires pour modifier une infrastructure financière critique.

Même si un malware infecte le premier poste, l’attaquant doit rencontrer une nouvelle barrière indépendante.

2. Sécuriser les installations Homebrew et les dépendances

Interdire tous les outils externes serait difficilement compatible avec le travail des développeurs. Il faut donc contrôler leur provenance et leur exécution, dans l’esprit du cadre SSDF du NIST pour le développement sécurisé.

Une entreprise comme Binance devrait notamment appliquer les mesures suivantes :

• Autoriser uniquement des dépôts logiciels et des registres approuvés.
• Vérifier l’intégrité et, lorsque c’est possible, les signatures des paquets téléchargés.
• Utiliser un miroir interne pour distribuer les logiciels validés.
• Examiner les scripts d’installation, particulièrement ceux exécutés avec des privilèges élevés.
• Bloquer l’installation directe de programmes inconnus sur les postes sensibles.
• Analyser les dépendances logicielles et surveiller leurs mises à jour.

Il faut aussi éviter une pratique dangereuse : télécharger un script depuis Internet et l’exécuter immédiatement avec les droits de l’utilisateur ou de l’administrateur.

Un script apparemment anodin peut installer un programme supplémentaire, récupérer des identifiants ou établir une communication avec un serveur contrôlé par l’attaquant.

Les contrôles doivent également couvrir les extensions des éditeurs de code, les bibliothèques Python, les paquets npm et les outils d’IA destinés aux développeurs.

La sécurité de la chaîne d’approvisionnement logicielle ne concerne pas uniquement les grandes applications. Elle commence parfois avec une dépendance installée en quelques secondes.

3. Neutraliser les faux entretiens d’embauche

L’attaque contre le deuxième ingénieur démontre que les procédures de recrutement constituent elles aussi une surface d’attaque.

Les entreprises devraient former leurs collaborateurs à reconnaître les signaux suspects, sans considérer que la formation suffit à elle seule.

Un entretien vidéo crédible ne garantit pas l’authenticité de l’entreprise. Un recruteur peut présenter de faux profils professionnels, utiliser des identités usurpées ou créer un site Internet convaincant.

Pour les collaborateurs qui occupent des fonctions sensibles, les exercices de recrutement externes devraient être réalisés dans un environnement isolé.

L’ingénieur pourrait télécharger le projet, l’examiner et l’exécuter dans une machine virtuelle jetable, dépourvue de secrets professionnels et sans connexion aux systèmes internes.

L’environnement devrait être détruit après l’exercice.

Il faut toutefois comprendre qu’une machine virtuelle n’offre pas une protection absolue. Sa configuration, ses accès réseau, les dossiers partagés et les vulnérabilités de l’hyperviseur doivent également être maîtrisés.

Une règle organisationnelle serait particulièrement utile : tout exercice technique reçu d’un recruteur extérieur doit être considéré comme du code non fiable, même lorsque l’entretien paraît légitime.

4. Protéger les jetons de déploiement

C’est probablement l’une des mesures les plus importantes pour empêcher une intrusion informatique de se transformer en vol financier.

Un jeton de déploiement ne devrait jamais donner accès à davantage de ressources que celles nécessaires à une tâche précise.

C’est le principe du moindre privilège.

Un jeton destiné à déployer une application de surveillance ne doit pas permettre de modifier un service de signature des transactions.

Il faut également privilégier des identifiants de courte durée, générés pour une opération déterminée, plutôt que des secrets permanents stockés sur les ordinateurs des ingénieurs.

Les mesures recommandées comprennent une authentification forte, la rotation automatique des identifiants, des coffres de secrets centralisés et une journalisation détaillée de chaque utilisation.

Pour les opérations critiques, les jetons devraient être associés à une identité de service vérifiable et à un contexte précis.

Par exemple, un jeton autorisé à publier une version depuis un pipeline de déploiement approuvé ne devrait pas pouvoir être réutilisé librement depuis l’ordinateur personnel d’un ingénieur.

Même si le jeton est dérobé, il devient beaucoup moins utile à l’attaquant.

5. Empêcher les déploiements non autorisés

Une entreprise qui conserve des milliards de dollars en cryptomonnaies ne devrait pas permettre à un seul poste compromis de modifier le comportement de ses services financiers critiques.

Les déploiements sensibles doivent passer par un processus indépendant de validation.

Cela peut comprendre une revue de code obligatoire, la signature des artefacts logiciels, l’approbation de plusieurs responsables et la vérification automatique des changements avant leur mise en production.

Il est également possible d’interdire l’exécution de conteneurs dont les images ne proviennent pas d’un registre interne approuvé.

Une politique d’admission peut vérifier qu’un conteneur possède une signature valide et correspond à une version autorisée.

Ces contrôles sont particulièrement utiles contre une attaque reposant sur des identifiants volés.

Le pirate peut réussir à s’authentifier, sans pour autant pouvoir déployer n’importe quel programme.

6. Séparer les autorisations de signature des opérations informatiques

Les mécanismes MPC et multisignatures doivent être accompagnés d’une validation indépendante du contenu des transactions.

La question n’est pas seulement de savoir si une transaction possède une signature cryptographique valide.

Il faut également vérifier si cette transaction est autorisée par les règles financières de l’entreprise.

Un système robuste devrait contrôler les adresses de destination, les montants, les limites de transfert, les types d’opérations et les changements de permissions sur les portefeuilles.

Dans le cas d’Ethereum, les autorisations EIP-7702 doivent faire l’objet de contrôles spécifiques.

Un portefeuille d’entreprise pourrait, par exemple, interdire par défaut toute délégation vers un contrat non approuvé.

Les modifications des autorisations de signature devraient nécessiter une validation distincte de celle utilisée pour les retraits ordinaires.

Autrement dit, un service capable de préparer un paiement ne devrait pas pouvoir modifier librement les règles qui déterminent qui a le droit d’autoriser ce paiement.

C’est une séparation fondamentale.

7. Encadrer les agents d’intelligence artificielle

L’utilisation présumée d’un outil d’IA interne dans l’attaque de Binance ouvre un nouveau chantier de cybersécurité.

Les assistants de programmation modernes peuvent accéder à des fichiers, interroger des dépôts de code et parfois lancer des commandes ou utiliser des services externes.

Leurs capacités sont utiles aux développeurs. Elles peuvent aussi amplifier les conséquences d’une compromission.

Une organisation doit donc éviter de donner à ses agents d’IA des permissions permanentes et étendues.

L’agent ne devrait accéder qu’aux ressources nécessaires à la tâche en cours.

L’exécution de commandes sensibles, l’accès aux secrets et les opérations de déploiement doivent être soumis à des contrôles supplémentaires.

Une approbation humaine peut être utile, à condition qu’elle soit réellement indépendante et qu’elle permette à la personne de comprendre ce qu’elle autorise.

Les instructions contenues dans des fichiers externes, des dépôts de code ou des documents consultés par l’IA doivent également être traitées comme des données non fiables.

C’est une protection contre les injections de prompt décrites par l’OWASP, dans lesquelles un contenu malveillant tente de pousser un assistant à agir contre les intentions de son utilisateur. Cela ne signifie pas qu’une injection de prompt a été démontrée dans l’incident Binance : il s’agit ici d’une recommandation générale de défense.

Enfin, les actions des agents doivent être enregistrées et surveillées. Un agent qui commence à consulter des secrets inhabituels, à explorer des ressources sans rapport avec sa mission ou à préparer des déploiements sensibles doit déclencher une alerte.

L’IA ne doit jamais devenir un moyen de contourner les règles de sécurité applicables aux utilisateurs humains.

8. Préparer un arrêt d’urgence réellement efficace

L’affaire Binance souligne une difficulté supplémentaire : suspendre les retraits sur une plateforme ne suffit pas nécessairement à neutraliser toutes les autorisations déjà présentes sur la blockchain.

Les entreprises doivent prévoir des procédures d’urgence adaptées à chaque type de portefeuille.

Pour Ethereum, cela implique notamment de savoir détecter et révoquer rapidement les délégations EIP-7702 suspectes, lorsque la configuration du compte permet cette révocation.

Les équipes doivent également disposer de moyens pour isoler les services compromis, révoquer les identifiants, suspendre les déploiements et empêcher la création de nouvelles transactions.

Ces procédures ne devraient pas être improvisées pendant une attaque.

Des exercices réguliers peuvent simuler la compromission d’un ingénieur, le vol d’un jeton de déploiement ou la prise de contrôle d’un service de signature.

L’objectif est de mesurer combien de temps l’organisation met à détecter, comprendre et contenir l’incident.

Pour une plateforme qui déplace des milliards de dollars, quelques minutes peuvent représenter des pertes considérables.

9. Détecter les attaques avant les premiers transferts

L’un des aspects les plus préoccupants de cette affaire reste la durée de préparation de l’opération.

Entre la première compromission rapportée en juin et le vol du 29 octobre, plusieurs mois se sont écoulés.

Une surveillance efficace ne doit donc pas se limiter aux transactions financières.

Elle doit également repérer les comportements inhabituels sur les ordinateurs des ingénieurs, les tentatives d’accès à des systèmes sensibles et les changements de permissions.

Les journaux de sécurité peuvent révéler des connexions à des heures inhabituelles, des déploiements inattendus ou l’utilisation d’identifiants depuis des environnements non autorisés.

L’analyse comportementale, éventuellement assistée par l’IA, peut aider à identifier ces anomalies.

Mais elle doit s’accompagner de procédures humaines de vérification et de réaction.

Binance annonce justement vouloir renforcer ses capacités de détection assistée par l’IA, travailler avec des experts indépendants et développer de nouvelles initiatives de recherche en sécurité. Ces mesures restent des engagements annoncés par l’entreprise, dont l’efficacité devra être évaluée.

10. Quelles précautions pour les utilisateurs de Binance ?

Les clients ordinaires ne peuvent pas empêcher directement une attaque contre l’infrastructure interne d’une plateforme. Ils peuvent néanmoins réduire leur exposition.

L’authentification à deux facteurs, de préférence avec une clé de sécurité physique ou une passkey, reste importante pour protéger leur propre compte.

Il est également recommandé d’utiliser un mot de passe unique, d’activer les alertes de connexion et de vérifier régulièrement les appareils autorisés.

Pour les montants importants destinés à être conservés longtemps, un portefeuille matériel personnel peut réduire la dépendance à la sécurité d’une plateforme centralisée. Cette solution exige cependant une protection rigoureuse de la phrase de récupération et comporte ses propres risques.

Il faut enfin se méfier des messages prétendant aider les victimes d’un piratage. Après un incident médiatisé, de faux services d’assistance, comme dans des affaires liées à Coinbase, peuvent tenter de voler des identifiants ou des phrases de récupération.

Aucun support légitime ne devrait demander à un utilisateur de communiquer sa phrase secrète.

Ce que Binance doit encore démontrer

Le piratage du 29 octobre n’est pas seulement une affaire de malware, d’IA ou de faux recrutement. Il révèle les risques d’une architecture dans laquelle la compromission de plusieurs outils de développement peut finir par affecter les mécanismes qui protègent les actifs financiers.

Le recours à plusieurs ingénieurs, à des autorisations cryptographiques distribuées et à des outils de sécurité n’a pas empêché l’opération.

Cela ne rend pas ces protections inutiles. Leur efficacité dépend de leur indépendance. Si plusieurs dispositifs de sécurité peuvent être manipulés à partir d’une même chaîne de compromission, leur accumulation ne garantit pas une véritable séparation des risques.

La priorité pour Binance est désormais de documenter précisément les permissions détournées, les composants compromis, les mécanismes de signature exploités et les contrôles qui n’ont pas fonctionné comme prévu.

La plateforme affirme avoir largement reconstitué les actifs affectés. C’est une réponse financière importante pour les utilisateurs. Elle ne constitue pas, à elle seule, la preuve que les vulnérabilités ayant permis l’attaque ont été éliminées.

Aucune entreprise ne peut garantir qu’elle ne subira plus jamais d’intrusion. En revanche, elle peut concevoir ses systèmes de façon qu’un ordinateur infecté, un faux entretien d’embauche ou un jeton dérobé ne suffise pas à compromettre des milliards de dollars.

C’est sur cette capacité de confinement, davantage que sur ses promesses de remboursement, que la sécurité future de Binance devra être jugée.

Les faits relatifs à l’intrusion reposent notamment sur les déclarations de Binance rapportées lors de son briefing et sur les analyses citées. Les recommandations relèvent d’une analyse de défense ; leur mise en œuvre effective par Binance n’a pas été auditée par BrefCrypto.