Retour

2026/11/03

Comment une seule signature a continué de vider le hot wallet de Binance : la délégation EIP-7702 derrière l’attaque

50 autorisations EIP-7702 pré-signées, une seule valide, et une délégation qui a survécu au wallet vide. Le mécanisme et ce qu’il faut surveiller.

Dans notre premier article sur l’attaque contre Binance, nous avons vu comment l’attaque aurait commencé : un ordinateur portable DevOps compromis, et des attaquants qui ont atteint les systèmes chargés d’approuver les actions sensibles. L’analyse on-chain de la société de sécurité Blockaid a depuis montré comment s’est déroulée la phase finale sur Ethereum. Elle a utilisé EIP-7702, une fonctionnalité ajoutée à Ethereum en mai 2025, et elle met en lumière un risque que de nombreux opérateurs de hot wallets n’ont pas encore anticipé.

En bref : une seule autorisation signée a transformé le plus grand hot wallet Ethereum de Binance en un compte que l’attaquant pouvait contrôler. Ce contrôle n’a pas pris fin lorsque le wallet a été vidé, et il n’aurait pas non plus pris fin avec une rotation de clé.

Points clés

  • L’attaquant a regroupé 50 autorisations EIP-7702 pré-signées, couvrant 50 nonces consécutifs, dans une seule transaction ; une seule correspondait, et elle a confié l’exécution du wallet au contrat de l’attaquant.
  • Une délégation EIP-7702 reste en place jusqu’à ce que le compte la remplace ou l’efface. Les dépôts arrivés après le premier siphonnage, plus de 200 millions de dollars à un moment donné, ont été pris sans aucune nouvelle signature.
  • Changer la clé privée ne supprime pas une délégation, car celle-ci est liée à l’adresse. Seule une révocation explicite l’efface.
  • La manière dont l’attaquant a obtenu 50 signatures valides reste inconnue. Binance indique n’avoir trouvé aucune preuve d’une fuite de clé privée.
  • Les opérateurs de hot wallets doivent surveiller l’état des délégations, refuser de signer des autorisations non voulues et intégrer la révocation explicite dans leurs runbooks de réponse aux incidents.

EIP-7702 en quelques mots

EIP-7702 permet à un compte Ethereum ordinaire (un externally owned account, ou EOA) de déléguer son exécution à un smart contract. Le titulaire du compte signe une autorisation qui indique l’adresse d’un contrat, la chaîne et le nonce actuel du compte. Une fois qu’une transaction contenant cette autorisation est traitée, les appels au compte exécutent le code du contrat, comme si le compte était un smart contract wallet. La fonctionnalité existe pour des raisons légitimes, comme le regroupement de transactions ou le paiement des frais pour le compte d’un utilisateur.

Trois points de la spécification sont importants dans cet incident :

  • Les autorisations circulent dans un nouveau type de transaction, le type 4 (0x04), qui peut en contenir une liste. N’importe qui peut soumettre la transaction ; l’autorisation a seulement besoin d’une signature valide du compte.
  • Chaque autorisation n’est valide que si son nonce est égal au nonce actuel du compte. Sinon, cette autorisation est ignorée et la transaction passe à la suivante.
  • La délégation est persistante. Elle reste en place jusqu’à ce que le compte signe une nouvelle autorisation pointant ailleurs, ou une autorisation pointant vers l’adresse zéro, ce qui l’efface.

Comment le wallet Binance 14 a été pris

Le hot wallet d’une plateforme d’échange très active envoie des transactions en permanence, donc son nonce change sans cesse. Un attaquant qui prépare une autorisation signée à l’avance ne peut pas savoir quel nonce sera en vigueur au moment où la transaction sera traitée. Selon l’analyse de Blockaid, l’attaquant a contourné ce problème en signant une plage de valeurs plutôt qu’une seule.

Heure (UTC, 29 octobre)Ce qui s’est passé
15:59L’attaquant déploie un contrat « sweeper ». Il n’est pas vérifié, et seule l’adresse opérateur de l’attaquant peut l’appeler.
20:20:59Une seule transaction de type 4 contient 50 autorisations EIP-7702, toutes signées avec la clé du hot wallet Binance 14, pour 50 nonces consécutifs. Une seule correspond au nonce actuel du wallet, qui est désormais délégué au sweeper.
20:24:23Un seul appel au sweeper sort du wallet environ 167 464 ETH, 1,615 milliard d’USDT et des dizaines d’autres tokens, en laissant 1 ETH pour les frais.
20:41Toujours délégué, le wallet sert à transférer environ 823 millions d’USDC depuis un smart account distinct contrôlé par Binance 14.
21:04 à 23:56Le wallet est vidé quatre fois de plus à mesure que de nouveaux fonds arrivent. Rien qu’à 21:44, plus de 200 millions de dollars de nouveaux dépôts sont pris sans aucune nouvelle signature.
00:10 (30 octobre)La délégation est révoquée, selon la chronologie de Hypernative.

L’étape USDC montre un second effet. Un compte délégué conserve tous les rôles qu’il détient dans d’autres contrats : propriétaire, exécutant, spender autorisé. Quiconque contrôle son exécution peut tous les utiliser.

Pourquoi un wallet vide restait dangereux

Après un vol, on suppose naturellement qu’un wallet vide n’a plus rien à perdre et qu’une nouvelle clé met fin à l’accès de l’attaquant. Avec EIP-7702, ces deux hypothèses sont fausses. La délégation est liée à l’adresse, pas au solde ni à une copie particulière de la clé. Tant qu’elle est en place, tout ce qui est envoyé à l’adresse peut être siphonné par le contrat délégué, sans que l’attaquant ait besoin d’une nouvelle signature.

C’est ce qui s’est passé ici. Des fonds ont continué d’arriver sur Binance 14 après le premier siphonnage, et ils ont été pris à leur tour. Changer la clé n’aurait servi à rien : comme le souligne Blockaid, effacer la délégation exige une nouvelle autorisation du même compte, pointant vers l’adresse zéro. Tant que cette révocation n’est pas traitée, l’adresse doit être considérée comme contrôlée par l’attaquant.

Conseil : En cas d’incident, révoquez d’abord, puis changez les clés et réalimentez. Arrêtez tous les processus automatiques qui envoient des fonds vers l’adresse concernée jusqu’à ce que vous ayez confirmé la disparition de la délégation.

Ce qui reste inexpliqué

Les 50 autorisations portaient toutes des signatures valides de la clé de Binance 14. Il existe deux grandes explications, et les éléments publics ne permettent pas encore de trancher :

  • La clé a fuité, et l’attaquant a signé les autorisations directement.
  • L’infrastructure de signature a été détournée : l’attaquant a amené les propres systèmes de signature de Binance à signer des données de son choix, sans jamais extraire la clé.

Binance a déclaré n’avoir trouvé aucune preuve d’une fuite de la clé privée du wallet, et son enquête se poursuit. Le CEO de Blockaid a indiqué à Cointelegraph que l’activité ressemble davantage à une compromission de l’infrastructure de signature qu’à une fuite de clé, mais il s’agit d’une évaluation externe préliminaire. Tant que Binance n’aura pas publié son post-mortem, nous considérons la question comme ouverte.

Que faire si vous exploitez des hot wallets

1. Surveillez l’état des délégations

Un compte délégué possède du code. Avec EIP-7702, ce code est l’indicateur de délégation 0xef0100 suivi de l’adresse de 20 octets du contrat délégué. Un EOA ordinaire n’a aucun code. Vous pouvez vérifier n’importe quelle adresse avec un appel JSON-RPC standard :

curl -s -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0xYOUR_HOT_WALLET","latest"]}' \
  https://YOUR_RPC_ENDPOINT

Un résultat 0x signifie qu’il n’y a pas de délégation. Un résultat commençant par 0xef0100 signifie que l’adresse est déléguée. Vérifiez cela pour chaque hot wallet à chaque bloc ou à intervalles courts, et déclenchez une alerte immédiate pour tout changement non prévu.

2. Surveillez les transactions de type 4 qui concernent vos adresses

La transaction qui délègue votre wallet ne provient pas forcément de votre wallet. N’importe qui peut la soumettre, du moment qu’elle contient une autorisation valide signée par votre clé. Surveillez les transactions de type 4 dont la liste d’autorisations contient une signature de l’une de vos adresses, et pas seulement les transactions envoyées depuis celles-ci.

3. Tenez un inventaire des délégations

Pour chaque adresse que vous exploitez, indiquez si elle doit être déléguée et, le cas échéant, à quel contrat audité. Toute délégation en dehors de cette liste est un incident. Si vous n’utilisez pas EIP-7702, l’état attendu de chaque hot wallet est simple : aucun code.

4. Refusez les autorisations inattendues au niveau du signataire

Une autorisation EIP-7702 a son propre format de signature : le hash de l’octet 0x05 suivi du chain ID, de l’adresse du contrat et du nonce encodés. Les services de signature et les politiques HSM peuvent reconnaître ce format. Si vous n’utilisez pas de délégations, bloquez entièrement ces données ; si vous en utilisez, n’autorisez que des adresses de contrats connues. Notez aussi qu’une autorisation avec le chain ID 0 est valide sur toutes les chaînes.

5. Intégrez la révocation explicite à votre runbook de réponse aux incidents

Documentez comment révoquer une délégation pour chaque wallet : qui signe l’autorisation vers l’adresse zéro, depuis quel système, et comment vous confirmez qu’elle a pris effet (le code de l’adresse redevient 0x). Prévoyez l’arrêt des transferts entrants vers l’adresse concernée, et exercez-vous à la procédure avant d’en avoir besoin.

Conseil : Le même principe s’applique en dehors de la crypto. Toute autorisation qui survit à l’identifiant qui l’a créée, comme un refresh token OAuth, un rôle cloud délégué ou un token CI/CD à longue durée de vie, nécessite sa propre étape de révocation explicite dans la réponse aux incidents.

Comment LOGIQ peut vous aider

LOGIQ aide les organisations à passer en revue qui et quoi peut agir avec autorité sur leurs serveurs Linux, leurs comptes cloud et leurs pipelines, et à mettre en place une surveillance et des étapes de réponse aux incidents qui couvrent les accès délégués, pas seulement les mots de passe et les clés. Si vous souhaitez un regard extérieur sur vos propres contrôles, lisez notre premier article sur l’attaque mentionné plus haut ou contactez-nous via notre site web.

Sources