Zurück

2026/11/02

Der größte Krypto-Raub begann nicht auf der Blockchain, sondern auf einem einzigen Laptop: Lehren aus dem Fall Binance

Der Binance-Diebstahl begann auf einem kompromittierten DevOps-Laptop, nicht mit geknackter Kryptografie. Was feststeht, was nicht, und fünf Checks für Ihre Systeme.

Am 29. Oktober 2026 leerten Angreifer innerhalb weniger Stunden Hot Wallets von Binance auf mindestens zehn Blockchains. Binance beziffert den Schaden auf rund 6,3 Milliarden US-Dollar – damit ist es nahezu sicher der größte Diebstahl in der Geschichte der Kryptowährungen. Versagt hat nicht die Kryptografie. Laut den vorläufigen Erkenntnissen von Binance begann der Angriff auf einem einzigen kompromittierten Laptop eines DevOps-Ingenieurs.

Damit ist dieser Vorfall weit über Krypto-Börsen hinaus relevant. Jede Organisation hat Personen, Geräte und Systeme, die sensible Aktionen freigeben können: Produktiv-Deployments, Zahlungen, Signaturen, privilegierten Cloud-Zugriff. Dieser Artikel trennt Bestätigtes von noch Vorläufigem, erklärt, warum ein kompromittierter privilegierter Endpoint schlimmer sein kann als ein gestohlener Schlüssel, und nennt fünf Prüfpunkte, die Sie in Ihrer eigenen Umgebung durchgehen können.

Das Wichtigste in Kürze

  • Die vorläufige Untersuchung von Binance deutet auf den kompromittierten Laptop eines DevOps-Ingenieurs als Einfallstor hin, und Binance gibt an, keine Hinweise auf ein Leck privater Wallet-Schlüssel gefunden zu haben. Beide Erkenntnisse sind vorläufig.
  • Ein Angreifer, der die Systeme kontrolliert, die Signaturen anfordern und freigeben, muss die Schlüssel nicht stehlen.
  • Das FBI und mehrere Blockchain-Analysefirmen schreiben den Diebstahl der nordkoreanischen Gruppe TraderTraitor zu; Binance selbst hat keinen Angreifer benannt.
  • Die wichtigsten Schutzmaßnahmen sichern die Menschen, Endpoints und Freigabewege rund um die Schlüssel ab – nicht nur die Schlüssel selbst.
  • Dasselbe Muster gilt für Cloud-Konsolen, SSH, CI/CD-Pipelines und KI-Agenten, die in der Produktion handeln können.

Was passiert ist und was noch vorläufig ist

Laut dem Blockchain-Analyseunternehmen TRM Labs begannen die Mittel am 29. Oktober gegen 20:05 Uhr UTC aus den Binance-Wallets abzufließen; der Großteil des Werts wurde innerhalb von etwa 20 Minuten bewegt. In ihrer vorläufigen Stellungnahme, über die BleepingComputer berichtete, erklärte Binance, der Vorfall betreffe möglicherweise den kompromittierten Laptop eines DevOps-Ingenieurs, über den der Angreifer einen Service-Container erreichte und nicht autorisierte Auszahlungstransaktionen einreichte. Binance setzte die Auszahlungen aus, widerrief die betroffene Autorisierung und nahm die Zusammenarbeit mit den Strafverfolgungsbehörden auf.

Inzwischen erklärte Binance, die Untersuchung habe „weitere Einbruchstellen aufgedeckt“. Co-CEO Richard Teng sagte, der Angriff sei nicht auf die Berechtigungen eines einzelnen Ingenieurs zurückzuführen, und – wie Elliptic ihn zitiert – er sei „nicht durch unsere normalen Freigabekontrollen gelaufen“. Binance hat einen detaillierten Post-Mortem-Bericht zugesagt, der zum Zeitpunkt der Erstellung dieses Artikels (2. November) noch nicht veröffentlicht war.

PunktStand zum Zeitpunkt der Erstellung
Betroffener BetragRund 6,3 Milliarden US-Dollar nach Schätzung von Binance; Analysefirmen nennen je nach Methode und Kursbasis 6,36 bis 6,43 Milliarden US-Dollar.
EinfallstorVorläufig: der kompromittierte Laptop eines DevOps-Ingenieurs. Binance hat inzwischen weitere Einbruchstellen gemeldet.
Leck privater SchlüsselBinance gibt an, keine Hinweise auf ein Leck privater Wallet-Schlüssel gefunden zu haben. Die Untersuchung dauert an.
UrheberDas FBI schrieb den Diebstahl am 31. Oktober der nordkoreanischen Gruppe TraderTraitor zu, im Einklang mit TRM Labs, Chainalysis und Elliptic. Binance hat keinen Angreifer benannt.
Eingefrorene MittelNoch nicht endgültig. Binance spricht von rund 3 Milliarden US-Dollar, die blockiert wurden; Elliptic hatte mit Stand 1. November rund 2,85 Milliarden US-Dollar als on-chain eingefroren oder beschlagnahmt verifiziert, überwiegend Stablecoins.
Auswirkungen für KundenBinance erklärt, den Verlust selbst zu tragen, und die Gelder der Nutzer seien sicher. Am 1. November begann die schrittweise Wiederaufnahme der Auszahlungen.

Eingefroren heißt nicht zurückgeholt. Stablecoin-Emittenten wie Tether und Circle können die von ihnen ausgegebenen Token einfrieren, doch Bitcoin, XRP und andere native Assets lassen sich auf diese Weise nicht einfrieren, und ein Großteil des gestohlenen Werts wird weiterhin gewaschen.

Warum ein kompromittierter privilegierter Endpoint schlimmer sein kann als ein gestohlener Schlüssel

Ein gestohlener privater Schlüssel ist ein ernstes Problem, aber ein einzelnes und gut verstandenes: Man rotiert den Schlüssel, und die gestohlene Kopie verliert den Großteil ihres Werts. Ein Angreifer, der das Gerät eines privilegierten Ingenieurs kontrolliert, ist in einer ganz anderen Lage. Er kann die Systeme nutzen, die legitim Signaturen anfordern, interne Dienste mit gültigen Zugangsdaten aufrufen und Transaktionen senden, die wie normale Vorgänge aussehen.

Die On-Chain-Daten passen zu diesem Bild. TRM Labs kam zu dem Schluss, dass das Muster über viele Chains hinweg „auf eine Kompromittierung der Signatur-Infrastruktur der Hot Wallets von Binance hindeutet“ – der Angreifer konnte also Binances eigene Systeme dazu bringen, Transaktionen seiner Wahl zu signieren. Auf Ethereum stellte das Sicherheitsunternehmen Blockaid fest, dass eine Hot Wallet einen Stapel von EIP-7702-Autorisierungen signierte, die die Kontrolle über die Wallet an den Contract des Angreifers übergaben. Wie diese Signaturen erlangt wurden, ist noch nicht bestätigt; diesen Mechanismus behandeln wir in einem separaten Folgeartikel.

Neu ist das nicht. Beim Bybit-Diebstahl im Februar 2025, den das FBI ebenfalls TraderTraitor zuschrieb, kompromittierten die Angreifer den Rechner eines Entwicklers bei einem Wallet-Anbieter und manipulierten die Transaktion, die die Unterzeichner von Bybit freigaben. In beiden Fällen taten die Schlüssel genau das, was von ihnen verlangt wurde. Die Frage war, wer es verlangte.

Fünf Prüfpunkte für die Abwehr

1. Privilegierte Geräte von der täglichen Arbeit trennen

Das Gerät, mit dem Produktivänderungen freigegeben, Transaktionen signiert oder Infrastruktur administriert wird, sollte nicht dasselbe sein, das für E-Mail, Chat, Surfen und die Installation von Entwicklerwerkzeugen genutzt wird. Setzen Sie dedizierte, gehärtete Admin-Workstations oder isolierte virtuelle Desktops ein, ohne private Konten und mit einer kurzen Liste freigegebener Software. TraderTraitor hat wiederholt gefälschte Jobangebote und bösartige Programmieraufgaben genutzt, um auf die Rechner von Entwicklern zu gelangen; ein separates Gerät hält eine solche Kompromittierung vom Freigabeweg fern.

2. Mehr als eine Person verlangen – und Zeit einbauen

Keine einzelne Person, kein einzelnes Gerät und kein einzelnes Dienstkonto sollte allein große Werte bewegen oder die Produktion verändern können. Verlangen Sie Freigaben von Personen auf getrennten Geräten, legen Sie Wertlimits pro Transaktion und pro Zeitfenster fest und bauen Sie für große oder ungewöhnliche Vorgänge eine Verzögerung (einen Timelock) ein. Schon eine Verzögerung von wenigen Minuten gibt dem Monitoring und den Menschen die Chance zu reagieren.

Tipp: Prüfen Sie, ob die Freigebenden sehen, was sie tatsächlich freigeben. Im Fall Bybit gaben die Unterzeichner eine Transaktion frei, deren tatsächlicher Inhalt manipuliert worden war. Der Freigabebildschirm sollte die genaue Aktion, das Ziel und den Betrag anzeigen – erzeugt unabhängig vom anfragenden System.

3. Endpoints härten und überwachen

Betreiben Sie EDR auf jedem privilegierten Gerät und stellen Sie sicher, dass jemand die Alarme rund um die Uhr prüft. Halten Sie Systeme auf dem aktuellen Patch-Stand, blockieren Sie nicht signierte oder nicht freigegebene Software, nutzen Sie Phishing-resistente MFA wie Hardware-Sicherheitsschlüssel und begrenzen Sie, wie lange Admin-Sitzungen und Tokens gültig bleiben. Betrachten Sie Entwicklerwerkzeuge, einschließlich Paketen, IDE-Erweiterungen und KI-Coding-Assistenten, als Teil der Angriffsfläche.

4. Anomalien erkennen und schnell einfrieren können

Die Binance-Gelder wurden innerhalb von Minuten bewegt. Definieren Sie, wie der Normalzustand bei Ihren sensibelsten Vorgängen aussieht – etwa Volumen, Ziele, Tageszeiten und Signaturraten –, und alarmieren Sie bei Abweichungen in Echtzeit. Bereiten Sie einen Notstopp vor, der Auszahlungen, Deployments oder Signaturen innerhalb von Sekunden anhalten kann, legen Sie im Voraus fest, wer ihn auslösen darf, und üben Sie seinen Einsatz.

5. Prüfen, wer und was Signaturen und Produktionszugriff auslösen kann

Erfassen Sie jede Person, jedes Dienstkonto, jeden Container, jede Pipeline und jeden API-Schlüssel, die eine Signatur anfordern, eine Zahlung freigeben oder die Produktion ändern können. Prüfen Sie für jeden Eintrag, ob der Zugriff noch benötigt wird, ob er so eng wie möglich begrenzt ist und ob seine Nutzung an einem Ort protokolliert wird, den der Angreifer nicht löschen kann. Entfernen Sie dauerhafte Berechtigungen, wo immer möglich, und setzen Sie stattdessen auf Just-in-Time-Zugriff.

Lehren für Unternehmens-Cloud, SSH, CI/CD und KI-gestützten Betrieb

Die meisten Organisationen betreiben keine Krypto-Hot-Wallets, aber alle haben etwas Vergleichbares: Zugangsdaten und Systeme, die mit Befugnis handeln können.

  • Cloud: Der Laptop eines Administrators mit einer aktiven Konsolensitzung oder zwischengespeicherten CLI-Zugangsdaten ist so wertvoll wie das Root-Konto. Nutzen Sie kurzlebige Zugangsdaten, gerätegebundene Sitzungen und Freigabe-Workflows für destruktive oder folgenreiche Aktionen.
  • SSH: Langlebige Schlüssel auf den Rechnern von Ingenieuren verschaffen einem Angreifer direkten Serverzugriff. Setzen Sie bevorzugt auf kurzlebige SSH-Zertifikate, die pro Sitzung ausgestellt werden, und protokollieren Sie jede privilegierte Sitzung zentral.
  • CI/CD: Pipelines enthalten häufig Zugangsdaten für Deployment und Signierung. Schützen Sie Pipeline-Definitionen durch verpflichtende Reviews, trennen Sie Build- und Release-Zugangsdaten und verlangen Sie eine Freigabe für Produktiv-Releases.
  • KI-gestützter Betrieb: KI-Agenten, die Befehle ausführen, Pull Requests öffnen oder Produktiv-APIs aufrufen können, sind neue privilegierte Identitäten. Geben Sie ihnen eigene, eng begrenzte Zugangsdaten, behalten Sie für sensible Aktionen einen menschlichen Freigabeschritt bei und protokollieren Sie, was sie tun.

Tipp: Führen Sie eine Tabletop-Übung mit einer einzigen Frage durch: „Wenn der Laptop dieses Ingenieurs heute Nacht vollständig kompromittiert würde, was könnte der Angreifer tun, bevor es jemand bemerkt?“ Die Antwort zeigt, wo Ihre Freigabewege von einem einzigen Gerät abhängen.

Worauf als Nächstes zu achten ist

Der Post-Mortem-Bericht von Binance sollte die Laptop-Theorie bestätigen oder korrigieren, erklären, wie die Signaturen erlangt wurden, und zeigen, welche Kontrollen umgangen wurden. Bis dahin sollten Sie die Ursache als vorläufig betrachten. Die oben genannten Lehren für die Abwehr hängen nicht von den endgültigen Details ab: Unabhängig vom genauen Weg gelangte der Angreifer zu den Systemen, die sensible Aktionen autorisieren konnten.

Wie LOGIQ Sie unterstützen kann

LOGIQ unterstützt Organisationen dabei, privilegierte Zugriffe auf Linux-Servern, in Cloud-Umgebungen und CI/CD-Pipelines zu überprüfen und Freigabe- und Überwachungskontrollen zu entwerfen, die zur tatsächlichen Arbeitsweise ihrer Teams passen. Wenn Sie einen zweiten Blick darauf werfen lassen möchten, wer und was in Ihrer Umgebung mit Befugnis handeln kann, kontaktieren Sie uns.

Quellen