Le 29 octobre 2026, Binance, l'une des principales plateformes d'échange de cryptomonnaies, a été victime d'une cyberattaque d'une ampleur exceptionnelle. Selon TRM Labs, près de 6,36 milliards de dollars d'actifs sont dérobés sur dix blockchains, dont l'essentiel en une vingtaine de minutes. C'est le plus important vol de cryptomonnaies jamais enregistré, loin devant les 1,5 milliard de dollars dérobés à la plateforme Bybit en février 2025.

2 jours plus tard, le FBI a attribué l'opération au groupe TraderTraitor, déjà impliqué dans plusieurs attaques majeures contre des plateformes de cryptomonnaies.

Au-delà du montant, cet incident pose une question fondamentale : Comment une infrastructure peut-elle exécuter des opérations techniquement autorisées, alors même qu'elles sont initiées par un attaquant ?

Une attaque ciblant les mécanismes d'autorisation

D'après les premières analyses de TRM Labs, les attaquants auraient compromis les mécanismes permettant à Binance d'autoriser les transactions de ses hot wallets, des portefeuilles connectés à Internet utilisés notamment pour traiter les retraits des utilisateurs.

L'attaque a été soigneusement préparée. Des mouvements de faible montant et plusieurs opérations préliminaires ont été observés avant le déclenchement de l'attaque principale, le 29 octobre à 20h05 UTC.

Sur Ethereum (une crypto), les attaquants ont exploité EIP-7702, une fonctionnalité qui permet à un portefeuille de déléguer certaines opérations à un programme au moyen d'une autorisation cryptographique. Selon TRM Labs, 50 autorisations préalablement signées auraient permis à un programme contrôlé par les attaquants d'exécuter des transferts depuis un portefeuille de Binance. Sur les autres blockchains, les transferts frauduleux ont été réalisés au moyen de transactions signées de manière classique.

Cette simultanéité conduit TRM Labs à privilégier l'hypothèse d'une compromission de l'infrastructure de signature des transactions.

La cause initiale reste à confirmer. Binance a d'abord évoqué la compromission possible de l'ordinateur d'un ingénieur DevOps, avant d'indiquer avoir découvert d'autres points de compromission. La plateforme précise ne pas avoir identifié, à ce stade, de preuve d'une fuite des clés privées de ses portefeuilles.

Les attaquants auraient donc détourné les mécanismes d'autorisation existants, plutôt que voler les clés elles-mêmes.

Une transaction autorisée n'est pas nécessairement légitime

C'est probablement l'enseignement le plus important de cette attaque.

Une signature cryptographique prouve qu'une transaction dispose de l'autorisation attendue par le système. Elle ne prouve pas que cette opération correspond à la volonté du propriétaire des fonds. Si un attaquant compromet le processus qui produit cette signature, une transaction frauduleuse devient parfaitement valide sur le plan technique.

Autrement dit, un système peut fonctionner conformément à ses règles tout en exécutant une opération malveillante.

Cette problématique dépasse largement les cryptomonnaies. Un compte administrateur compromis exécute des commandes parfaitement autorisées, et ça nous l'avons vu dans plusieurs dossiers d'expertise. Un système de paiement accepte un virement initié depuis un compte disposant des privilèges nécessaires. Un outil de déploiement automatisé applique une modification malveillante dès lors qu'elle provient d'un environnement jugé fiable.

Dans chacun de ces cas, l'authentification ne fait pas défaut. C'est la confiance accordée à un utilisateur, un service ou un processus qui est détournée.

Sécuriser les accès ne suffit donc pas. Il faut aussi contrôler les opérations réalisées après authentification, surtout lorsqu'elles touchent à des privilèges élevés ou à des ressources critiques comme :

• La séparation des responsabilités ;
• La limitation des capacités d'action des comptes privilégiés (plafonds, fenêtres temporelles) ;
• Les validations indépendantes pour les opérations sensibles ;
• La détection des comportements inhabituels.

Un compte autorisé à effectuer des transferts doit-il pouvoir déplacer plusieurs milliards de dollars en quelques minutes ? Un même processus doit-il pouvoir agir sur plusieurs infrastructures sans contrôle(s) supplémentaire(s) ?

Ces questions ne permettent pas de conclure à l'absence de protections chez Binance. Elles rappellent néanmoins qu'il faut concevoir (security by design) des mécanismes capables de limiter les conséquences d'une compromission, même lorsque les actions semblent techniquement légitimes.

Après l'attaque, une course contre la montre

La rapidité du vol est un premier défi. Empêcher la dispersion des fonds en est un second.

Dans une analyse publiée le 2 novembre, Elliptic recense plus de 40 000 transactions impliquant environ 12 000 portefeuilles répartis sur 11 blockchains, en moins de quatre jours. Ces mouvements, largement automatisés, fractionnent les actifs, les convertissent et les font passer d'une blockchain à l'autre pour brouiller leur traçabilité.

Les attaquants ont notamment cherché à convertir rapidement certains stablecoins. Contrairement au Bitcoin ou à l'Ether, ceux-ci peuvent être bloqués directement par leurs émetteurs. Cette particularité a permis à Tether et Circle, entre autres, de contribuer au gel d'environ 3 milliards de dollars. Gelés ne veut cependant pas dire récupérés : leur immobilisation ne garantit pas leur restitution.

De son côté, Binance a suspendu les retraits avant de les rouvrir progressivement à partir du 1er novembre. La plateforme s'est engagée à couvrir les pertes sur ses propres ressources et a publié une nouvelle preuve de réserves. Ces mesures sensées restaurer la confiance financière, ne disent rien à elles seules, de la sécurité des mécanismes d'autorisation qui ont été détournés et de ce compte faire la plateforme pour éviter que cela se reproduise.

Que faut-il retenir ?

L'attaque contre Binance attribuée à des hackers nord-coréens illustre une réalité qui dépasse largement les plateformes de cryptomonnaies : La confiance accordée à un système ne peut pas reposer uniquement sur sa capacité à authentifier et autoriser des opérations. Elle doit aussi s'appuyer sur des contrôles capables d'en vérifier la légitimité et d'en limiter les conséquences lorsqu'elles deviennent anormales.