Hack Binance : comment 6,3 milliards $ sont partis sans qu’aucune clé privée ne soit volée

!Le plus gros hack de l’histoire a commencé sur un laptop

En bref. Le 29 octobre 2026, environ 6,3 milliards de dollars ont quitté les portefeuilles de Binance : le plus gros vol de l’histoire des cryptomonnaies, plus de quatre fois le précédent record (Bybit, 1,5 milliard $ en février 2025). Selon l’enquête préliminaire de Binance, tout serait parti du laptop compromis d’un ingénieur DevOps. Aucune clé privée n’aurait fuité : c’est le système qui utilise les clés qui a été détourné. Voici la chaîne d’attaque, étape par étape, et ce qu’elle enseigne à toute entreprise qui exploite une infrastructure cloud.

Article mis à jour le 30 octobre 2026. L’enquête est en cours : Binance n’a pas encore publié son post-mortem technique. Les chiffres et certains détails peuvent évoluer.

Ce qui s’est passé

Le 29 octobre au soir (heure UTC), des fonds massifs sortent des « hot wallets » de Binance, ces portefeuilles connectés qui servent à traiter les retraits des clients au quotidien. Binance suspend temporairement les retraits sur plusieurs réseaux, annonce un impact d’environ 6,3 milliards de dollars et indique que les pertes seront couvertes par son fonds d’urgence SAFU et par ses fonds propres. Les fonds des clients ne sont pas touchés, selon l’entreprise.

Dans les heures qui suivent, une partie du butin est bloquée : Binance évoque environ 3 milliards de dollars gelés. Tether a gelé plus de 1,56 milliard d’USDT, Circle plus de 800 millions d’USDC, et le Security Council d’Arbitrum a placé environ 74,6 millions d’ARB et 8 425 ETH dans un portefeuille restreint.

La société d’analyse TRM Labs attribue l’attaque, « avec un haut niveau de confiance », au groupe nord-coréen TraderTraitor. Cette attribution n’est pas confirmée officiellement.

La chaîne d’attaque en 4 maillons

Ce qui rend ce hack instructif, ce n’est pas la crypto. C’est la manière dont une confiance accordée à un poste de travail s’est propagée jusqu’à la signature de transactions.

1. Point d’entrée : un poste DevOps

Binance l’a écrit lui-même : son enquête préliminaire indique que l’incident « may involve a compromised DevOps engineer’s laptop ». La manière dont ce poste a été compromis n’est pas encore publique, et Binance n’a mis en cause aucun employé.

Un poste DevOps n’est pas un ordinateur comme les autres. Il contient souvent des accès au cloud, des tokens de pipelines CI/CD, des configurations Kubernetes, des sessions ouvertes vers la production. Le compromettre, c’est souvent compromettre tout ce que son propriétaire peut toucher.

2. Mouvement latéral : un service container interne

Depuis ce poste, l’attaquant a pu atteindre un service container interne, autrement dit un service applicatif qui tourne dans l’infrastructure de Binance. Ce service avait une capacité critique : soumettre des transactions de retrait.

3. Les retraits sont soumis… et signés

C’est le cœur de l’affaire. Binance affirme n’avoir trouvé aucune preuve de fuite de clé privée. Autrement dit, les clés étaient toujours à l’abri, mais le système chargé de signer avec ces clés a accepté des demandes qui n’auraient jamais dû passer. TRM Labs estime que l’attaquant a très probablement obtenu la capacité de faire signer au système de Binance les transactions de son choix, sur plusieurs blockchains.

À noter : la société de sécurité Blockaid a d’abord évoqué une « clé volée ». À ce stade, la version de Binance (pas de fuite de clé) et celle de TRM (signature détournée) convergent.

4. Les fonds partent sur une dizaine de blockchains

Ethereum, Bitcoin, Tron, Arbitrum, Avalanche… TRM recense des sorties sur dix blockchains, pour environ 6,36 milliards de dollars aux prix du moment des transferts.

Le coup EIP-7702, expliqué simplement

Sur Ethereum, l’attaquant a utilisé un mécanisme récent : EIP-7702.

Historiquement, un portefeuille Ethereum « classique » (un EOA) ne peut que signer et envoyer des transactions. EIP-7702 lui permet de déléguer son exécution à du code de smart contract, via une autorisation signée. C’est utile pour des fonctionnalités avancées (paiement des frais par un tiers, transactions groupées…), mais cela signifie aussi qu’une seule signature peut transformer un portefeuille en programme.

!50 autorisations EIP-7702 envoyées, une seule a suffi

Selon l’analyse de Blockaid rapportée par crypto.news :

  • l’attaquant avait financé une adresse d’opération via Tornado Cash et déployé un contrat malveillant quelques heures avant l’attaque ;
  • à 20:20:59 UTC, il envoie une transaction contenant 50 autorisations EIP-7702 visant le hot wallet « Binance 14 » ;
  • ces autorisations couvrent 50 nonces consécutifs (de 18 914 775 à 18 914 824) : chaque autorisation n’est valide que pour le nonce courant du compte, et l’attaquant ne pouvait pas savoir lequel serait actif au moment de l’exécution ;
  • une seule correspond : le portefeuille délègue alors son exécution à un contrat non vérifié, dont la fonction sweep() transfère l’ETH et les tokens ERC-20 vers l’attaquant (en gardant 1 ETH pour les frais) ;
  • vers 20:24 UTC, environ 2,5 milliards de dollars sont sortis de Binance 14, dont 167 464 ETH et plus de 1,6 milliard d’USDT. D’autres portefeuilles (dont Binance 16) sont également touchés.

Tant que la délégation restait active, le portefeuille continuait d’exécuter le code de l’attaquant : les dépôts arrivant ensuite étaient exposés. Binance a depuis révoqué l’autorisation.

Point important : EIP-7702 n’est pas la cause racine. C’est un élément du chemin d’exécution. La cause, c’est qu’un système capable de signer a accepté de signer ces autorisations.

Ce qu’on ne sait pas encore

  • Comment le laptop a été compromis (phishing, malware, accès volé ?).
  • Comment l’attaquant est passé du container à des signatures valides sur plusieurs chaînes.
  • Pourquoi des contrôles de politique de signature n’ont pas bloqué 50 autorisations EIP-7702 inattendues en une seule transaction.

Binance a annoncé un post-mortem technique détaillé à l’issue de l’enquête. Nous mettrons cet article à jour.

La vraie leçon : la confiance se propage

Le réflexe face à ce type d’incident est de penser « clés », « coffres », « chiffrement ». Ici, la clé était protégée. Ce qui a cédé, c’est la chaîne de confiance autour de la clé :

poste DevOps → accès réseau interne → service container → service de signature → transaction valide

Chaque maillon faisait confiance au précédent. Tout ce qui peut toucher la production hérite de la confiance accordée à la production. C’est vrai chez Binance, et c’est vrai dans n’importe quelle entreprise qui a un cloud, une CI/CD ou un ERP.

5 garde-fous techniques qui auraient changé l’issue

Les trois premiers sont recommandés par TRM Labs. Les deux derniers sont des pratiques que nous appliquons dans nos projets.

!5 garde-fous techniques

1. Un policy engine devant la signature

Le service de signature ne doit pas signer « tout ce qu’on lui demande ». Il applique des règles : destinataires autorisés, montants maximums, types d’opérations permis. TRM le dit clairement : les politiques de signature devraient rejeter les autorisations EIP-7702 qui ne sont pas attendues. Une transaction contenant 50 autorisations de délégation sur un hot wallet n’a aucune raison légitime d’exister.

2. Une signature cloisonnée

Séparer l’infrastructure de signature par blockchain et par niveau de portefeuille (hot, warm, cold). Un composant compromis ne doit pas pouvoir signer partout à la fois.

3. Le monitoring des délégations

Surveiller en continu les portefeuilles de trésorerie : une délégation EIP-7702 sur un hot wallet doit déclencher une alerte immédiate, et idéalement une révocation automatique. Ici, quelques minutes séparaient l’autorisation du vidage.

4. Le poste DevOps traité comme un actif critique

Pas d’accès permanent à la production depuis un laptop. Des accès éphémères (just-in-time), approuvés, limités dans le temps et journalisés. Des secrets qui ne vivent pas sur les postes, une authentification forte matérielle (clés FIDO2), et un poste durci et supervisé.

5. La validation multi-personnes

Au-delà d’un seuil, deux humains valident, sur un canal indépendant du système qui demande la transaction. Le principe des « quatre yeux » ralentit un peu les opérations exceptionnelles. Il bloque surtout les attaques automatisées.

Et dans votre entreprise ?

Vous n’avez peut-être pas de hot wallet. Mais vous avez l’équivalent :

  • votre console cloud (AWS, Azure, GCP) ;
  • vos pipelines CI/CD, qui déploient en production avec des tokens puissants ;
  • votre ERP et vos accès bancaires, qui déclenchent des paiements.

La même chaîne existe souvent : un laptop d’admin → des tokens CI/CD ou cloud → la production. Un exercice de 30 minutes à faire cette semaine :

  1. Lister qui peut toucher la production aujourd’hui, et depuis quel poste.
  2. Repérer les tokens et secrets longue durée (clés d’API, tokens CI/CD, clés cloud) et les remplacer par des accès à durée courte.
  3. Vérifier que les opérations sensibles (déploiement en prod, paiement, export de données) déclenchent une alerte et, au-delà d’un seuil, une double validation.
  4. Sortir les secrets des laptops : coffre de secrets, identités de workload, rotation automatique.
  5. Imposer la MFA matérielle sur les comptes à privilèges.

Questions fréquentes

Les clients de Binance ont-ils perdu de l’argent ? Selon Binance, non : les pertes sont couvertes par le fonds SAFU et les fonds propres de l’entreprise.

EIP-7702 est-il dangereux ? Pas en soi. C’est une fonctionnalité légitime d’Ethereum. Le danger vient d’un système qui accepte de signer des autorisations de délégation sans contrôle. Comme toute fonctionnalité puissante, elle doit être encadrée par des politiques de signature.

Qui est derrière l’attaque ? TRM Labs l’attribue au groupe nord-coréen TraderTraitor avec un haut niveau de confiance. Il n’y a pas de confirmation officielle à ce jour.

Ce type d’attaque concerne-t-il uniquement la crypto ? Non. Le schéma (compromission d’un poste à privilèges, mouvement latéral, abus d’un service de confiance) est celui de nombreuses attaques contre des infrastructures cloud classiques.

Conclusion

Le hack de Binance n’est pas une histoire de cryptographie cassée. C’est une histoire d’architecture de confiance : un poste, un container et un service de signature qui se faisaient confiance les uns aux autres. La sécurité d’un système se mesure à son maillon le plus exposé, et ce maillon est souvent un poste de travail.

Chez NeoLogix, nous concevons et opérons des plateformes cloud et DevOps avec ces principes dès le départ : accès éphémères, secrets centralisés, politiques de déploiement et de signature, supervision. Si vous voulez faire le point sur la chaîne d’accès à votre production, écrivez-nous à contact@neologix.ma.

Sources