Der Binance-Sicherheitsvorfall hat nicht nur wegen des Ausmaßes der verdächtigen Wallet-Aktivitäten Aufmerksamkeit erregt, sondern auch wegen eines technischen Details, das kurz bevor bedeutende Ethereum-Vermögenswerte sich zu bewegen begannen, sichtbar war: eine Reihe von EIP-7702-Autorisierungen.
Dieses Detail rückte EIP-7702 schnell in den Mittelpunkt der Diskussion. Der Ethereum-Kontodelegationsmechanismus ermöglicht es einem normalen extern verwalteten Konto, oder EOA, vorübergehend Smart-Contract-Logik auszuführen. Im Binance-Vorfall identifizierten Blockchain-Forscher kurz vor der Übertragung von Vermögenswerten aus einer mit Binance verbundenen Hot Wallet eine EIP-7702-Delegation.
Doch es gibt einen wichtigen Unterschied.
Die Existenz einer EIP-7702-Autorisierung beweist für sich genommen nicht, dass EIP-7702 ausgenutzt wurde.
Binances erste Untersuchung deutet stattdessen auf eine Kompromittierung der operativen Infrastruktur hin. Die Börse erklärte, der Laptop eines DevOps-Ingenieurs könnte kompromittiert worden sein, wodurch ein Angreifer Zugriff auf einen Service-Container erlangen und unbefugte Auszahlungstransaktionen einreichen konnte. Binance erklärte außerdem, es seien keine Hinweise auf ein Leck der Wallet-Privatschlüssel gefunden worden.
Das macht den Vorfall besonders wichtig für das Verständnis moderner Wallet-Sicherheit. Ein Privatschlüssel kann innerhalb geschützter Infrastruktur bleiben, während ein Angreifer ein anderes System missbraucht, das berechtigt ist, legitime Signaturen anzufordern.
Dieser Artikel erklärt, was EIP-7702 im Vorfall offenbar bewirkt hat, warum Berichte über mehrere Autorisierungen Aufmerksamkeit erregten und warum der Unterschied zwischen Schlüsseldiebstahl und der Kompromittierung der Signaturinfrastruktur von Bedeutung ist.
Was geschah beim Binance-Sicherheitsvorfall?
Verdächtige Aktivitäten im Zusammenhang mit Binance-verbundenen Hot Wallets begannen am 30. Oktober 2026 Aufmerksamkeit zu erregen.
On-Chain-Ermittler beobachteten große Überweisungen von mit der Börse verbundenen Wallets an neu erstellte Adressen. Erste Schätzungen variierten erheblich, während Forscher Transaktionen über Ethereum, Bitcoin, Tron und andere Netzwerke hinweg verfolgten.
Binance bestätigte anschließend einen Sicherheitsvorfall und begann, die Quelle der unbefugten Transaktionen zu untersuchen. Die Börse setzte Einzahlungen und Auszahlungen vorübergehend aus, während Sicherheitsprüfungen durchgeführt wurden.
In seinem Sicherheitsupdate vom 30. Oktober erklärte Binance, seine erste Untersuchung deute darauf hin, dass ein kompromittierter Laptop eines DevOps-Ingenieurs es einem Angreifer ermöglicht habe, Zugriff auf einen Service-Container zu erlangen und unbefugte Auszahlungstransaktionen einzureichen.
Die Börse schätzte die Gesamtauswirkung in diesem Stadium der Untersuchung auf etwa 6,3 Milliarden US-Dollar und erklärte, dass rund 3 Milliarden US-Dollar der betroffenen Vermögenswerte on-chain eingefroren worden seien. Binance erklärte außerdem, dass es Verluste aus seinem SAFU-Fonds und Unternehmensmitteln decken werde.
Am wichtigsten für die technische Diskussion erklärte Binance:
Es seien keine Hinweise auf ein Leck eines Wallet-Privatschlüssels gefunden worden.
Diese Aussage verändert die Art und Weise, wie die gemeldete EIP-7702-Aktivität interpretiert werden sollte.
Statt nur zu fragen, ob ein Angreifer einen Hot-Wallet-Privatschlüssel gestohlen hat, wird die relevantere Frage, ob ein kompromittiertes internes System in der Lage war, eine gültige Autorisierung von geschützter Signaturinfrastruktur anzufordern oder zu ermöglichen.
Warum wurde EIP-7702 Teil der Untersuchung?
EIP-7702 wurde mit Ethereums Pectra-Upgrade eingeführt, um extern verwalteten Konten einige der Fähigkeiten zu verleihen, die normalerweise mit Smart-Contract-Wallets verbunden sind.
Traditionell wird ein Ethereum-EOA durch einen Privatschlüssel kontrolliert. Es kann Transaktionen signieren, Vermögenswerte übertragen und mit Smart Contracts interagieren, aber sein eigenes Konto enthält keine programmierbare Ausführungslogik.
EIP-7702 ändert diese Beziehung.
Es ermöglicht einem EOA, den Code eines anderen Contracts zu autorisieren, als seine Ausführungslogik zu fungieren, während die ursprüngliche Ethereum-Adresse erhalten bleibt.
Dies ermöglicht nützliche Funktionen der Kontenabstraktion wie Transaktionsbündelung, Gas-Sponsoring und fortgeschrittenere Berechtigungssysteme.
Es bedeutet auch, dass eine EIP-7702-Autorisierung deutlich mehr Aufmerksamkeit verdient als eine herkömmliche Token-Genehmigung.
Während der Analyse des Binance-Vorfalls berichteten Forscher, dass eine über Tornado Cash finanzierte Adresse kurz vor dem Auftreten bedeutender Vermögensübertragungen mehrere EIP-7702-Autorisierungen im Zusammenhang mit einer Binance-verbundenen Ethereum-Hot-Wallet eingereicht habe.
Eine Autorisierung habe Berichten zufolge mit dem Wallet-Zustand übereingestimmt und sei wirksam geworden.
Etwa drei Minuten später begannen bedeutende Vermögenswerte, die Wallet zu verlassen.
Das Timing machte die Autorisierung natürlich zu einem wichtigen Teil der Untersuchung.
Es sagt uns jedoch immer noch nicht, wie die gültige Autorisierung erlangt wurde.
Wie funktioniert eine EIP-7702-Autorisierung?
Der einfachste Weg, den Mechanismus zu verstehen, besteht darin, sich EIP-7702 so vorzustellen, dass es einem gewöhnlichen Ethereum-Konto vorübergehend erlaubt, zu sagen:
„Verwende die Ausführungslogik dieses Smart Contracts, wenn mein Konto Aufrufe erhält.“
Ein vereinfachter Ablauf sieht so aus:
Ethereum EOA
│
│ Unterzeichnet eine EIP-7702-Autorisierung
▼
Delegation wird zugewiesen
│
▼
Delegierter Smart Contract
│
│ Stellt ausführbare Logik bereit
▼
Ursprüngliches EOA kann
Verhalten im Stil eines Smart Contracts ausführen
Das ursprüngliche Konto verschwindet nicht.
Seine Adresse, Guthaben und bestehende On-Chain-Historie bleiben intakt. Was sich ändert, ist der Code, der über dieses Konto ausgeführt werden kann.
EIP-7702 enthält auch Schutzmaßnahmen. Autorisierungen sind an den Kontozustand gebunden, einschließlich einer Nonce, und können ersetzt oder widerrufen werden. Sie sind daher keine beliebigen Anweisungen, die jemand an die Wallet einer anderen Person anhängen kann.
Eine gültige Autorisierung erfordert weiterhin eine legitime kryptografische Autorisierung durch das betreffende Konto.
Dieser Punkt ist zentral für das Verständnis des Binance-Vorfalls.
Wenn ein Angreifer erfolgreich bösartige Delegationslogik installiert, lautet die wichtige Sicherheitsfrage nicht einfach:
„Hat der Angreifer EIP-7702 verwendet?“
Sie lautet:
„Wie hat der Angreifer die Befugnis erlangt, eine gültige EIP-7702-Autorisierung zu erstellen?“
Warum wurden mehrere EIP-7702-Autorisierungen gemeldet?
Sicherheitsforscher, die die Transaktionen untersuchten, berichteten, dass der Angreifer einen Batch mit etwa 50 Autorisierungen eingereicht habe, die verschiedenen Nonce-Werten zugeordnet waren.
Auf den ersten Blick können „50 Autorisierungen“ so klingen, als wären 50 Wallets kompromittiert worden.
Das ist nicht unbedingt, was passiert ist.
Ethereum-Konten führen eine Nonce, die sich ändert, wenn Transaktionen ausgeführt werden. Eine EIP-7702-Autorisierung muss dem entsprechenden Kontozustand entsprechen.
Wenn ein Angreifer weiß, welche Wallet er ins Visier nehmen will, aber nicht zuverlässig bestimmen kann, welche Nonce gültig sein wird, wenn eine Transaktion das Netzwerk erreicht, kann er Autorisierungen für mehrere mögliche Nonce-Werte vorbereiten.
Nur die Autorisierung, die dem gültigen Zustand der Wallet entspricht, würde erfolgreich sein.
Diese Technik wird manchmal als Nonce-Spraying bezeichnet.
Die wichtige Implikation ist, dass die Existenz von 50 Autorisierungseinträgen nicht unbedingt 50 erfolgreiche Berechtigungen, 50 kompromittierte private Schlüssel oder 50 separate Wallet-Angriffe bedeutet.
Stattdessen könnte das Muster darauf ausgelegt gewesen sein, die Wahrscheinlichkeit zu erhöhen, dass eine zuvor erhaltene Autorisierung beim Einreichen dem Zustand des Zielkontos entspricht.
Das wirft eine weitere Frage auf:
Wer – oder welches interne System – hatte die Befugnis, die zugrunde liegende Signatur zu erstellen?
Hier werden die vorläufigen Erkenntnisse von Binance besonders relevant.
Diebstahl privater Schlüssel und Kompromittierung der Signaturinfrastruktur sind unterschiedliche Probleme
Viele Diskussionen über Kryptowährungssicherheit reduzieren den Wallet-Schutz auf ein Prinzip:
Schütze den privaten Schlüssel.
Das bleibt wesentlich, aber institutionelle Wallets sind erheblich komplizierter.
Eine Börse kann Hardware-Sicherheitsmodule, Signaturdienste, Richtlinien-Engines, Auszahlungsdienste, Zugriffskontrollsysteme und andere Infrastruktur rund um den zugrunde liegenden Schlüssel verwenden.
Ein Angreifer kann daher versuchen, den Prozess zu kompromittieren, der eine Signatur anfordert, anstatt den privaten Schlüssel selbst zu extrahieren.
Die vorläufige Untersuchung von Binance deutet derzeit viel stärker auf das zweite Szenario hin.
Die Börse erklärte, ein kompromittiertes DevOps-Laptop habe möglicherweise Zugriff auf einen Dienstcontainer ermöglicht, der in der Lage sei, unbefugte Auszahlungstransaktionen einzureichen, während sie ausdrücklich angab, keine Hinweise auf ein Leck privater Schlüssel gefunden zu haben.
Diese Unterscheidung ist bedeutsam.
Ein hardwaregeschützter privater Schlüssel kann technisch sicher bleiben, während die umgebende Infrastruktur eine Signatur für etwas erzeugt, das niemals hätte genehmigt werden dürfen.
Hat EIP-7702 den Binance-Hack verursacht?
Basierend auf den derzeit verfügbaren Informationen gibt es keine öffentlichen Belege dafür, dass eine Schwachstelle in EIP-7702 selbst den Sicherheitsvorfall bei Binance verursacht hat.
Diese Unterscheidung ist entscheidend.
Ein Angreifer, der eine legitime Protokollfunktion nutzt, bedeutet nicht automatisch, dass die Funktion fehlerhaft war.
Betrachten wir ein einfacheres Beispiel.
Wenn ein Angreifer legitime Zugangsdaten für ein Bankkonto erlangt und eine Überweisung über das normale Zahlungssystem der Bank veranlasst, beweist die Tatsache, dass die Überweisungsinfrastruktur der Bank die Zahlung ausgeführt hat, nicht, dass das Überweisungsprotokoll selbst fehlerhaft war.
Eine ähnliche Unterscheidung gilt hier.
EIP-7702 hat möglicherweise den Ausführungsmechanismus bereitgestellt, durch den ein erfolgreich autorisiertes Konto sein Verhalten an bösartigen Code delegieren konnte.
Aber EIP-7702 erfordert normalerweise eine gültige Autorisierung.
Die ungeklärte Frage ist, wie diese Autorisierung möglich wurde.
Binances vorläufige Erklärung deutet darauf hin, dass die Ermittler eine kompromittierte operative Infrastruktur und nicht einen Fehler des Ethereum-Protokolls untersuchen.
Daher ist die genaueste Interpretation in diesem Stadium:
EIP-7702 erscheint relevant für den untersuchten Ausführungspfad, wurde jedoch nicht als die zugrunde liegende Schwachstelle bestätigt.
Was wurde bestätigt und was wird noch untersucht?
Da sich große Sicherheitsvorfälle schnell entwickeln, ist es besonders wichtig, bestätigte Erkenntnisse von Analysen auf Transaktionsebene zu unterscheiden.
Diese Unterscheidung ist wichtig, weil Blockchain-Transaktionen eine hervorragende Sichtbarkeit darüber bieten, was on-chain geschah, aber nicht unbedingt offenlegen, wie ein internes Signatursystem kompromittiert wurde.
Forscher können Delegationen, Überweisungen und Vertragsinteraktionen beobachten.
Sie können allein aus Blockchain-Daten nicht feststellen, ob eine Signatur erstellt wurde, nachdem ein privater Schlüssel gestohlen wurde, ob ein interner Dienst sie legitimerweise angefordert hat oder ob ein kompromittierter Workflow dazu führte, dass ein geschützter Signierer bösartige Anweisungen autorisierte.
Dafür sind Beweise aus dem Inneren der betroffenen Infrastruktur erforderlich.
Warum die Signaturinfrastruktur ebenso wichtig ist wie die Speicherung privater Schlüssel
Institutionelle Kryptowährungssicherheit besteht zunehmend aus mehreren Schichten.
Die erste ist die Schlüsselsicherheit.
Wo wird der private Schlüssel gespeichert? Kann er extrahiert werden? Ist er durch ein Hardware-Sicherheitsmodul oder ein anderes kryptografisches Verwahrungssystem geschützt?
Die zweite ist die Signatursicherheit.
Welche Dienste dürfen Signaturen vom geschützten Schlüssel anfordern? Welche Authentifizierungs-, Richtlinien- und Genehmigungsmechanismen müssen diese Dienste erfüllen?
Die dritte ist die Autorisierungssicherheit.
Selbst wenn eine Anfrage kryptografisch gültig ist, was genau wird das Konto aufgefordert zu autorisieren?
Diese dritte Schicht wird zunehmend wichtiger, da Smart Accounts und Kontodelegation immer leistungsfähiger werden.
Eine herkömmliche Token-Überweisung kann einen festen Betrag eines Vermögenswerts bewegen.
Eine Delegation kann stattdessen ändern, wie ein Konto zukünftige Anweisungen ausführen kann.
Für Sicherheitsteams bedeutet der Unterschied, dass die Signaturvalidierung allein nicht mehr ausreicht.
Die Bedeutung der Transaktion muss ebenfalls bewertet werden.
Warum EIP-7702 die Sicherheitsannahmen von Wallets verändert
EIP-7702 ist gerade deshalb leistungsfähig, weil es erweitert, was ein gewöhnliches Ethereum-Konto tun kann.
Eine Wallet kann programmierbare Funktionen erhalten, ohne Vermögenswerte in eine völlig neue Smart-Contract-Wallet zu migrieren.
Für Verbraucher-Wallets kann dies die Benutzerfreundlichkeit verbessern.
Für ausgefeilte institutionelle Infrastruktur kann es fortgeschrittenere Ausführungsrichtlinien unterstützen.
Aber zusätzliche Programmierbarkeit schafft zusätzliche Autorisierungsoberflächen.
Eine bösartige ERC-20-Genehmigung gibt typischerweise einer anderen Adresse Berechtigung über einen Token.
Eine bösartige EIP-7702-Delegation kann potenziell beeinflussen, wie ein Konto viel breitere Klassen von Aktionen ausführt.
Das macht EIP-7702 nicht von Natur aus unsicher.
Es bedeutet, dass Wallets, Börsen und Verwahrungsanbieter die Delegationsautorisierung als einen Sicherheitsvorgang mit hohem Risiko behandeln sollten.
Eine EIP-7702-Signatur sollte nicht nur als kryptografisch gültig bewertet werden.
Sicherheitssysteme sollten auch fragen, ob das Delegationsziel erwartet wird, ob sein Bytecode überprüft wurde, ob die angeforderte Autorisierung zum normalen Verhalten des Kontos passt und ob die interne Richtlinie es diesem Konto überhaupt erlaubt, die Ausführung zu delegieren.
Was sollte die Binance-Nachanalyse klären?
Binance hat erklärt, dass eine detaillierte technische Nachanalyse veröffentlicht wird, sobald die Untersuchung abgeschlossen ist.
Mehrere Fragen werden bestimmen, wie die Branche den Vorfall letztlich interpretiert.
Erstens: Wie gelangte der Angreifer Zugang zum Signaturpfad?
Die vorläufige DevOps-Erklärung identifiziert einen potenziell kompromittierten Teil der Infrastruktur, doch die vollständige Kette von diesem Zugang bis zu einer gültigen Blockchain-Autorisierung bleibt wichtig.
Zweitens: Welche genaue Rolle spielte EIP-7702?
Die Ermittler müssen feststellen, ob eine Delegation erforderlich war, um die Ethereum-Transfers auszuführen, wie die Autorisierung vorbereitet wurde und warum interne Kontrollen sie zuließen.
Drittens: Waren private Schlüssel jemals exponiert?
Binance erklärt derzeit, dass es keine Hinweise auf ein Leck privater Schlüssel gibt. Ein vollständiger forensischer Bericht könnte mehr Details darüber liefern, wie die Schlüssel von der kompromittierten Infrastruktur isoliert wurden.
Schließlich: Welche Kontrolle hätte die Transaktion stoppen sollen?
Für institutionelle Sicherheitsteams könnte dies die wertvollste Frage von allen sein.
Eine technisch gültige Signatur sollte nicht automatisch eine operativ gültige Transaktion bedeuten.
Die stärksten Verwahrungssysteme trennen kryptografische Autorisierung von geschäftlicher Autorisierung.
Was bedeutet das für gewöhnliche Ethereum-Wallet-Nutzer?
Der Binance-Vorfall betrifft institutionelle Infrastruktur und sollte nicht automatisch als Beweis dafür interpretiert werden, dass gewöhnliche Ethereum-Wallets demselben Angriffspfad ausgesetzt sind.
Eine persönliche Self-Custody-Wallet und ein Hot-Wallet-System einer Börse funktionieren sehr unterschiedlich.
EIP-7702 vermittelt jedoch auch einzelnen Nutzern eine wichtige Lektion:
Eine Delegationssignatur verdient dieselbe Vorsicht wie andere mächtige Wallet-Berechtigungen.
Nutzer sollten sorgfältig prüfen, was eine Wallet von ihnen zu signieren verlangt, insbesondere wenn eine unbekannte Website eine Kontodelegation anfordert.
Eine bösartige Delegation sollte nicht mit einer gewöhnlichen Login-Signatur verwechselt werden.
Nutzer sollten sich außerdem auf etablierte Wallet-Oberflächen verlassen, die Delegationsanfragen klar kennzeichnen und verdächtige Verträge melden.
Das zentrale Sicherheitsprinzip bleibt einfach: Beurteilen Sie eine Signatur nicht nur danach, ob sie sofort Guthaben überträgt. Manche Signaturen ändern, wozu ein Konto später berechtigt sein wird.
Die größere Lektion: Wallet-Sicherheit geht über private Schlüssel hinaus
Der Binance-Sicherheitsvorfall hebt eine breitere Entwicklung in der Blockchain-Sicherheit hervor.
Jahrelang war die vorherrschende Annahme der Branche einfach:
Schütze den Schlüssel, schütze die Wallet.
Dieses Modell wird zunehmend unvollständig.
Moderne institutionelle Wallets hängen oft von Infrastrukturschichten rund um den Schlüssel ab – APIs, Signaturdienste, Auszahlungs-Engines, Richtliniensysteme, Zugriffskontrollen und automatisierte Ausführungsumgebungen.
Account-Abstraction-Mechanismen wie EIP-7702 fügen eine weitere Ebene hinzu, indem sie Wallets erlauben, Ausführungslogik zu delegieren.
Infolgedessen hängt die Sicherheit von Kryptowährungen zunehmend von drei separaten Fragen ab:
Wer kontrolliert den Schlüssel?
Wer kann eine Signatur anfordern?
Und welche Befugnis gewährt diese Signatur tatsächlich?
Ein System kann bei der ersten Frage erfolgreich sein und bei der zweiten oder dritten versagen.
Dies scheint eines der wichtigsten Probleme zu sein, die die Binance-Untersuchung bisher aufgeworfen hat.
FAQ
War EIP-7702 die Ursache des Binance-Hacks?
Nicht bestätigt. Die vorläufigen Erkenntnisse von Binance deuten auf eine kompromittierte operative Infrastruktur hin, während EIP-7702 offenbar Teil des untersuchten Autorisierungspfads war.
Wurden private Schlüssel von Binance gestohlen?
Binance erklärte, in seiner ersten Untersuchung keine Hinweise auf ein Leck privater Wallet-Schlüssel gefunden zu haben.
Was ist EIP-7702?
EIP-7702 ermöglicht es einer Ethereum-EOA, Ausführungslogik an Smart-Contract-Code zu delegieren, während dieselbe Wallet-Adresse beibehalten wird.
Warum wurden mehrere EIP-7702-Autorisierungen beobachtet?
Sie könnten über verschiedene Nonce-Werte vorbereitet worden sein, um dem Zielkontozustand zu entsprechen. Dies bedeutet nicht zwangsläufig, dass mehrere Wallets kompromittiert wurden.
Sind gewöhnliche Ethereum-Nutzer betroffen?
Es gibt keine Hinweise auf eine netzwerkweite Kompromittierung von Ethereum-Wallets. Nutzer sollten dennoch bei unbekannten Delegations- oder Signaturanfragen vorsichtig sein.
Reicht der Widerruf von Token-Genehmigungen aus?
Nicht immer. ERC-20-Genehmigungen und EIP-7702-Delegation sind separate Berechtigungen, daher entfernt das Aufheben einer Token-Genehmigung nicht automatisch die Kontodelegation.
Fazit
Das Auftreten von EIP-7702 im Binance-Vorfall macht den Mechanismus zu einem wichtigen Bestandteil der technischen Untersuchung, aber die verfügbaren Beweise belegen nicht, dass EIP-7702 selbst kompromittiert wurde.
Die vorläufigen Erkenntnisse von Binance deuten stattdessen darauf hin, dass ein Angreifer möglicherweise den Laptop eines DevOps-Ingenieurs kompromittiert, Zugang zu einem operativen Service-Container erlangt und unbefugte Auszahlungstransaktionen eingereicht hat. Die Börse gibt an, keine Hinweise auf ein Leck der privaten Schlüssel der Wallet gefunden zu haben.
Die Unterscheidung ist wichtig.
Wenn ein geschütztes Signatursystem dazu veranlasst werden kann, bösartige Anweisungen zu autorisieren, müssen Angreifer möglicherweise gar nicht den privaten Schlüssel stehlen.
EIP-7702 kann die Folgen einer solchen Autorisierung verstärken, da es einem Ethereum-Konto ermöglicht, programmierbare Ausführungslogik zu delegieren. Doch diese Fähigkeit bösartig zu nutzen und eine Schwachstelle im Protokoll zu finden, sind zwei verschiedene Dinge.
Bis Binance seine vollständige technische Post-Mortem-Analyse veröffentlicht, ist EIP-7702 am besten als eine Komponente im gemeldeten Ausführungspfad zu verstehen – nicht als bestätigte Grundursache des Vorfalls.
Für Börsen, Verwahrungsanbieter und Wallet-Entwickler ist die größere Lehre bereits klar: Moderne Wallet-Sicherheit muss nicht nur private Schlüssel schützen, sondern auch die Systeme, die Signaturen anfordern, und die Berechtigungen, die diese Signaturen erzeugen.
Risikohinweis: Dieser Artikel dient ausschließlich Informations- und Bildungszwecken. Kryptowährungs- und Blockchain-Systeme bergen technische, operative und Marktrisiken. Leser sollten Sicherheitsinformationen unabhängig überprüfen und geeignete Risikokontrollen beim Verwalten digitaler Vermögenswerte anwenden.
