Bitget verlor am 24. September 2026 rund 387,5 Millionen US-Dollar, nachdem Angreifer ein Sicherheitsprodukt eines Drittanbieters ausgenutzt, sich hoch privilegierte interne Zugangsdaten verschafft und gefälschte Auszahlungsbefehle durch die Wallet-Infrastruktur der Börse geschleust hatten.
Der Vorfall ist der bislang größte Krypto-Diebstahl des Jahres 2026 und nach aktuellen Einschätzungen von Analysehäusern der größte Einzeldiebstahl, der 2026 Nordkorea zugeschrieben wird. Bitgets erste Schätzung lag bei 351,6 Millionen US-Dollar, die Summe stieg jedoch, nachdem Ermittler weitere Zcash- und TRON-Transfers nachverfolgt hatten. Frühe unabhängige On-Chain-Schätzungen hatten den Schaden auf etwa 174 Millionen bis 183 Millionen US-Dollar beziffert.
Kernaussage: Der Bitget-Exploit war kein klassischer Diebstahl privater Schlüssel. Die Angreifer kompromittierten eine vertrauenswürdige Sicherheitsebene, ließen bösartige Auszahlungsanweisungen für den Autorisierungsprozess legitim erscheinen und bewegten über Hot- und Warm-Wallets rund 387,5 Millionen US-Dollar, bevor die Kontrollen den Abfluss stoppten.
Wie umging der Bitget-Hack die Sicherheitskontrollen der Börse?
Der Bitget-Hack umging die Sicherheitskontrollen der Börse, indem die Angreifer ein kritisches Backend-System mit Anbindung an die Wallet-Infrastruktur kompromittierten, interne Zugangsdaten erlangten, Transaktionsdaten fälschten und betrügerische Auszahlungsbefehle einschleusten. Nach Angaben von Bitget passierten die Befehle die Risikokontrollen der Börse, weil der Autorisierungsprozess Transaktionsinformationen erhielt, die wie gewöhnliche, legitime Auszahlungen aussahen.
In einem Livestream bezeichnete Bitget die Schwachstelle des Drittanbieters als Zero-Day, während die formelle Erklärung vorsichtiger formuliert war. Den Anbieter hat die Börse nicht genannt. Bitget erklärte, den Anbieter informiert, Einzelheiten zur Schwachstelle weitergegeben und die betroffene Funktion bis zu einer Korrektur deaktiviert zu haben.
Die Angriffskette lässt sich in fünf miteinander verknüpften Stufen darstellen:
- Kompromittierung eines Drittanbieters: Der Angreifer nutzte eine Schwachstelle in einem Sicherheitsprodukt aus, das in der Umgebung von Bitget eingesetzt wurde.
- Zugriff auf Zugangsdaten: Der Angreifer verschaffte sich hoch privilegierte interne Zugangsdaten.
- Manipulation des Backends: Der Angreifer kompromittierte ein kritisches Backend-System innerhalb der Wallet-Infrastruktur.
- Fälschung von Transaktionsdaten: Der Angreifer veränderte oder fälschte die Transaktionsdaten, die dem Autorisierungsprozess vorgelegt wurden.
- Ausführung der Auszahlungen: Gefälschte Auszahlungsbefehle umgingen die Risikokontrollen und zogen Assets aus Hot- und Warm-Wallets ab.
Die Unterscheidung zwischen der Kompromittierung von Signaturschlüsseln und der Kompromittierung der Autorisierungsebene ist wesentlich. Bitget erklärte, dass Cold Wallets, private Schlüssel, die Kontostände der Nutzer und die Self-Custody-Wallet Bitget Wallet nicht kompromittiert wurden. Handel und Einzahlungen liefen weiter, plattformweite Auszahlungen wurden allerdings gesperrt, nachdem das Abgleichssystem eine Abweichung festgestellt hatte.
Der Angriff zielte somit auf die Fähigkeit der Börse, zu beurteilen, ob eine Auszahlungsanforderung vertrauenswürdig ist. Ein gültig wirkender Befehl kann gefährlich sein, selbst wenn die kryptografische Signatur unversehrt bleibt. Ist das System kompromittiert, das eine Transaktion vorbereitet, beschreibt, weiterleitet oder freigibt, kann der Signaturprozess eine Anweisung ordnungsgemäß autorisieren, die die Börse nie erteilen wollte.
„Nach unserer Erfahrung aus Audits von Smart Contracts und Wallet-Infrastruktur bei Soken reicht die Integrität der Autorisierung weiter als der Schutz privater Schlüssel. Ein System kann seine Schlüssel bewahren und dennoch die Kontrolle über die Gelder verlieren, wenn kompromittierte Backend-Daten als maßgebliche Beschreibung dessen behandelt werden, was ein Unterzeichner freigibt.“
Der Bitget-Vorfall lieferte auch Hinweise auf antiforensische Aktivitäten. Der Angreifer löschte die Spuren der eingeschleusten Befehle, was Gracy Chen als den tückischsten Teil der Operation bezeichnete. Aus diesem Verhalten ergibt sich eine konkrete Anforderung an die Incident Response: Börsen müssen unabhängige, manipulationsresistente Aufzeichnungen über Erstellung, Freigabe, Signierung und Übermittlung von Befehlen vorhalten.
Ein sicheres Design sollte sich nicht auf ein einziges internes System verlassen, das eine Auszahlungsanforderung sowohl erstellt als auch dem Freigebenden beschreibt. Eine unabhängige Rekonstruktion der Transaktion, Richtlinienprüfungen über einen getrennten Kanal, unveränderliche Audit-Logs und eine strikte Trennung zwischen Sicherheitswerkzeugen und Wallet-Betrieb können gefälschte Anweisungen leichter erkennbar machen.
Wie verlief der Bitget-Exploit zeitlich?
Der Bitget-Exploit entwickelte sich von kleinen Testtransfers zu einem Abfluss über mehrere Chains, bevor der automatisierte Abgleich eine Abweichung feststellte. Die ersten nicht autorisierten Transfers erfolgten am 24. September 2026 um 18:31 UTC. Der Hauptabfluss lief anschließend von 18:58 bis 20:09 UTC in 17 Transaktionen über 8 Chains, der letzte Transfer des Angreifers wurde um 21:23 UTC beobachtet.
| Uhrzeit oder Datum | Ereignis im Bitget-Vorfall | Sicherheitsrelevanz |
|---|---|---|
| 18:31 UTC, 24. September | Erste nicht autorisierte Transfers aus Hot- und Warm-Wallets festgestellt | Zwei Testtransfers, 0,184 ETH und 193 TRX, blieben unter den Risikoschwellen |
| 18:58 bis 20:09 UTC, 24. September | Hauptabfluss in 17 Transaktionen über 8 Chains | Rund 361 Millionen US-Dollar wurden in der Hauptsequenz bewegt |
| 19:05 UTC, 24. September | Abgleichssystem stellte eine Abweichung fest | Plattformweite Auszahlungen wurden gesperrt |
| 20:40 UTC, 24. September | Bitget begann, verbleibende Gelder in Cold Storage zu überführen | Das verbleibende Wallet-Risiko wurde verringert |
| 21:23 UTC, 24. September | Letzter Transfer des Angreifers on-chain beobachtet | Der letzte Transfer erfolgte 2 Stunden und 52 Minuten nach dem ersten Test |
| 21:44 UTC, 24. September | Wallet-Dienste und Signierung wurden abgeschaltet | Der Signaturbetrieb wurde gestoppt |
| 25. September, 08:43 UTC | Bitget ermittelte die Grundursache | Die Untersuchung ging von der Eindämmung zur Behebung über |
| 25. September, 13:42 UTC | Strafverfolgungsbehörden wurden informiert | Die externe Eskalation des Vorfalls begann |
| 28. September, 08:00 UTC | BTC-Auszahlungen wurden wieder aufgenommen | Die stufenweise Wiedereröffnung begann |
| 29. September, 08:00 UTC | Wiederaufnahme der ETH-Auszahlungen war geplant | Die nächste Phase folgte auf die Wiedereröffnung für BTC |
| 30. September, 08:00 UTC | USDT-Auszahlungen waren geplant | Die Umsetzung späterer Phasen war in den verfügbaren Informationen nicht bestätigt |
| 2. Oktober, 08:00 UTC | Weitere Token, Fiat und P2P waren geplant | Der Wiedereröffnungsplan umfasste zusätzliche Dienste |
Die beiden ersten Transfers waren so angelegt, dass sie unter den bestehenden Schwellenwerten blieben. Die Testbeträge, 0,184 ETH und 193 TRX, lösten keine Warnmeldungen aus. Das zeigt, warum eine rein schwellenwertbasierte Überwachung gegen gestaffelte Angriffe wenig ausrichtet. Ein Angreifer kann zunächst prüfen, ob ein Autorisierungspfad funktioniert, und die Transaktionsgröße erhöhen, sobald das System stabil erscheint.
Bitgets Zeitleiste und die On-Chain-Untersuchung weichen bei den genauen Grenzen des Hauptabflusses leicht voneinander ab. Nach Darstellung der Bitget-CEO lief die zentrale Sequenz von 18:58 bis 20:09 UTC, während die On-Chain-Daten Schübe um 19:01 und 19:16 UTC zeigten. Diese Details ändern nichts am zentralen Befund: Der Angreifer verfügte weniger als drei Stunden lang über einen funktionierenden Auszahlungspfad, bevor der letzte Transfer beobachtet wurde.
In der ersten Stunde nach Wiedereröffnung der BTC-Auszahlungen wurden nach Angaben der Bitget-CEO mehr als 3.000 BTC abgewickelt. Dieses betriebliche Detail ist von Bedeutung, weil die Wiedereröffnung einer Börse nach einem Wallet-Vorfall ein zweites Kontrollproblem schafft. Die Plattform muss den Kundenzugang wiederherstellen, ohne den kompromittierten Freigabepfad erneut einzuführen oder zuzulassen, dass eine Welle legitimer Auszahlungen weitere nicht autorisierte Aktivitäten verdeckt.
Eine stufenweise Wiedereröffnung ist daher mehr als ein Zeitplan für den Kundenservice. Sie ist eine Eindämmungsstrategie, die eine Überwachung je Asset, den Wallet-Abgleich, die Rotation von Zugangsdaten und die schrittweise Validierung der Auszahlungskontrollen ermöglicht.
Welche Assets waren betroffen, und wie kam der Schaden von 387,5 Millionen US-Dollar zustande?
Bitgets abschließende Schadensschätzung belief sich auf rund 387,5 Millionen US-Dollar über 13 Assets und 11 Netzwerke, wobei unabhängige Tracker zwischen 7 und 11 betroffene Netzwerke zählten. XRP stellte mit rund 102,98 Millionen XRP im Wert von etwa 157,8 Millionen US-Dollar die größte Einzelposition dar, während auf ETH in der On-Chain-Aufschlüsselung rund 126,6 Millionen US-Dollar entfielen.
Öffentliche Mitteilungen und On-Chain-Untersuchungen ergaben folgende ungefähre Aufschlüsselung nach Assets:
| Asset | Ungefähre Menge oder ungefährer Wert | Beobachtetes Detail |
|---|---|---|
| XRP | 102,98 Millionen XRP, rund 157,8 Millionen US-Dollar | Größte Einzelposition |
| ETH | Rund 126,6 Millionen US-Dollar | Teil des Abflusses über mehrere Chains |
| USDT0 auf Arbitrum | Rund 19,7 Millionen US-Dollar | Stablecoin-Position auf Arbitrum |
| AVAX | Rund 16,8 Millionen US-Dollar | In der nachverfolgten Asset-Aufschlüsselung enthalten |
| BNB | Rund 9,9 Millionen US-Dollar | In der nachverfolgten Asset-Aufschlüsselung enthalten |
| TRX | Rund 7,0 Millionen US-Dollar | Wert von mehreren Trackern bestätigt |
| Gesamtschaden bei Bitget | Rund 387,5 Millionen US-Dollar | Nach Nachverfolgung der Zcash- und TRON-Transfers nach oben korrigiert |
Zu den gestohlenen Assets gehörten XRP, ETH, USDT, ZEC, ATOM, USDC, BNB, AVAX, TRX, ALGO, TIA und XAUt. Bitgets erste öffentliche Schätzung vom 24. September lag bei 351,6 Millionen US-Dollar. Die Schätzung stieg, nachdem weitere Zcash- und TRON-Transfers identifiziert worden waren.
XRP stellte die Rückgewinnung vor ein besonderes Problem, weil XRP von seinem Emittenten nicht eingefroren werden kann. Bis zum 26. September hatten rund 83 Millionen US-Dollar der gestohlenen XRP die Sammel-Wallets des Angreifers verlassen. Sobald Assets eine Sammeladresse verlassen und in Umtausch- oder Cross-Chain-Routen gelangen, müssen Ermittler sowohl den Geldern als auch den Diensten folgen, die sie verarbeiten.
Das Geldwäschemuster beruhte auf dem raschen Umtausch von Stablecoins in ETH, gefolgt von Swaps in BTC. Ermittler identifizierten THORChain als Hauptroute zu BTC, daneben tauchten Chainflip, deBridge, SwapKit und Wasabi CoinJoin im Geldwäschepfad auf. Am 28. September tauschte eine mit dem Hacker verbundene Wallet rund 2.390 ETH im Wert von etwa 6,3 Millionen US-Dollar über THORChain in Tranchen von rund 100 ETH gegen 75,2 BTC.
Die Reaktion legte ein Spannungsfeld zwischen dezentraler Infrastruktur und der Eindämmung von Vorfällen offen. THORChain lehnte Bitgets Bitte ab, den Hacker zu blockieren, und erklärte: „Ein Stopp ist kein selektives Einfrieren bestimmter Gelder.“ Chen entgegnete: „Dezentralisierung ist ein Designprinzip, kein Schutzschild, um den Transfer bekanntermaßen gestohlener Gelder zu ermöglichen.“
Dieser Schlagabtausch zeigt, warum die Abstimmung vor einem Vorfall wichtig ist. Dezentrale Protokolle haben möglicherweise keine generelle Möglichkeit, einen einzelnen Transfer zu identifizieren oder einzufrieren, ohne eine ganze Route zu beeinträchtigen. Zentralisierte Börsen, Stablecoin-Emittenten, Bridge-Betreiber und Intent-basierte Systeme wenden jeweils unterschiedliche Eingriffsregeln an. Eine Börse, die erst nach einem Exploit versucht, diese Regeln zu verstehen, hat in den ersten Stunden der Geldwäsche weniger Optionen.
Was zeigt der Bitget-Hack über Risiken bei Drittanbietern und auf der Freigabeebene?
Der Bitget-Hack zeigt, dass die Sicherheit einer Börse ebenso sehr von Drittanbieter-Software, internen Zugangsdaten, der Darstellung von Transaktionen und der Risikorichtlinie abhängt wie von der kryptografischen Schlüsselverwahrung. Bitget, Bybit, DMM Bitcoin und WazirX weisen ein wiederkehrendes Muster auf: Angreifer kompromittierten einen vertrauenswürdigen Anbieter oder eine Freigabeebene, sodass eine bösartige Transaktion für den Signatur- oder Autorisierungsprozess legitim erschien.
| Vorfall | Datum | Kompromittierte Ebene | Gemeldeter Schaden oder Umfang | Zentrale Lehre |
|---|---|---|---|---|
| Bitget | 24. September 2026 | Sicherheitsprodukt eines Drittanbieters und Wallet-Backend | Rund 387,5 Millionen US-Dollar | Gefälschte Auszahlungsbefehle umgingen die Risikokontrollen |
| Bybit | 21. Februar 2025 | Entwicklerrechner und Signaturoberfläche von Safe{Wallet} | Rund 1,46 Milliarden US-Dollar | Schadcode veränderte die Umgebung für die Transaktionsfreigabe |
| DMM Bitcoin | Mai 2024 | Mitarbeiter eines Wallet-Software-Anbieters und Signatur-Workflow | Rund 305 Millionen bis 308 Millionen US-Dollar | Die Kompromittierung eines Anbieters ermöglichte nicht autorisierte Wallet-Aktivitäten |
| WazirX | 18. Juli 2024 | Multisig-Wallet-Contract und Verwahrungs-Workflow | Rund 235 Millionen US-Dollar | Unterzeichner gaben Transaktionen frei, nachdem der Contract verändert worden war |
| Coinbase | Offengelegt im Mai 2025 | Support-Mitarbeiter im Ausland und Kundendaten | Geschätzte Behebungskosten von 180 Millionen bis 400 Millionen US-Dollar | Eine Kompromittierung von Kundendaten kann auch ohne Schlüsseldiebstahl ein erhebliches operatives Risiko schaffen |
Das gemeinsame Versagen liegt nicht in gebrochener Kryptografie. Es liegt im Verlust eines vertrauenswürdigen Kontexts rund um eine Transaktion. Ein Unterzeichner sieht womöglich eine gültige Anforderung, ein vertrautes Zielformat und einen normal wirkenden Freigabeablauf, während die zugrunde liegende Anweisung ausgetauscht oder manipuliert wurde.
Für Börsen erfordert das Kontrollen an mehreren unabhängigen Punkten:
- Isolierung von Anbietern: Sicherheitsprodukte von Drittanbietern sollten keinen unnötigen Zugriff auf die Erzeugung von Wallet-Befehlen oder auf privilegierte Zugangsdaten haben.
- Abschottung von Zugangsdaten: Interne Zugangsdaten sollten auf einzelne Funktionen beschränkt sein, nach verdächtigen Aktivitäten rotiert werden und standardmäßig keine umfassenden Auszahlungen über mehrere Chains autorisieren können.
- Unabhängige Rekonstruktion der Transaktion: Die Freigabeoberfläche sollte die Transaktionsdetails aus einer unabhängigen Quelle ableiten, statt demselben Backend zu vertrauen, das die Anforderung erstellt hat.
- Vielfalt der Richtlinien: Große Auszahlungen sollten Regeln durchlaufen, die getrennt vom operativen Wallet-Backend gepflegt werden.
- Unveränderliche Protokollierung: Logs sollten außerhalb der kompromittierten Umgebung gespeichert werden und Ereignisse der Erstellung, Änderung, Freigabe, Signierung und Übermittlung von Befehlen umfassen.
- Canary-Transfers: Kleine Testtransfers sollten nicht allein deshalb als unbedenklich gelten, weil sie unter einem Betragsschwellenwert liegen. Wiederholte Tests, ungewöhnliche Ziele und Cross-Chain-Muster müssen miteinander korreliert werden.
- Notabschaltung: Die Börse muss die Signierung stoppen und Wallet-Dienste isolieren können, ohne davon unabhängige Handels- und Einzahlungssysteme vom Netz zu nehmen.
Bitget erklärte, betroffene Server isoliert, interne Zugangsdaten widerrufen und neu ausgestellt sowie den Zugriff auf sensible Systeme neu strukturiert zu haben. Die Börse erklärte außerdem, die Schwachstelle sei behoben. Diese Schritte dienen der Eindämmung, eine belastbare Überprüfung muss jedoch testen, ob sich dieselben Transaktionsdaten vor der Freigabe weiterhin manipulieren lassen.
Sokens Smart-Contract-Audits und Blockchain-Sicherheitsleistungen sind für diese Kontrollgrenze relevant, weil Wallet-Infrastruktur häufig Smart Contracts, Signaturdienste, Backend-APIs, Schlüsselverwaltungssysteme und Werkzeuge von Drittanbietern kombiniert. Eine auf Solidity-Code beschränkte Prüfung würde nicht testen, ob ein kompromittierter Dienst die Daten verändern kann, die ein Unterzeichner sieht.
Wie wirksam waren die Rückgewinnungsmaßnahmen und wie belastbar die Zuschreibungen?
Die Rückgewinnungsmaßnahmen führten bis zum 29. September 2026 nur in begrenztem Umfang zu bestätigten Rückerstattungen, während die Zuschreibung probabilistisch und nicht offiziell blieb. Circle und Tether froren insgesamt rund 339.100 US-Dollar ein, und NEAR Intents teilte mit, sein Screening habe versuchte Transfers mit Bitget-Bezug im Umfang von mehr als 50 Millionen US-Dollar abgewiesen und 503.000 US-Dollar eingefroren. Eine Rückführung gestohlener Gelder an Bitget war nicht bestätigt worden.
Folgende Rückgewinnungsmaßnahmen wurden gemeldet:
| Reagierende Stelle oder Mechanismus | Gemeldete Maßnahme | Betrag |
|---|---|---|
| Circle und Tether | USDC und USDT eingefroren | Insgesamt rund 339.100 US-Dollar |
| Stablecoin-Guthaben | 239.113,50 USDT und 99.989,91 USDC eingefroren | In der Gesamtsumme von 339.100 US-Dollar enthalten |
| NEAR Intents | Versuchte Transfers mit Bitget-Bezug abgewiesen | Mehr als 50 Millionen US-Dollar |
| NEAR Intents | Versuchte Transfers mit Bitget-Bezug eingefroren | 503.000 US-Dollar |
| Bitget | Belohnung für Eingreifen und Rückgewinnung ausgelobt | 5 % für das Einfrieren plus 5 % für die Rückgewinnung |
Der Unterschied zwischen abgewiesenen Transfers und zurückgewonnenen Geldern ist entscheidend. Ein Screening-System kann verhindern, dass Assets in eine bestimmte Route gelangen, ohne Gelder zurückzuholen, die der Angreifer bereits kontrolliert. Ebenso erfassen Einfrierungen durch Emittenten ausgewählte Stablecoin-Guthaben, nicht aber XRP, ETH, BTC oder Assets, die sich durch erlaubnisfreie (permissionless) Infrastruktur bewegen.
Auch die Zuschreibung verlangt eine sorgfältige Wortwahl. Analysehäuser bewerteten den Angriff als mit hoher Wahrscheinlichkeit mit Nordkorea verbunden und stellten Überschneidungen mit Wallets fest, die bei den Hacks von Bybit und AFX Bridge verwendet wurden. Eine weitere Einschätzung beschrieb ein TraderTraitor-ähnliches Syndikat, nahm jedoch keine abschließende Zuschreibung des Bitget-Vorfalls vor. Stand 29. September 2026 hatte keine staatliche Behörde eine formelle Zuschreibung des Angriffs vorgenommen.
Das übergeordnete Muster ist erheblich. Mit Bitget überstieg der erfasste Krypto-Diebstahl mit Nordkorea-Bezug im Jahr 2026 die Marke von 1 Milliarde US-Dollar bei mehr als 50 Vorfällen. Eine Branchenschätzung bezifferte die Gesamtsumme auf 1,04 Milliarden US-Dollar, womit 2026 das Jahr mit der zweithöchsten Schadenssumme nach 2025 ist, für das 1,68 Milliarden US-Dollar geschätzt wurden.
Die CEO von Bitget sagte, der Angreifer sei sehr wahrscheinlich eine nordkoreanische Gruppe. Diese Aussage ist ein operatives Risikosignal, kein Ersatz für eine formelle Zuschreibung. Sicherheitsteams sollten die verfügbaren Wallet-Überschneidungen und Geldwäschemuster nutzen, um die Erkennung auszurichten, und zugleich in öffentlichen Aussagen und rechtlichen Verfahren die Unsicherheit wahren.
Bitget erklärte außerdem, dass 100 % der Nutzergelder durch den Bitget Protection Fund gedeckt seien, der 5.500 BTC hielt, zum damaligen Zeitpunkt etwa 464 Millionen US-Dollar wert. Die Börse verpflichtete sich, den Fonds innerhalb einer Woche aus Unternehmensreserven von mehr als 1,4 Milliarden US-Dollar auf mindestens 300 Millionen US-Dollar aufzufüllen. Diese Zusagen betreffen die Zahlungsfähigkeit gegenüber den Kunden, sie ändern jedoch nichts an der Notwendigkeit, die Freigabearchitektur zu reparieren, die die Auszahlungsbefehle passieren ließ.
Der BGB-Token fiel nach dem Vorfall um etwa 3 % bis 7 % und erreichte ein Tief von rund 1,89 bis 1,93 US-Dollar, bevor er sich auf etwa 1,97 US-Dollar erholte. Die Marktreaktion spiegelte somit neben dem unmittelbaren Wallet-Verlust auch ein Vertrauensrisiko wider.
Bitgets Reaktion lässt sich zusammen mit weiterer Forschung zu Sicherheitsvorfällen über Sokens Security-Research-Hub verfolgen, während Organisationen, die die Governance von Börsen überprüfen, technische Audits und Unterstützung bei der Incident Response nutzen können, um Grenzen von Zugangsdaten, Transaktionsintegrität und Notfallkontrollen zu testen.
Was sollten Börsen nach dem Bitget-Exploit ändern?
Börsen sollten den Bitget-Exploit als Versagen der Autorisierungsintegrität behandeln und jedes System testen, das eine Auszahlung erstellt, umwandelt, anzeigt, freigibt, signiert oder übermittelt. Der Schutz von Cold Wallets und privaten Schlüsseln bleibt notwendig, der Bitget-Vorfall zeigt jedoch, dass das Risiko bei Hot- und Warm-Wallets auch von vertrauenswürdigen Transaktionsmetadaten und unabhängigen Freigabepfaden abhängt.
Ein praxistaugliches Programm nach einem Vorfall sollte in dieser Reihenfolge vorgehen:
- Den Befehlspfad rekonstruieren. Erfassen Sie den gesamten Weg von der Auszahlungsanforderung bis zur Übermittlung, einschließlich Drittanbieter-Produkten, Dienstkonten, Queues, APIs, Signatursystemen und Abgleich.
- Zugangsdaten umfassend widerrufen. Bitget hat interne Zugangsdaten widerrufen und neu ausgestellt. Andere Börsen sollten vererbte Berechtigungen, inaktive Dienstkonten und über mehrere Umgebungen hinweg geteilte Zugangsdaten ermitteln.
- Transaktionserstellung von der Transaktionsfreigabe trennen. Die Freigabeoberfläche sollte Ziel, Asset, Betrag, Chain, Nonce und Richtlinienklassifizierung unabhängig prüfen.
- Beweise außerhalb der Produktion sichern. Da der Angreifer Spuren der eingeschleusten Befehle gelöscht hat, müssen Audit-Logs in eine Umgebung repliziert werden, die operative Administratoren nicht überschreiben können.
- Risikoschwellen erneut testen. Die Testtransfers über 0,184 ETH und 193 TRX blieben unter den Schwellenwerten. Die Erkennung sollte Wert, Neuheit des Ziels, Zeitpunkt, Wiederholung, Cross-Chain-Verhalten und den Kontext der Zugangsdaten kombinieren.
- Den Abschaltprozess üben. Bitget isolierte Server, überführte verbleibende Gelder in Cold Storage und schaltete die Signierung ab. Diese Maßnahmen sollten vor einem Vorfall geprobt und nicht erst währenddessen improvisiert werden.
- Die externe Eskalation vorab festlegen. Stablecoin-Emittenten, Bridges, Intent-Systeme, Analyseanbieter und Strafverfolgungsbehörden sollten in den Incident-Playbooks berücksichtigt sein.
- In kontrollierten Phasen wiedereröffnen. Eine Wiedereröffnung Asset für Asset erlaubt es der Überwachung, jeden Wallet-Pfad zu validieren, bevor Auszahlungen in größerem Umfang wieder aufgenommen werden.
Ein nützliches Kontrollziel ist einfach: Kein einzelnes kompromittiertes Backend sollte in der Lage sein, eine Auszahlungsanforderung zu erstellen, sie einem Freigebenden zu beschreiben, die Risiko-Engine zufriedenzustellen und die Signierung auszulösen. Dieses Ziel gilt unabhängig davon, ob die Börse Multisignatur-Wallets, Hardware-Sicherheitsmodule, Smart-Contract-Vaults oder Verwahrungsinfrastruktur von Drittanbietern einsetzt.
Der Bitget-Vorfall stützt zudem eine grundsätzlichere Unterscheidung zwischen Verwahrungssicherheit und Autorisierungssicherheit. Verwahrungssicherheit fragt, ob ein Angreifer an Schlüssel gelangen kann. Autorisierungssicherheit fragt, ob sich das System dazu bringen lässt, mit legitimen Schlüsseln die falsche Transaktion freizugeben. Börsen, die nur die erste Kategorie messen, können melden, dass die privaten Schlüssel sicher sind, und zugleich die Kontrolle über die Gelder verlieren, die mit diesen Schlüsseln freigegeben werden.
Bitgets Zeitplan für die Wiedereröffnung, die Zusagen zum Protection Fund und die Erneuerung der Zugangsdaten betreffen die Betriebskontinuität und den Kundenschutz. Die nächste technische Frage lautet, ob die Börse nachweisen kann, dass die den Freigebenden angezeigten Transaktionsdaten nun unabhängig vom kompromittierten Backend erzeugt und überprüft werden. Dieser Nachweis sollte Teil jedes öffentlichen Berichts nach dem Vorfall sein.
Bitgets Verlust, der Abfluss über mehrere Chains in 17 Transaktionen und die begrenzte bestätigte Rückgewinnung verweisen alle auf dieselbe Kontrolllücke: Vertrauenswürdige Software und vertrauenswürdiger Transaktionskontext müssen als Angriffsflächen behandelt werden. Der konkrete nächste Schritt für den Betreiber einer Börse besteht darin, eine Auszahlung von Anfang bis Ende nachzuverfolgen und anschließend zu versuchen, die angezeigten Transaktionsdaten zu verändern, ohne die endgültige Signaturanforderung zu ändern. Erkennen die Überwachungs- und Freigabeebenen diese Abweichung nicht, bleibt die Wallet-Architektur angreifbar.
Soken kann diese Arbeit durch Sicherheitsbewertungen für Börsen und Penetrationstests unterstützen, wobei die Prüfung auf den Autorisierungspfad ausgerichtet ist, der Werkzeuge von Drittanbietern mit dem Betrieb von Hot- und Warm-Wallets verbindet.