En bref. Lors du piratage de Binance fin octobre 2026, l'attaquant a obtenu des signatures valides sans extraire de clé privée : un serveur compromis autorisé à demander des signatures suffisait. Il a notamment utilisé une délégation EIP-7702 qui lui a permis de répéter des transferts sans nouvelle signature. Trail of Bits, cabinet d'audit de sécurité, en tire le 6 novembre quatre contrôles avec leur méthode de vérification. La leçon vaut au-delà des cryptoactifs : un service de signature se sécurise par ce qu'il accepte de signer, pas seulement par la protection de sa clé.
Ce qui s'est passé
D'après la reconstitution publiée par FrenchWeb le 3 novembre 2026, qui s'appuie sur Bloomberg et The Block, les attaquants commencent à vider des portefeuilles de Binance le jeudi 29 octobre, peu après 16 heures à New York. Le 30 octobre, Binance annonce avoir isolé les infrastructures touchées, révoqué les autorisations compromises et suspendu les retraits. La plateforme indique avoir réservé plus de 6,34 milliards de dollars pour couvrir les pertes. Le 31 octobre, le FBI attribue le vol à la Corée du Nord, sous la désignation TraderTraitor. Les retraits reprennent partiellement le 1er novembre.
Trail of Bits résume l'évolution des explications de Binance. La première mise à jour évoquait un ordinateur portable DevOps compromis qui aurait permis d'accéder à un conteneur de service et de soumettre des retraits non autorisés. La deuxième faisait état d'intrusions supplémentaires, sans preuve de fuite des clés privées des portefeuilles. Le rapport du 3 novembre décrit une attaque plus large : ingénierie sociale, détournement d'un outil d'IA interne, identifiants volés et accès non autorisé au service de signature des portefeuilles.
Point central relevé par Trail of Bits : l'attaquant a obtenu des signatures valides. Un serveur compromis qui a le droit de demander des signatures peut détourner une clé protégée sans jamais l'extraire.
Le mécanisme : une délégation qui reste en place
EIP-7702 est une proposition d'amélioration d'Ethereum (Ethereum Improvement Proposal). Elle permet à un portefeuille de signer une instruction permanente, que Trail of Bits résume ainsi : « utilise ce code quand mon compte est appelé ». Ethereum conserve cette instruction jusqu'à ce qu'elle soit modifiée ou effacée avec la clé du portefeuille.
Dans le cas Binance, cette délégation a permis des transferts répétés, y compris des fonds déposés après le premier vol, sans nouvelle signature de Binance. D'autres portefeuilles ont été vidés par des transferts signés ordinaires.
Trail of Bits explique pourquoi les systèmes de surveillance peuvent passer à côté : EIP-7702 place les autorisations de délégation hors des données d'appel habituelles (calldata). Les clés de session, les chemins de récupération, les modules d'autorisation, les modules Safe et les opérations ERC-4337 (le standard d'abstraction de compte) ajoutent autant de chemins d'exécution que les politiques de signature et les outils de surveillance doivent comprendre. Une surveillance qui ne regarde que les transferts et les changements de propriétaire peut ne voir le changement d'autorité qu'au moment où les actifs bougent.
Qui est concerné
Directement : toute organisation qui détient des fonds d'utilisateurs en cryptoactifs, opère des portefeuilles ou un service de signature sur Ethereum.
Par analogie, et c'est une lecture de WeeSec plutôt qu'un propos de Trail of Bits : toute équipe qui expose un service de signature à d'autres systèmes. Signature de code, signature d'artefacts dans une chaîne CI/CD (intégration et déploiement continus), émission de jetons, signature de documents. La question de fond est la même : si un système autorisé à demander une signature est compromis, que peut-il faire signer ?
L'incident ajoute un élément que les équipes DevSecOps connaissent : le point d'entrée cité dans les premières explications est un poste DevOps, et le rapport du 3 novembre mentionne un outil d'IA interne détourné. Les postes et outils internes qui atteignent l'infrastructure de signature font partie de son périmètre de sécurité.
Les quatre contrôles de Trail of Bits
1. Réduire l'accès à l'infrastructure de signature
Documentez chaque service et chaque API qui peut demander une signature, qui peut l'appeler et ce qu'il peut autoriser : transferts, délégation, données arbitraires. Revoyez cet inventaire à chaque évolution des fonctions de portefeuille sur les chaînes supportées. Séparez l'infrastructure de signature des systèmes métier courants, et vérifiez le détail des transactions par un système indépendant.
Vérification proposée par Trail of Bits : pour chaque chemin de compromission identifié, utilisez les accès et identifiants du système compromis pour tenter une action non approuvée. Identifiez le contrôle censé la bloquer et conservez la preuve qu'aucune signature exploitable n'a été produite.
2. Traiter la délégation comme un privilège d'administration
Les services de signature doivent reconnaître les demandes qui modifient l'autorité d'un compte. Trail of Bits recommande de rejeter les autorisations EIP-7702 pour les comptes de conservation détenus par une clé (EOA, externally owned accounts) qui n'ont pas besoin de délégation, et de s'assurer que les API génériques de signature de condensat ne contournent pas cette restriction. Quand la délégation est nécessaire, chaque élément s'approuve séparément : compte, adresse et code du délégué, chaîne, nonce. Les simulations doivent appliquer la délégation proposée et examiner les changements de permissions et d'autorité future, pas seulement les mouvements de soldes immédiats.
Vérification : une demande de délégation sur un compte où elle est désactivée est rejetée par l'interface dédiée comme par l'interface générique. Changer le compte, le délégué, la chaîne ou le nonce exige une nouvelle approbation. Les simulations font apparaître une autorité ajoutée même quand la transaction ne déplace aucun actif.
3. Limiter les dégâts même si la signature est compromise
Même après une délégation, la clé d'origine peut encore transférer des fonds ou changer de délégué. Si elle est compromise, l'attaquant contourne donc les limites imposées par le délégué. Trail of Bits recommande de protéger les actifs par des contrôles de conservation distincts que la clé opérationnelle ne peut pas modifier : limites appliquées de façon indépendante, délais surveillés sur les actions sensibles, autorité de configuration séparée.
Vérification : considérez la clé opérationnelle comme compromise et tentez transferts directs, remplacement du délégué et changements de politique. Confirmez qu'aucun de ces chemins ne contourne les protections, y compris en raccourcissant ou supprimant les délais. Exercez la réponse à incident sur un retrait malveillant : mesurez les délais d'alerte et de confinement, et montrez que le retrait bloqué ne peut pas s'exécuter ensuite.
4. Détecter les changements d'autorité
Associez chaque portefeuille aux actifs et contrats qu'il contrôle, y compris ceux qui ne détiennent pas de fonds. Les alertes doivent identifier les systèmes et privilèges touchés, par exemple une délégation non approuvée sur un compte qui peut mettre à jour des coffres financés.
Vérification : testez plusieurs scénarios de délégation, des combinaisons d'autorisations, l'exécution par module multisignature et les opérations ERC-4337 en échec dans des lots réussis. La surveillance doit reconstituer dans l'ordre les changements d'autorité et les mouvements d'actifs, et distinguer la détection des contrôles qui bloquent l'exécution avant tout mouvement de fonds.
Transposer la méthode à une chaîne CI/CD
Pour une équipe qui signe du code ou des artefacts plutôt que des transactions, les quatre contrôles se traduisent ainsi. Il s'agit de bonnes pratiques, à adapter à votre outillage.
- Inventaire des demandeurs : quels jobs de pipeline, quels comptes de service, quels outils internes (y compris des agents IA) peuvent obtenir une signature ? La liste doit être courte et revue.
- Politique sur le contenu signé : le service de signature vérifie-t-il ce qu'il signe (provenance de l'artefact, branche, pipeline d'origine), ou signe-t-il tout ce qu'on lui présente ?
- Opérations d'autorité à part : l'ajout d'une clé de confiance, d'un signataire ou d'une exception de politique doit suivre un circuit d'approbation distinct de la signature courante.
- Test de compromission : depuis le compte d'un job de build, tentez de faire signer un artefact construit hors du pipeline. Le refus doit être constaté et journalisé.
Trail of Bits conclut sur un point d'organisation : nommez un responsable de cette revue, planifiez-la, et relancez-la à chaque changement de protocole supporté, de portefeuille ou de service de signature.
FAQ
L'attaquant a-t-il volé les clés privées de Binance ?
Selon le résumé de Trail of Bits, la deuxième mise à jour de Binance ne faisait état d'aucune preuve de fuite des clés privées des portefeuilles. L'attaquant a obtenu des signatures valides via un accès non autorisé au service de signature.
Qu'est-ce qu'EIP-7702 ?
Une proposition d'amélioration d'Ethereum qui permet à un portefeuille de signer une instruction permanente de délégation : un code désigné s'exécute quand le compte est appelé. L'instruction reste active jusqu'à sa modification ou son effacement avec la clé du portefeuille.
Pourquoi la surveillance des transferts ne suffit-elle pas ?
Parce qu'une délégation change l'autorité sur un compte sans forcément déplacer d'actifs. Une surveillance limitée aux transferts et aux changements de propriétaire ne voit le problème qu'au moment où les fonds partent.
Ces recommandations concernent-elles la signature de code ?
Trail of Bits les formule pour les portefeuilles et services de signature de cryptoactifs. Le principe (contrôler qui peut demander une signature et ce qui peut être signé) se transpose à la signature de code et d'artefacts, avec des contrôles propres à chaque outil.
Sources
- Trail of Bits, After Binance, check what your signing systems can approve, 6 novembre 2026 : https://blog.trailofbits.com/2026/11/06/after-binance-check-what-your-signing-systems-can-approve
- FrenchWeb, Binance : un piratage à 6,3 milliards de dollars, une mobilisation inédite, 3 novembre 2026 : https://www.frenchweb.fr/binance-un-piratage-a-6-3-milliards-de-dollars-une-mobilisation-inedite/900000014
Pour revoir les accès à vos services de signature et à votre chaîne CI/CD, WeeSec accompagne les équipes sur le DevSecOps.