Binance-Hack 2026: Auszahlungen, Reserven und Ursachen

Sind Binance-Auszahlungen wieder möglich?

Am 5. November kündigte Binance für weitere Token und Netzwerke eine gestaffelte Wiederöffnung ab 04:00 UTC an. Die Liste bedeutet keine gleichzeitige Freigabe aller Positionen; prüfen Sie den konkreten Status im offiziellen Zugang.

Binance meldete am 4. November eine Wiederauffüllung von rund 98 % des betroffenen Betrags mit eigenen Mitteln. Das ist keine Quote zurückgeführter Diebesbeute.

Der neue Reserven-Snapshot vom 4. November, 00:00 UTC umfasst laut Binance 44 Token. Der vollständige kryptografische Nachweis war bei der Ankündigung noch in Arbeit. Ein Snapshot ist weder ein vollständiger Finanzaudit noch ein Nachweis zur Angriffsursache. [28] [29] [17]

Eingefroren ist nicht zurückgegeben

Die frühere Binance-Angabe von 2,54 Milliarden US-Dollar war ein Zwischenstand. Inzwischen meldet die Börse rund 3 Milliarden eingefrorene Werte. Eine Sperre kann die weitere Bewegung bestimmter Token begrenzen. Sie bedeutet nicht, dass diese Werte bereits an Binance oder Kunden zurückgegeben wurden.

Auch die geschätzten Gesamtauswirkungen von rund 6,3 Milliarden US-Dollar sind kein abschließend festgestellter Nettoverlust. Die Beträge stammen aus einer laufenden Untersuchung und beschreiben unterschiedliche Größen. Aus 6,3 minus 3 Milliarden lässt sich deshalb keine bestätigte Deckungslücke oder endgültige Schadenssumme berechnen. [11] [14] [15]

Mehrere Angriffspunkte statt einer einfachen Laptop-Erklärung

Die erste vorläufige Binance-Erklärung beschrieb einen kompromittierten DevOps-Laptop und Zugriff auf einen Service-Container. Die spätere Darstellung nennt zusätzliche Kompromittierungspunkte. Richard Teng sagt, es sei nicht nur um ein Gerät oder die Berechtigung eines einzelnen Mitarbeiters gegangen. Damit wird aus der ersten Spur noch keine abschließend rekonstruierte Ursache.

Nach Tengs Darstellung durchlief die EIP-7702-Delegation nicht die normalen Freigabekontrollen. Das wirft eine konkrete Frage auf: Welcher Weg erlaubte diese Autorisierung, obwohl die regulären Kontrollen sie hätten prüfen sollen? Die Erklärung legt noch nicht die vollständigen Protokolle, beteiligten Identitäten oder technischen Umgehungswege offen. Eine bestimmte Phishing-Methode oder ein Container-Ausbruch bleibt damit unbewiesen.

Die beobachtete Delegation auf Ethereum und der Zugang zur Betriebsinfrastruktur liegen auf verschiedenen Ebenen. Die Blockchain zeigt verarbeitete Autorisierungen und Transaktionen. Die Betriebsuntersuchung muss den Zugang davor erklären. EIP-7702 ermöglicht Code-Delegation; es ist keine Mehrfachsignatur-Regel und wird durch eine vereinfachende Beschreibung im Interview nicht zu einer solchen. [5] [14] [22] [23]

Was können Nutzer und Unternehmen jetzt tun?

Den tatsächlichen Status direkt in der bekannten Binance-App oder über die selbst eingegebene offizielle Adresse prüfen. Nachrichten mit angeblichen Entschädigungs- oder Entsperrlinks ignorieren; Passwörter, Einmalcodes und Wiederherstellungsphrasen niemals weitergeben. Unternehmen können Zuständigkeiten für externe Plattformen, Freigaben und Notfallkommunikation prüfen und relevante Kontostände und Transaktionen über offizielle Wege dokumentieren. Keine hektischen Transaktionen aufgrund unbestätigter Meldungen auslösen. [6]

Warum ein Laptop-Angriff nicht automatisch Schlüsseldiebstahl bedeutet

Ein Angreifer muss einen privaten Schlüssel nicht zwingend als Datei mitnehmen, um eine unerlaubte Transaktion auszulösen. In einer Infrastruktur mit Signierdiensten kann entscheidend sein, welche Aufträge die geschützte Signatur erreichen dürfen. Wird dieser Weg missbraucht, können technisch gültige Signaturen entstehen, obwohl der Geschäftsvorgang nicht genehmigt war. Das ist eine technische Einordnung, kein zusätzlicher bestätigter Binance-Befund.

Binance meldet bislang keine Hinweise auf ein Leck privater Wallet-Schlüssel. Damit wird die Frage nach Identitäten, Container-Zugängen und Freigaberegeln wichtiger. Sie ist noch nicht vollständig beantwortet: Ein erster Unternehmensbefund ersetzt weder die Rekonstruktion des gesamten Ablaufs noch unabhängige Prüfung. Die Ursache, die Vermögensbilanz und eine mögliche Erstattung müssen getrennt nachgewiesen werden. [5] [14] [16]

EIP-7702: Was eine Unterschrift tatsächlich erlaubt

EIP-7702 ist eine Ethereum-Funktion, mit der ein Konto die Ausführung von Code an einen Smart Contract delegieren kann. Dazu wird eine gültige Autorisierung des Kontos benötigt. Ein Dritter kann diese Autorisierung in eine passende Transaktion aufnehmen und die Gebühren zahlen; er muss die Transaktion nicht vom delegierenden Konto selbst absenden.

Wird die Autorisierung akzeptiert, verweist das Konto auf den gewählten Code. Ein späterer Aufruf kann diesen Code im Kontext des Kontos ausführen und dadurch auf dessen Vermögenswerte wirken. Die Delegation bleibt bestehen, bis sie durch eine neue gültige Autorisierung geändert oder aufgehoben wird. EIP-7702 ist eine Funktion, keine für diesen Vorfall nachgewiesene Sicherheitslücke.

Code kann bereits im Ausführungsteil derselben Transaktion aufgerufen werden; ein späterer Aufruf ist nicht erforderlich. Eine kryptographisch gültige Autorisierung belegt nicht, dass die Freigabe geschäftlich gewollt war. Auch wenn der anschließende Ausführungsteil mit einem Fehler (Revert) abbricht, wird eine zuvor gesetzte Delegation dadurch nicht zurückgenommen. [5]

Was die bisherige Analyse der Blockchain zeigt

Die Sicherheitsfirma Blockaid berichtet von einer Transaktion mit 50 EIP-7702-Autorisierungen für die als Binance 14 bezeichnete Adresse. Eine Autorisierung sei akzeptiert und das Konto an einen Contract delegiert worden. Die Nummer einer Autorisierung muss zum aktuellen Kontozähler, dem Nonce, passen. Diese Angaben sind eine vorläufige externe Analyse, kein abgeschlossener Binance-Untersuchungsbericht.

Eine unabhängige Analyse von 808bits datiert die Delegation auf den 29. Oktober um 20:20:59 UTC und einen anschließenden Aufruf mit Token- und Ether-Bewegungen auf 20:24:23 UTC. Die Zeiten beziehen sich auf untersuchte Ethereum-Transaktionen, nicht auf alle Netzwerke und nicht auf einen endgültigen Gesamtschaden. Dass eine gültige Autorisierung zu sehen ist, beantwortet nicht, wie sie erzeugt wurde: Schlüsselabfluss, missbrauchte Freigabe oder ein anderer Zugang sind anhand dieser Daten allein nicht bewiesen.

Quelle: 808bits und drk.vc; Zeitangaben beschreiben einzelne untersuchte Transaktionen, keinen bestätigten Gesamtschaden. [4] [7] [8]

Die Tabelle lässt sich seitlich verschieben.

Was Organisationen an ihrem Signaturprozess prüfen können

Für Verwahrer und Betreiber von Wallet-Infrastruktur ist der entscheidende Prüfpunkt, was die Signatur tatsächlich autorisiert. Signier- und Freigabesysteme sollten den Typ der Anfrage, Netzwerkkennung, Ziel-Contract und Nonce verständlich anzeigen und gegen eine dokumentierte Richtlinie prüfen. Blinde Freigaben unbekannter Hashes und nicht benötigte Delegationen sollten nach Möglichkeit verhindert werden.

Zusätzlich können Teams erlaubte Delegationsziele begrenzen, Änderungen und ungewöhnliche Serien von Autorisierungen alarmieren und die Freigabe kritischer Änderungen unabhängig prüfen. Für einen Vorfall gehören Zuständigkeiten, ein geübter Stopp- und Wiederanlaufplan sowie die Sicherung von Signatur- und Systemprotokollen dazu. Welche dieser Maßnahmen den konkreten Binance-Vorfall verhindert hätte, ist noch nicht belegt.

Diese Kontrollen sind eine technische Einordnung von Cyberkern. Richtlinien müssen vor der Signatur den tatsächlich zu signierenden Inhalt prüfen; eine reine Hash-Freigabe kann den Zweck verbergen. Eine Blockchain-Meldung nach der Ausführung kommt für die Verhinderung dieser Transaktion zu spät. Auch eine erlaubte Zieladresse allein garantiert keinen sicheren Code. [5] [9]

Was die 50 Autorisierungen und der Nonce verraten

Die Zahl 50 beschreibt zunächst Einträge in einer Autorisierungsliste. Sie ist weder eine Zahl betroffener Kunden noch ein Beleg für 50 gestohlene Schlüssel. Für jeden Eintrag prüft Ethereum unter anderem Signatur, Netzwerkkennung und den zum Konto passenden Nonce. Scheitert eine Prüfung, wird der Eintrag übersprungen und die Liste weiterverarbeitet.

Der Nonce ist ein Kontozähler. Bei einer stark genutzten Wallet kann er sich durch laufende Transaktionen rasch ändern. Mehrere Autorisierungen für unterschiedliche Zählerstände können deshalb ein Zeitfenster abdecken. Die externen Analysen melden für die untersuchte Binance-Transaktion eine akzeptierte Autorisierung. Das ist ein Befund zu diesem Fall, keine Protokollregel: Eine Liste kann grundsätzlich mehrere gültige Einträge enthalten; nach einer akzeptierten Autorisierung steigt der Kontozähler. [5] [7] [12]

Wie konnte das trotz Signaturschutz passieren?

Die erste DevOps-Spur erklärt den gesamten Ablauf noch nicht. Richard Teng nennt zusätzliche Kompromittierungspunkte und sagt, die Delegation habe normale Freigabekontrollen nicht durchlaufen. Der angekündigte Review umfasst Endgeräte, Cloud, Schlüsselverwaltung und Signierung. Für Betreiber zählt daher nicht nur der Schutz eines Geräts, sondern die belegbare Kontrolle jedes kritischen Autorisierungswegs.

Für Betreiber ergeben sich daraus drei Kontrollfragen. Sie sind Cyberkerns technische Einordnung; aus der vorläufigen Erklärung lässt sich noch nicht ableiten, welche konkrete Kontrolle den Binance-Vorfall sicher verhindert hätte:

Eine belastbare Rekonstruktion verknüpft Zugangsprotokolle, Container-Aktivitäten, Auszahlungsaufträge, Freigaben und die tatsächlichen Signaturen. Auf der Blockchain muss der gemeldete Widerruf vom historischen Zustand unterschieden werden. Eine Konto- oder Sitzungsmaßnahme allein ist kein allgemeiner Beleg, dass eine zuvor gesetzte Delegation auf der Blockchain aufgehoben ist. [5] [12] [14] [22] [23]

• Identität und Auftrag: Welche Identität konnte vom betroffenen Gerät aus kritische Anfragen stellen, und wurden angezeigter Vorgang und tatsächlich signierter Inhalt unabhängig abgeglichen?
• Berechtigung im Container: Welche Dienste und Auszahlungsfunktionen waren erreichbar? Waren Rechte, Dienstzugänge und Ausnahmewege auf den notwendigen Umfang begrenzt?
• Eindämmung und Nachweis: Wann wurden Geräte- und Dienstzugänge gesperrt, betroffene Autorisierungen widerrufen und die Änderungen anhand von Protokollen beziehungsweise Blockchain-Zustand überprüft?

Hätte eine Hardware- oder Cold-Wallet das verhindert?

Offline verwahrte Schlüssel und geeignete Hardware können die Angriffsfläche für Schlüsseldiebstahl erheblich begrenzen. Das ist ein wichtiger Schutz. Er beantwortet aber eine andere Frage als die Prüfung des Inhalts: Auch ein gut geschützter Schlüssel kann einen gefährlichen Auftrag signieren, wenn eine falsche Delegation oder ein falsches Ziel genehmigt wird.

Bei einer Börse kommen verfügbare Betriebsbestände und häufige Auszahlungen hinzu. Entscheidend sind deshalb die begrenzten Bestände einer Hot-Wallet, getrennte Zuständigkeiten und verständliche, verbindliche Regeln für kritische Signaturen. Welche Hardware, Schlüsselaufteilung oder Offline-Verwahrung Binance bei den betroffenen Systemen einsetzte, ist durch die hier geprüften Quellen nicht vollständig belegt. Aus dem Vorfall folgt weder, dass Hardware-Wallets nutzlos sind, noch dass ein bestimmtes Produkt ihn sicher verhindert hätte. [5] [13]

Drei Fragen für Nutzer und an den Untersuchungsbericht

Ist damit auch meine eigene Wallet kompromittiert? Der Vorfall bei Binance belegt keinen Zugriff auf eine unabhängig verwaltete persönliche Wallet. Ein Börsenguthaben und selbst verwahrte Schlüssel sind unterschiedliche Situationen. Den Status des eigenen Börsenkontos prüfen Sie über die bekannte App oder die selbst eingegebene offizielle Adresse; aus einer allgemeinen Meldung lässt sich kein individueller Kontostand ableiten.

Sollte ich jetzt eine angebliche Entschädigung oder Wallet-Reparatur bestätigen? Nein. Eine Nachricht über einen Börsenvorfall begründet keine Freigabe für unbekannte Contracts, keine Weitergabe einer Wiederherstellungsphrase und keine Zahlung an einen Helfer. Nach einem öffentlich bekannten Hack können gerade solche Angebote den nächsten Schaden auslösen. Technische Änderungen an einer tatsächlich betroffenen Wallet gehören in einen geprüften Wiederherstellungsplan.

Was muss ein vollständiger Untersuchungsbericht liefern? Eine zeitliche und technische Verbindung zwischen Zugang, Signatur und Geldbewegung. Dazu eine nachvollziehbare Abrechnung, die Transfers, eingefrorene Werte, Rückführungen und verbleibenden Verlust sauber trennt. Eine Deckungszusage beantwortet die Frage nach der finanziellen Verantwortung; sie ersetzt weder den Ursachennachweis noch den Nachweis bereits erfolgter Erstattungen. Ein Reservennachweis allein ersetzt weder einen vollständigen Finanzaudit noch die Untersuchung der Ursache und interner Sicherheitskontrollen. [5] [6] [13] [14] [17]