Zurück

2026/11/03

Wie eine einzige Signatur die Hot Wallet von Binance immer wieder leerte: die EIP-7702-Delegation hinter dem Angriff

50 vorab signierte EIP-7702-Autorisierungen, ein Treffer und eine Delegation, die die leere Wallet überdauerte. Wie es funktionierte und was zu überwachen ist.

In unserem ersten Artikel zum Binance-Angriff haben wir beschrieben, wie der Angriff Berichten zufolge begann: mit einem kompromittierten DevOps-Laptop und Angreifern, die bis zu den Systemen vordrangen, die sensible Aktionen freigeben. Eine On-Chain-Analyse des Sicherheitsunternehmens Blockaid hat inzwischen gezeigt, wie die letzte Phase auf Ethereum ablief. Sie nutzte EIP-7702, eine Funktion, die im Mai 2025 zu Ethereum hinzugefügt wurde, und sie zeigt ein Risiko, das viele Betreiber von Hot Wallets noch nicht eingeplant haben.

Kurz gesagt: Eine einzige signierte Autorisierung machte die größte Ethereum-Hot-Wallet von Binance zu einem Konto, das der Angreifer steuern konnte. Diese Kontrolle endete nicht, als die Wallet leer war, und sie hätte auch mit einer Schlüsselrotation nicht geendet.

Das Wichtigste in Kürze

  • Der Angreifer packte 50 vorab signierte EIP-7702-Autorisierungen für 50 aufeinanderfolgende Nonces in eine einzige Transaktion; genau eine passte und übergab die Ausführung der Wallet an den Vertrag des Angreifers.
  • Eine EIP-7702-Delegation bleibt bestehen, bis das Konto sie ersetzt oder löscht. Einzahlungen, die nach dem ersten Abräumen eingingen, zeitweise mehr als 200 Millionen US-Dollar, wurden ohne neue Signatur abgezogen.
  • Das Rotieren des privaten Schlüssels entfernt keine Delegation, denn sie gehört zur Adresse. Nur ein ausdrücklicher Widerruf löscht sie.
  • Wie der Angreifer an 50 gültige Signaturen kam, ist weiterhin offen. Binance gibt an, keine Hinweise auf ein Leck des privaten Schlüssels gefunden zu haben.
  • Betreiber von Hot Wallets sollten den Delegationsstatus überwachen, die Signatur nicht beabsichtigter Autorisierungen verweigern und den ausdrücklichen Widerruf in ihre Runbooks für die Incident Response aufnehmen.

EIP-7702 in Kürze

EIP-7702 erlaubt es einem gewöhnlichen Ethereum-Konto (einem Externally Owned Account, kurz EOA), seine Ausführung an einen Smart Contract zu delegieren. Der Kontoinhaber signiert eine Autorisierung, die eine Vertragsadresse, die Chain und den aktuellen Nonce des Kontos enthält. Sobald eine Transaktion mit dieser Autorisierung verarbeitet ist, führen Aufrufe des Kontos den Code des Vertrags aus, als wäre das Konto eine Smart-Contract-Wallet. Die Funktion hat legitime Zwecke, etwa das Bündeln von Transaktionen oder das Bezahlen von Gebühren im Namen eines Nutzers.

Drei Details der Spezifikation sind für diesen Vorfall wichtig:

  • Autorisierungen werden in einem neuen Transaktionstyp übertragen, Typ 4 (0x04), der eine Liste davon enthalten kann. Jeder kann die Transaktion einreichen; die Autorisierung braucht nur eine gültige Signatur des Kontos.
  • Jede Autorisierung ist nur gültig, wenn ihr Nonce dem aktuellen Nonce des Kontos entspricht. Passt er nicht, wird diese eine Autorisierung übersprungen und die Transaktion fährt mit der nächsten fort.
  • Die Delegation ist dauerhaft. Sie bleibt bestehen, bis das Konto eine neue Autorisierung signiert, die auf ein anderes Ziel zeigt, oder eine, die auf die Nulladresse zeigt und sie damit löscht.

Wie die Wallet Binance 14 übernommen wurde

Die Hot Wallet einer stark genutzten Börse sendet ständig Transaktionen, ihr Nonce ändert sich also laufend. Ein Angreifer, der eine signierte Autorisierung im Voraus vorbereitet, kann nicht wissen, welcher Nonce gilt, wenn die Transaktion verarbeitet wird. Laut der Analyse von Blockaid löste der Angreifer dieses Problem, indem er statt eines einzelnen Werts einen ganzen Bereich signierte.

Uhrzeit (UTC, 29. Oktober)Was geschah
15:59Der Angreifer deployt einen „Sweeper“-Vertrag. Er ist nicht verifiziert, und nur die Operator-Adresse des Angreifers darf ihn aufrufen.
20:20:59Eine einzige Typ-4-Transaktion enthält 50 EIP-7702-Autorisierungen, alle mit dem Schlüssel der Hot Wallet Binance 14 signiert, für 50 aufeinanderfolgende Nonces. Genau eine passt zum aktuellen Nonce der Wallet, die nun an den Sweeper delegiert ist.
20:24:23Ein einziger Aufruf des Sweepers zieht rund 167.464 ETH, 1,615 Milliarden USDT und Dutzende weitere Tokens aus der Wallet ab und lässt 1 ETH für Gebühren übrig.
20:41Die weiterhin delegierte Wallet wird genutzt, um rund 823 Millionen USDC aus einem separaten Smart Account abzuziehen, den Binance 14 kontrollierte.
21:04 bis 23:56Die Wallet wird viermal weiter geleert, während neue Mittel eingehen. Allein um 21:44 werden mehr als 200 Millionen US-Dollar an neuen Einzahlungen ohne neue Signatur abgezogen.
00:10 (30. Oktober)Die Delegation wird widerrufen, laut der Zeitleiste von Hypernative.

Der USDC-Schritt zeigt einen zweiten Effekt. Ein delegiertes Konto behält alle Rollen, die es in anderen Verträgen hat: Owner, Executor, genehmigter Spender. Wer seine Ausführung kontrolliert, kann sie alle nutzen.

Warum eine leere Wallet trotzdem gefährlich war

Nach einem Diebstahl liegt die Annahme nahe, dass eine leere Wallet nichts mehr zu verlieren hat und dass ein neuer Schlüssel den Zugriff des Angreifers beendet. Mit EIP-7702 ist beides falsch. Die Delegation hängt an der Adresse, nicht am Guthaben und nicht an einer bestimmten Kopie des Schlüssels. Solange sie besteht, kann alles, was an die Adresse gesendet wird, vom delegierten Vertrag abgezogen werden, ohne dass der Angreifer eine weitere Signatur braucht.

Genau das ist hier passiert. Nach dem ersten Abräumen gingen weiterhin Mittel bei Binance 14 ein, und sie wurden erneut abgezogen. Eine Schlüsselrotation hätte nicht geholfen: Wie Blockaid betont, erfordert das Löschen der Delegation eine neue Autorisierung desselben Kontos, die auf die Nulladresse zeigt. Bis dieser Widerruf verarbeitet ist, sollte die Adresse als vom Angreifer kontrolliert gelten.

Tipp: Im Ernstfall zuerst widerrufen, dann Schlüssel rotieren und wieder auffüllen. Stoppen Sie alle automatisierten Prozesse, die Mittel an die betroffene Adresse senden, bis Sie bestätigt haben, dass die Delegation entfernt ist.

Was noch ungeklärt ist

Alle 50 Autorisierungen trugen gültige Signaturen des Binance-14-Schlüssels. Es gibt zwei grundsätzliche Erklärungen, und die öffentlich verfügbaren Belege lassen noch keine Entscheidung zwischen ihnen zu:

  • Der Schlüssel wurde geleakt, und der Angreifer hat die Autorisierungen direkt signiert.
  • Die Signaturinfrastruktur wurde missbraucht: Der Angreifer brachte die eigenen Signatursysteme von Binance dazu, Inhalte seiner Wahl zu signieren, ohne den Schlüssel jemals zu extrahieren.

Binance hat erklärt, keine Hinweise auf ein Leck des privaten Wallet-Schlüssels gefunden zu haben; die Untersuchung läuft noch. Der CEO von Blockaid sagte gegenüber Cointelegraph, die Aktivität deute eher auf eine Kompromittierung der Signaturinfrastruktur als auf einen geleakten Schlüssel hin, doch das ist eine vorläufige Einschätzung von außen. Bis Binance seinen Post-Mortem-Bericht veröffentlicht, betrachten wir die Frage als offen.

Was Sie tun sollten, wenn Sie Hot Wallets betreiben

1. Delegationsstatus überwachen

Ein delegiertes Konto hat Code. Unter EIP-7702 besteht dieser Code aus dem Delegationsindikator 0xef0100, gefolgt von der 20-Byte-Adresse des Vertrags, an den delegiert wird. Ein gewöhnliches EOA hat überhaupt keinen Code. Sie können jede Adresse mit einem Standard-JSON-RPC-Aufruf prüfen:

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

Das Ergebnis 0x bedeutet: keine Delegation. Ein Ergebnis, das mit 0xef0100 beginnt, bedeutet, dass die Adresse delegiert ist. Prüfen Sie dies für jede Hot Wallet bei jedem Block oder in kurzen Abständen, und alarmieren Sie sofort bei jeder Änderung, die Sie nicht geplant haben.

2. Typ-4-Transaktionen beobachten, die Ihre Adressen betreffen

Die Transaktion, die Ihre Wallet delegiert, muss nicht von Ihrer Wallet kommen. Jeder kann sie einreichen, solange sie eine gültige, mit Ihrem Schlüssel signierte Autorisierung enthält. Überwachen Sie Typ-4-Transaktionen, deren Autorisierungsliste eine Signatur einer Ihrer Adressen enthält, nicht nur Transaktionen, die von diesen Adressen gesendet werden.

3. Ein Inventar der Delegationen führen

Halten Sie für jede Adresse, die Sie betreiben, fest, ob sie überhaupt delegiert sein soll und, falls ja, an welchen auditierten Vertrag. Jede Delegation außerhalb dieser Liste ist ein Vorfall. Wenn Sie EIP-7702 nicht nutzen, ist der erwartete Zustand jeder Hot Wallet einfach: kein Code.

4. Unerwartete Autorisierungen beim Signierer ablehnen

Eine EIP-7702-Autorisierung hat ein eigenes Signaturformat: den Hash des Bytes 0x05, gefolgt von der kodierten Chain ID, Vertragsadresse und dem Nonce. Signaturdienste und HSM-Richtlinien können dieses Format erkennen. Wenn Sie keine Delegationen nutzen, blockieren Sie solche Inhalte vollständig; wenn doch, lassen Sie nur bekannte Vertragsadressen zu. Beachten Sie außerdem, dass eine Autorisierung mit Chain ID 0 auf jeder Chain gültig ist.

5. Den ausdrücklichen Widerruf ins Incident-Response-Runbook aufnehmen

Dokumentieren Sie für jede Wallet, wie eine Delegation widerrufen wird: wer die Autorisierung auf die Nulladresse signiert, von welchem System aus, und wie Sie bestätigen, dass sie wirksam ist (der Code der Adresse ist wieder 0x). Nehmen Sie das Stoppen eingehender Überweisungen an die betroffene Adresse auf, und üben Sie das Verfahren, bevor Sie es brauchen.

Tipp: Dasselbe Prinzip gilt auch außerhalb der Kryptowelt. Jede Berechtigung, die die Zugangsdaten überdauert, mit denen sie erstellt wurde, etwa ein OAuth-Refresh-Token, eine delegierte Cloud-Rolle oder ein langlebiges CI/CD-Token, braucht in der Incident Response einen eigenen, ausdrücklichen Widerrufsschritt.

Wie LOGIQ helfen kann

LOGIQ unterstützt Organisationen dabei, zu prüfen, wer und was auf ihren Linux-Servern, in Cloud-Konten und Pipelines mit Befugnissen handeln kann, und Monitoring sowie Incident-Response-Schritte aufzubauen, die auch delegierten Zugriff abdecken und nicht nur Passwörter und Schlüssel. Wenn Sie eine zweite Meinung zu Ihren eigenen Kontrollen wünschen, lesen Sie unseren oben verlinkten ersten Artikel zum Angriff oder nehmen Sie über unsere Website Kontakt mit uns auf.

Quellen