Also, der Reihe nach: Am 29. Oktober abends sind aus einer Wallet von Binance innerhalb von Minuten Milliarden abgeflossen. Die Schlagzeilen überschlugen sich, die Zahlen änderten sich stündlich, und am nächsten Tag stand die Summe bei über sechs Milliarden Dollar, ein grosser Teil davon inzwischen eingefroren. Was mich daran interessiert, ist nicht die Summe. Es ist der Satz, der in allen Analysen auftaucht: kein gestohlener Schlüssel, keine gebrochene Kryptografie. Eine gültige Signatur. Für eine Operation, die niemand hätte signieren dürfen. Das ist kein Krypto-Problem. Das ist ein Architekturproblem, und ich kenne es aus Banken, aus Cloud-Plattformen, und seit einem Jahr aus unseren eigenen Agenten.
Was passiert ist, soweit man es weiss
Nach den bisherigen Analysen hat die Wallet „Binance 14" am 29. Oktober gegen 20:20 Uhr UTC ihre Ausführung an einen fremden Smart Contract delegiert, über die Ethereum-Funktion EIP-7702. Vier Minuten später begann der Abfluss: ETH und Stablecoins, aus dieser einen Wallet allein rund zweieinhalb Milliarden. Eine Analysefirma beschreibt, dass der Angreifer fünfzig Autorisierungen in eine einzige Transaktion gepackt hat, von denen eine die passende Nonce hatte. Dazu gleich mehr. Als Einstiegspunkt wird laut Berichten mit Bezug auf Binance der kompromittierte Laptop eines Ingenieurs genannt, über den ein Angreifer in einen Service-Container gelangt sein soll. Eine Blockchain-Forensikfirma schreibt den Angriff mit hoher Sicherheit einer nordkoreanischen Gruppe zu.
Alles davon ist vorläufig. Zwischen bewegten, eingefrorenen und endgültig verlorenen Beträgen muss man unterscheiden, und die interne Architektur von Binance kennt niemand ausserhalb. Aber die Richtung ist klar genug, um daraus zu lernen.
Warum mich so etwas interessiert
Wer mich kennt, weiss, dass mich solche Vorfälle schon immer beschäftigt haben. Nicht wegen der Schlagzeile. Wegen der Frage, was dahintersteckt: Wie konnte es passieren, welche Entscheidungen haben es ermöglicht, welche Grenze hat gehalten und welche nicht. Wenn ein komplexes System versagt, will ich wissen, warum. Nicht nur, wo der Fehler war, sondern welche Abhängigkeiten und Vertrauensbeziehungen dazu geführt haben. Daraus lernt man mehr über Architektur als aus jedem Buch.
Wie wir das heute untersuchen
Früher hiess so eine Untersuchung: Artikel, Spezifikationen, Stellungnahmen von Hand zusammentragen und vergleichen. Heute machen wir das mit unseren Agenten, und zwar aufgeteilt. Einer verfolgt die offiziellen Mitteilungen und wie sie sich über die Stunden ändern. Einer liest die technische Spezifikation und mögliche Angriffstechniken. Einer vergleicht die Aussagen der Sicherheitsforscher und sucht gezielt nach Widersprüchen. Dann führen wir zusammen und prüfen, welche Aussage wirklich von mehreren unabhängigen Quellen getragen wird.
Das macht die Ergebnisse nicht automatisch richtig. Mehrere Agenten können denselben Fehler übernehmen, dieselbe Ursprungsmeldung lesen, eine plausible und falsche Erklärung bauen. Darum muss jede wichtige Aussage auf ihren Beleg zurückführbar sein. Dasselbe Prinzip wie bei allem, was wir bauen: Belege statt Behauptungen. Die Agenten nehmen mir das Denken nicht ab. Sie bringen mich schneller zu den richtigen Fragen.
Drei Ebenen, die man nicht vermischen darf
Beobachtbare Fakten. Transaktionen auf der Blockchain, Zeitstempel, Smart-Contract-Code, Signaturen. Das kann jeder nachprüfen, und das tun wir als Nächstes.
Aussagen von Beteiligten. Stellungnahmen der Börse, der Forensikfirmen, der Infrastrukturanbieter. Wichtig, aber mit Interesse.
Technische Interpretation. Der Versuch, aus eins und zwei einen Ablauf zu rekonstruieren. Hier braucht es Disziplin: Ein plausibles Szenario ist kein nachgewiesener Angriff. Und sobald man eine Erklärung hat, sucht man unbewusst nach Bestätigung. Ich suche lieber nach Widersprüchen.
Was EIP-7702 tut, in drei Absätzen
Ethereum kennt zwei Arten von Konten: solche, die ein privater Schlüssel kontrolliert, und solche, die aus Code bestehen. Seit dem Pectra-Upgrade kann ein normales Konto seine Ausführung an bestehenden Smart-Contract-Code delegieren. Das ermöglicht nützliche Dinge, gebündelte Transaktionen, flexible Gebühren, programmierbare Wallets. Es verändert aber, was eine Signatur bedeutet.
Eine solche Autorisierung enthält die Chain-ID, die Adresse des Contracts, eine Nonce, und die Signatur. Der Kontoinhaber bestätigt damit nicht eine einzelne Überweisung. Er bestätigt: Dieses Konto darf ab jetzt den Code dieser Adresse ausführen. Die Delegation bleibt, bis sie ersetzt oder entfernt wird. Das ist ein grundsätzlich anderes Gewicht als eine Überweisung. Die Kontrolle über das Konto hängt ab jetzt von der Logik des Contracts ab, und wenn der Contract dem Angreifer gehört, gehört ihm das Konto.
Und ein Detail, das in der Berichterstattung untergeht: Eine Transaktion darf mehrere solche Autorisierungen enthalten, jede wird einzeln geprüft, ungültige werden übersprungen. Darum die fünfzig Einträge, von denen einer passte. Das heisst nicht, dass jemand Signaturen erraten hat, das geht bei ECDSA nicht. Es heisst, dass jemand eine gültige Signatur hatte und die Nonce nicht sicher kannte. Die Frage ist also nicht, ob die Kryptografie gehalten hat. Sie hat. Die Frage ist, wie diese Signatur entstanden ist.
Der mögliche Angriffspfad
Als Hypothese, nicht als Rekonstruktion der Binance-Infrastruktur, die niemand von uns kennt:
Der entscheidende Schritt ist der vierte. Ein Container hat keine finanziellen Rechte, ausser die Infrastruktur gibt sie ihm. Wenn ein Signaturdienst nur prüft, ob der Aufrufer grundsätzlich signieren darf, und nicht, was er signieren lässt, dann braucht der Angreifer den Schlüssel nicht. Er braucht nur einen Dienst, der ihn verwenden darf. Ob es bei Binance so war, ist offen. Dass es so gehen kann, ist sicher.
Warum ein HSM das nicht löst
Der Reflex nach so einem Vorfall ist: Schlüssel ins Hardware-Modul, dann kann nichts passieren. Das Modul sorgt dafür, dass der Schlüssel nie herauskommt. Gut und richtig. Aber wenn ein Dienst dem Modul einen Payload schickt und das Modul signiert, was es bekommt, dann ist der Schlüssel geschützt und die Autorisierung trotzdem missbraucht. Ist der Payload eine Überweisung? Eine Rechteänderung? Eine Delegation, die dem Angreifer dauerhaft das Konto gibt? Das Modul weiss es nicht, wenn es niemand prüft. Den Schlüssel zu schützen reicht nicht. Man muss die Bedeutung der Operation prüfen, die mit dem Schlüssel autorisiert wird.
Wie ich so etwas absichern würde
Getrennte Vertrauensdomänen. Entwicklungsarbeitsplätze, Build-Systeme, Container und produktive Signaturdienste dürfen nicht dieselbe Domäne sein. Eine kompromittierte Entwickleridentität darf nicht bis zur Finanzoperation reichen. Getrennte Identitäten, minimale Rechte, kontrollierte Kommunikation.
Semantische Prüfung jeder kritischen Signatur. Der Signaturdienst nimmt keinen beliebigen Payload entgegen. Er versteht, was drin ist: Überweisung, Rechteänderung, Delegation. Und für Delegationen auf einer Milliarden-Wallet lautet die Regel schlicht: nicht erlaubt. Nicht als Konfiguration, die derselbe Angreifer ändern kann, sondern erzwungen.
Wirklich unabhängige Freigaben. Mehrstufig, über getrennte Domänen, Multi-Party. Zwei Freigaben, die über dieselbe kompromittierte Administrationsumgebung laufen, sind eine.
Den maximalen Schaden begrenzen. Warum kontrolliert eine einzelne operative Wallet überhaupt Milliarden? Limits, getrennte Bestände, verzögerte Grosstransfers, technisch erzwungen. Die wichtigste Kennzahl ist nicht die Wahrscheinlichkeit eines Angriffs. Es ist der maximale Schaden, wenn er gelingt.
Stopp vor der Signatur, nicht Alarm danach. Eine ungewöhnliche Delegation auf einer kritischen Wallet muss blockiert werden, bevor sie signiert wird, von einer Instanz, die nicht dieselbe Infrastruktur ist. Eine bestätigte Transaktion nimmt kein Alarm zurück. Das ist das Notfallprotokoll aus dem Regeln-Artikel, nur vor dem Notfall.
Fehler finden ist einfach geworden
Und jetzt der Teil, weshalb ich das in die Werkstatt schreibe und nicht nur als Analyse. Was hier passiert ist, war einmal Spezialistenarbeit: eine neue Protokollfunktion verstehen, ihre Semantik gegen die Annahmen einer Signaturinfrastruktur halten, die Lücke dazwischen finden, den Contract bauen, die Nonce durch fünfzig Versuche abdecken. Dafür brauchte es Leute, die Monate hatten. Heute braucht es einen Agenten, dem man die Spezifikation und ein Ziel gibt. Ich habe vor einer Woche über Reverse Engineering für alle geschrieben: Der Schutz waren die Kosten, und die Kosten sind weg. Dasselbe gilt für Exploits. Die Angreifer haben die Werkzeuge, die wir haben, und sie brauchen keine Abnahme.
Warum das Banken und KI-Agenten betrifft
Das ist kein Blockchain-Thema. Banken haben zentrale Signaturdienste und Zahlungsfreigaben. Cloud-Plattformen laufen auf Service-Identitäten und Tokens. Und KI-Agenten bekommen Zugriff auf Werkzeuge, Datenbanken und geschäftskritische Prozesse. Überall dieselbe Frage: Was passiert, wenn eine technisch berechtigte Komponente eine fachlich unzulässige Aktion ausführt? Ein Agent kann ein gültiges Token haben und trotzdem den gefährlichen Befehl ausführen. Er kann innerhalb seiner Rechte handeln und weit über seine Aufgabe hinaus wirken. Ich habe das vor zwei Wochen erlebt, als unser eigener Agent 169 Dateien überschrieben hat: gültige Rechte, falsche Operation, niemand dazwischen.
Das löst kein besserer Prompt. Es braucht unabhängige Prüfung, klare Grenzen, nachvollziehbare Entscheidungen und Mechanismen, die auch dann halten, wenn der Agent selber kompromittiert ist. Die ausführende Komponente darf nicht die letzte Instanz sein, die über die Zulässigkeit ihrer eigenen Aktion entscheidet. Kein Agent nimmt sich selber ab, und keine Wallet auch nicht.
Und das gilt für die Recherche-Agenten genauso. Einer, der Quellen sammelt, darf nicht entscheiden, dass etwas wahr ist. Einer, der Zusammenhänge analysiert, darf eine Hypothese nicht als bestätigten Angriff darstellen. Einer, der zusammenfasst, muss zeigen, ob zehn Artikel unabhängig sind oder eine Meldung. Quellenzuordnung und die Trennung von Beobachtung und Interpretation sind keine journalistischen Anforderungen. Sie sind Agentenarchitektur.
Was wir wissen und was offen ist
| Aussage | Stand 30. Oktober |
|---|---|
| Milliardenabfluss bei Binance am 29. Oktober | Vielfach berichtet, on-chain sichtbar |
| Gesamtsumme über 6 Milliarden Dollar | Vorläufig (Forensikfirma); aus „Binance 14" allein rund 2,5 bis 2,8 Mrd |
| Rund 2,4 Milliarden eingefroren | Vorläufig (Stablecoin-Herausgeber) |
| EIP-7702-Delegation als Mechanismus | Externe Analysen, on-chain prüfbar |
| Fünfzig Autorisierungen in einer Transaktion, eine mit passender Nonce | Analyse einer Sicherheitsfirma, on-chain prüfbar |
| Kompromittierter Laptop eines Ingenieurs als Einstieg | Laut Berichten mit Bezug auf Binance, nicht unabhängig bestätigt |
| Private Schlüssel gestohlen | Nicht nachgewiesen; Analysten sprechen von Missbrauch, nicht Abfluss |
| Signaturinfrastruktur missbraucht | Technisch plausible, unbestätigte Hypothese |
| Schwachstelle im Protokoll EIP-7702 | Nicht belegt; das Protokoll hat getan, was es soll |
| Zuschreibung an eine nordkoreanische Gruppe | Eine Forensikfirma, hohe Sicherheit nach eigener Angabe |
Ein grosser Vorfall rechtfertigt keine unbelegten Schlüsse. Eine Technik ist nicht unsicher, weil sie in einem Angriff vorkam. Und aus dem Ausmass eines Schadens folgt nicht automatisch, welche Kontrolle gefehlt hat.
Wie es weitergeht
Als Nächstes gehen wir mit den Agenten auf die Blockchain selber: welche Wallets, welche Autorisierungen tatsächlich stattgefunden haben, welche Contracts danach gelaufen sind, in welcher Reihenfolge. Transaktions-Hashes, Zeitstempel, Nonces, Contract-Code gegen die Berichte. Die Blockchain zeigt, was ausgeführt wurde. Sie zeigt nicht, ob ein Laptop kompromittiert oder ein Signaturdienst missbraucht wurde. Dafür braucht es Forensik, die wir nicht haben. Ziel ist nicht, die Theorie zu bestätigen. Ziel ist, zu wissen, welcher Teil des Pfads sich nachweisen lässt und welcher offen bleibt. Das kommt in einem zweiten Artikel.
Und damit klar ist, warum wir diese Stunden investieren, obwohl uns niemand dafür bezahlt: Wir machen das, um zu lernen. Nicht aus Neugier an fremdem Unglück, sondern weil ich überzeugt bin, dass Sicherheit im System der einzige Weg in die Zukunft ist. Nicht als Schicht obendrauf, nicht als Prüfung hinterher, sondern eingebaut in die Beziehungen zwischen den Komponenten, so dass ein einzelner Fehler nicht alles kostet. Jeder Vorfall, den man wirklich versteht, macht die eigene Architektur ein Stück besser. Das gilt für Wallets, für Banken, und für die Agenten, die wir bauen. Und wer mich kennt, weiss: Das interessiert mich einfach. Seit dem ersten System, das ich habe kippen sehen.
Noch etwas, damit niemand das hier für mehr hält, als es ist: Das ist meine Meinung und meine Recherche, Stand heute. Sie kann in einer Woche ganz anders aussehen, wenn die On-Chain-Daten etwas anderes zeigen als die Berichte. Dann steht das auch hier. Wir verfolgen das die nächste Woche, und was sich ändert, wird nicht still korrigiert, sondern sichtbar.
Was bleibt
Ein Schlüssel kann geschützt sein. Ein HSM kann korrekt arbeiten. Eine Signatur kann gültig sein. Und trotzdem lässt das System eine Operation zu, die nie hätte passieren dürfen. Ob es bei Binance genau so war, zeigt die Untersuchung. Die Architekturfrage bleibt so oder so: Sicherheit entsteht nicht durch sichere Komponenten, sondern durch kontrollierte Beziehungen zwischen ihnen. Wer vertraut wem, mit welchen Rechten, und was passiert, wenn eine davon fällt. Es reicht nicht, Angriffe unwahrscheinlich zu machen. Man muss Systeme so bauen, dass ein einzelner Fehler nicht alles kostet.
Eine gültige Signatur ist noch keine sichere Entscheidung. Das Netzwerk prüft die Kryptografie, nicht die Absicht. Wer Milliarden verwaltet, oder einen Agenten mit Rechten auf Produktion, braucht eine Instanz zwischen „darf signieren" und „darf das signieren", die nicht dieselbe Infrastruktur ist. Fehler finden ist einfach geworden. Also müssen wir sie zuerst finden, und so bauen, dass sie nicht alles kosten. Was die Blockchain dazu sagt, kommt im nächsten Artikel.
Quellen
Spezifikation. EIP-7702, Set Code for EOAs. eips.ethereum.org
Analysen zum Vorfall, Stand 30. Oktober 2026. Blockaid zu den fünfzig Autorisierungen, Zeitstempeln und „Missbrauch statt Abfluss": blockaid.io. TRM Labs zur Gesamtsumme und Zuschreibung: trmlabs.com. Cointelegraph zum Laptop und zur Einschätzung „Key misuse, not theft": cointelegraph.com. Technische Darstellung der Delegation bei drk.vc.
Vergleich. Bybit, Februar 2025, rund 1,5 Milliarden, über kompromittierte Infrastruktur des Wallet-Anbieters Safe, bei der Freigebende etwas anderes sahen, als sie signierten. Anderer Angriff, dieselbe Grenze: zwischen Signaturfähigkeit und fachlicher Autorisierung.
Methodik. Die Eigenschaften von EIP-7702 sind anhand der Spezifikation nachvollziehbar. Die Angaben zum Vorfall, zu Beträgen und zum Angriffspfad sind vorläufig. Die Architekturmassnahmen sind allgemeine Empfehlungen, keine Feststellungen über die Infrastruktur von Binance.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert ein eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal wird daraus ein Mix. Ich lese natürlich alles nochmal, aber niemand ist unfehlbar. Was drin bleibt, ist dann auch von mir.