Binance : 6,34 milliards de dollars touchés sans fuite de clé privée confirmée

Attaque : 29 octobre 2026. Rapport initial Binance : 3 novembre. Analyse rédigée le 4 novembre. Binance chiffre les actifs concernés à environ 6,34 milliards de dollars, dont 2,85 milliards gelés ou interceptés à la date de son premier rapport. Ce sont des valeurs provisoires, sensibles au prix des actifs et à la réconciliation des mouvements. Le mécanisme annoncé est plus important que le montant spectaculaire : l’attaquant a obtenu un accès non autorisé à un service interne de signature de portefeuilles. Les transactions pouvaient ainsi porter une signature valide sans qu’une clé privée unique ait été publiée ou copiée.

Le rapport Binance reste une première enquête, avec une revue indépendante prévue. Nous distinguons ci-dessous les faits décrits par l’entreprise, les propriétés vérifiables du protocole Ethereum et les détails encore non publics.

De l’ordinateur d’un ingénieur au service de signature

Binance décrit une préparation en plusieurs phases. En septembre, un ingénieur logiciel a suivi un faux processus de recrutement. Lors d’un entretien, on lui a fait télécharger sur son poste professionnel un dépôt présenté comme un exercice ; son installation a exécuté du code malveillant. Le rapport décrit le remplacement d’un composant pyenv légitime par un fichier modifié. Le 20 octobre, les attaquants ont utilisé ce poste et un outil IA interne comme relais vers d’autres ingénieurs de l’équipe wallet. Ils ont identifié un jeton de déploiement de conteneurs sur le poste d’un ingénieur DevOps. Le 29 octobre, ils se sont connectés au poste d’un troisième ingénieur, ont utilisé ce jeton pour déployer un conteneur, puis ont déclenché un script malveillant. (Chronologie Binance)

Une tentative antérieure avait déjà exposé l’équipe : en juin, un ingénieur wallet avait téléchargé un installateur Homebrew altéré en cherchant un outil de codage IA. Binance dit avoir détecté l’anomalie, remplacé l’appareil et tourné les identifiants, mais estime que l’attaquant avait appris le rôle de l’ingénieur et de ses collègues. Ce point ne signifie pas que le poste de juin était encore compromis en octobre ; il montre une phase de reconnaissance différente de la chaîne de septembre.

La frontière franchie en octobre était une frontière d’autorisation métier. Un service de signature doit accepter certaines demandes émises par les systèmes de retrait, selon des règles sur le destinataire, le montant, le réseau et le contexte. Selon Binance, l’accès obtenu a permis de soumettre des transactions hors du processus normal de retrait. Le rapport public ne donne ni le code de la politique de signature ni la requête exacte envoyée au service ; on ne peut donc pas attribuer l’échec à une ligne de validation précise.

Ce que prouve une signature cryptographique

Sur une blockchain, un nœud vérifie qu’une transaction est signée selon les règles du compte. Il ne sait pas si cette transaction a été approuvée par le moteur antifraude de Binance. Si un service de signature valide une demande qui contourne le flux métier, la chaîne voit une transaction authentique, même si l’entreprise ne l’a jamais voulue. C’est pourquoi la défense ne se résume pas à « protéger la clé » : il faut lier la signature à une politique indépendante du système qui soumet la demande.

Binance rapporte des sorties de XRP, SOL, OP et BTC avant de détailler l’usage d’EIP-7702 sur Ethereum. Des portefeuilles chauds ont envoyé, entre 20 h 05 et 20 h 09 UTC, 233,46 millions de XRP ; d’autres sorties comprenaient environ 970 500 SOL, 44,2 millions d’OP et 18 270 BTC. L’alerte interne sur les gros transferts a déclenché la réponse. Ces montants sont ceux du rapport initial, pas un inventaire définitif de chaque actif.

EIP-7702 : pourquoi couper les retraits ne coupait pas l’attaque

EIP-7702 permet à un compte Ethereum ordinaire de signer une autorisation indiquant une adresse de contrat. La transaction de type 0x04 transporte un tuple contenant notamment chain_id, adresse du code et nonce. Le protocole vérifie la signature, puis inscrit sur le compte un indicateur de délégation 0xef0100 || adresse. Les appels futurs exécutent le code pointé dans le contexte du compte autorisant. La délégation persiste après la transaction et ne disparaît pas parce qu’un service hors chaîne s’arrête.

Binance dit que les attaquants ont fait signer des autorisations vers un contrat qu’ils contrôlaient, après une série de 50 transactions liées aux nonces et à la délégation. L’entreprise parle de droits d’exécution partiels. Au niveau du protocole, EIP-7702 n’impose pas lui-même une limite de dépense : d’éventuelles restrictions viennent du code délégué. Sans ce code et les transactions analysées en détail, nous ne pouvons pas préciser quelles permissions effectives l’attaquant avait. Le fait défensif majeur est que la capacité on-chain survivait à la suspension du système de retraits. Binance a dû signer une nouvelle autorisation vers l’adresse zéro pour effacer la délégation ; elle situe cette opération à 00 h 10 UTC le 30 octobre.

Le portefeuille était géré en MPC, sans clé privée unique immédiatement utilisable pour produire cette révocation. Le MPC protège le secret en répartissant les parts de signature, mais sa procédure de réponse peut demander une coordination plus longue quand une autorisation malveillante a déjà été inscrite sur la chaîne. Binance indique qu’un transfert de 2 961,9 ETH, diffusé auparavant, s’est finalisé à 23 h 56 UTC malgré les mesures en cours. La fin des retraits applicatifs et la fin des transactions pendantes sont deux instants différents.

Comment on aurait pu détecter plus tôt

Chaque maillon offre une vérification distincte : dépôt téléchargé pendant un entretien, remplacement d’un binaire local, appel de l’outil IA interne depuis un poste compromis, usage inhabituel d’un jeton de déploiement, nouveau conteneur dans l’environnement wallet, puis demande de signature sans dossier de retrait correspondant. La détection doit relier une signature à son origine métier et alerter si aucune opération autorisée ne justifie le destinataire, la chaîne ou le montant. Sur Ethereum, surveiller aussi les autorisations EIP-7702 et le code de délégation associé aux adresses de garde ; un simple compteur de retraits ne voit pas toute leur portée.

Après un tel incident, la révocation des jetons d’ingénieurs et la reconstruction des services répondent au compromis hors chaîne. Il faut en parallèle examiner l’état sur chaque chaîne, les autorisations déjà persistantes et les transactions en attente. Le rapport Binance dit avoir reconstruit les systèmes wallet et l’outil IA touchés, remplacé des appareils et renforcé les politiques de signature. L’attribution à la Corée du Nord est rapportée par Binance à partir d’une communication du FBI ; elle ne change pas la mécanique technique établie dans son premier rapport.

La distinction entre secret et autorisation apparaît aussi dans l’incident eMudhra, où les clés elles-mêmes étaient faibles. Chez Binance, le rapport décrit un accès au service qui les utilise. Pour examiner les jetons de déploiement et la chaîne de confiance logicielle, comparer avec la release LiteLLM compromise, sans en déduire une cause commune.

Sources principales : rapport initial Binance, spécification EIP-7702.