Bitget: 387,5-Mio.-Dollar-Off-Chain-Sicherheitsverletzung – mehr als nur Keys und Contracts

Am 24. September 2026 wurden ungefähr 387,5 Mio. USD von einigen operativen Wallets von Bitget über Ethereum und andere EVM-Netzwerke, XRP Ledger, Zcash und TRON transferiert. Bitget bezeichnete die betroffenen Wallets als Hot- und Warm-Wallets. Die On-Chain-Transaktionen trugen gültige Wallet-Signaturen. Bitget führte den Einstiegspunkt auf eine Schwachstelle in einem Sicherheitsprodukt eines Drittanbieters zurück und erklärte, dass private Schlüssel und Cold Wallets nicht kompromittiert wurden [1, 2].

Basierend auf öffentlichen Offenlegungen und On-Chain-Beweisen, die bis zum 29. September 2026, 16:35 UTC, verfügbar waren, fasst der erste Teil die offengelegte Angriffssequenz, die anschließenden Vermögensbewegungen, die Wiederherstellung des Dienstes und die unterschiedlichen Reaktionen der Ökosystem-Teilnehmer zusammen. Der zweite Teil kombiniert diese Beobachtungen mit unserer Sicherheitserfahrung, um ein Defense-in-Depth-Rahmenwerk für Krypto-Institutionen zusammen mit praktischen Sicherheitsempfehlungen vorzustellen.

1. Vom Off-Chain-Zugriff zum On-Chain-Verlust und zur Wiederherstellung

Bitget hat den Einstiegspunkt auf eine Schwachstelle in einem Sicherheitsprodukt eines Drittanbieters zurückgeführt, hat jedoch weder das Produkt noch die betroffene Komponente noch den technischen Exploit-Mechanismus offengelegt [1, 2]. Die öffentliche Darstellung beschreibt den nachgelagerten Pfad als internen Zugriff, gefälschte Auszahlungsbefehle, umgangene Risikoprüfung, gültige Signaturen und On-Chain-Transfers.

1.1 Angriffszeitleiste und Zuordnung

Die von Bitget-CEO Gracy Chen berichtete Zeitleiste zeigt zusammen mit den On-Chain-Aufzeichnungen, wie sich der Vorfall entwickelte [3]:

• 18:31 UTC, 24. September: Die ersten Bewegungen betrugen 0,84 ETH und 93 TRX. Beide lagen unterhalb des Risikokontroll-Schwellenwerts der Börse.
• 18:58–20:09 UTC: Chen beschrieb siebzehn größere Transfers über Ethereum, XRP Ledger, Zcash, BNB Chain, Base, Arbitrum, Optimism und Avalanche mit einem Gesamtwert von ungefähr 361 Mio. USD [3]. On-Chain-Aufzeichnungen zeigen zudem einen Transfer von 20,59 Mio. TRX auf TRON um 19:16 UTC.
• Sieben Minuten nach dem ersten großen Transfer: Das Abstimmungssystem von Bitget stellte eine Diskrepanz fest und stoppte von Nutzern initiierte Auszahlungen. In der Zeitleiste von Bitget wird diese Maßnahme von der späteren Abschaltung der Auszahlungs- und Signaturdienste der Wallets um 21:44 UTC unterschieden [1].

Chen erklärte, dass der Angreifer Spuren gelöscht habe, die von den betrügerischen Befehlen hinterlassen wurden [3]. Zur vorläufigen Zuordnung sagte sie zudem, dass das IP-Adress-Verhalten und die On-Chain-Muster stark mit bekannten nordkoreanischen Hackergruppen übereinstimmten [4]. Dies bleibt eine vorläufige Zuordnung und kein endgültiges Ergebnis; die offizielle Vorfallsseite von Bitget hat keine verantwortliche Gruppe benannt, und die Untersuchung dauert an [1].

1.2 Mittelfluss und operative Wiederherstellung

On-Chain-Aufzeichnungen, die im offiziellen Tracker von Bitget widergespiegelt werden, zeigen, dass gestohlene Stablecoins innerhalb von Minuten in ETH umgewandelt wurden [5]. Anders als USDT oder USDC bieten native Assets wie ETH keine vom Emittenten kontrollierte Einfrierfunktion. Dieses Verhalten steht im Einklang mit dem Versuch, die Gefahr eines vom Emittenten kontrollierten Einfrierens zu verringern, belegt jedoch weder die Identität noch den Erfahrungsgrad des Angreifers.

Der offizielle betroffene Betrag stieg später auf ungefähr 387,5 Mio. USD, da Bitget eine vollständigere Abrechnung einbezog, die Zcash und TRON umfasste [1]. Bitget veröffentlichte Angreiferadressen, ein Portal zur Meldung von Wiederherstellungen und eine Adressen-API [1, 6], zusammen mit der Echtzeit-Tracking-Website [5]. Die Bestandsansicht der Website zeigt die aktuelle Verteilung, während der Mittelfluss-Graph nachgelagerte Adressen, Dienste, Bridges und Cross-Chain-Routen abbildet.

Um 16:35:28 UTC am 29. September meldete der offizielle Tracker 322,67 Mio. USD an aktuellen Beständen des Angreifers, rund 632.700 USD eingefroren über acht Einträge, 312.500 USD an vom Emittenten einfrierbaren Stablecoins und 55,87 Mio. USD in Bewegung oder noch in Analyse [5]. Die eingefrorene Gesamtsumme umfasste 293.507 USD bei NEAR Intents (das während der Ausführung ungefähr 503.000 USD eingefroren gemeldet hatte [12]), 239.242 USD, die von Tether eingefroren wurden, und 99.990 USD, die von Circle eingefroren wurden. Öffentliche Quellen gleichen die Zahlen von NEAR Intents nicht miteinander ab.

Zum gleichen Zeitpunkt zeigte der Adressen-Explorer zugeordnete Adressbestände, die sich auf BTC (288,51 Mio. USD), ZEC (28,91 Mio. USD) und ETH (7,17 Mio. USD) konzentrierten [5]. Der Explorer verwendet einen anderen Klassifizierungsumfang als die Übersicht, sodass seine Gesamtsumme von 327,69 Mio. USD auf Adressebene nicht direkt mit der Zahl von 322,67 Mio. USD der aktuellen Bestände in der Übersicht vergleichbar ist.

Auch die operative Wiederherstellung machte Fortschritte. Bitget nahm die ETH-Auszahlungen um 08:00 UTC am 29. September wieder auf. Bis 09:00 UTC meldete das Unternehmen ungefähr 9.674 ETH an Zuflüssen und 9.023 ETH an Abflüssen, sodass die Zuflüsse die Abflüsse um rund 651 ETH überstiegen [7].

1.3 Nachdem die Mittel abgeflossen sind: Reaktion der Community

Sobald Vermögenswerte die Wallets der betroffenen Institution verlassen, hängt die Wiederherstellung von Organisationen außerhalb der ursprünglichen Sicherheitsgrenze ab. Bitget öffnete seine Tracing-Daten und startete eine Belohnung für geeignete Unterstützung, die Mittel einfror oder wiederherstellte [1, 6]. Binance erklärte, dass sein Sicherheitsteam Informationen austauschte, Mittel verfolgte und die Wiederherstellung unterstützte [8]. Bybit-CEO Ben Zhou bot Unterstützung an und aktualisierte die Wiederherstellungsplattform LazarusBounty, wobei er anmerkte, dass Bitget Bybit nach dessen eigenem Vorfall 2025 geholfen hatte [9]. Die Reaktion von Bybit setzte ein Muster gegenseitiger Unterstützung zwischen den beiden Börsen fort.

Infrastrukturanbieter hatten aufgrund ihrer technischen Designs und Governance-Modelle unterschiedliche Optionen. Bitget bat THORChain, öffentlich gelisteten und aktiv verfolgten Angreiferadressen den Dienst zu verweigern. Gracy Chen argumentierte, dass „Dezentralisierung ein Designprinzip ist, kein Schutzschild zur Erleichterung bekannter gestohlener Gelder“ [10]. THORChain erklärte, dass es kein selektives Blacklisting unterstützt: Seine Notfallkontrollen können umfassendere Aktivitäten oder eine Chain-Route stoppen, nicht jedoch eine einzelne Adresse oder Transaktion. Einige gestohlene Vermögenswerte bewegten sich weiterhin über das Netzwerk von ETH zu BTC [11].

NEAR Intents berichtete von einer anderen Reaktion. Sein Risikosystem SHIELD identifizierte und blockierte über 50 Mio. USD an versuchten Flüssen, die mit den Angreifern verknüpft waren, nach Herausfilterung doppelter Versuche; ungefähr 503.000 USD wurden während der Ausführung eingefroren, während etwa 166.000 USD durchgingen. NEAR Intents verzichtete zudem auf seinen Anteil an der Wiederherstellungsbelohnung von Bitget [12]. Die Zahl von 50 Mio. USD stellt versuchte Flüsse dar, die das System nicht verarbeitet hat, nicht eingefrorene oder wiederhergestellte Beträge.

Große Cross-Chain-Wiederherstellungen erfordern in der Regel mehrere Beteiligte. Börsen können Einzahlungen oder Auszahlungen zurückhalten, Stablecoin-Emittenten können Token einfrieren, Routing-Dienste können zugeordnete Flüsse ablehnen, sofern ihr Design dies zulässt, und Basisprotokolle können möglicherweise nur überwachen und Indikatoren teilen. Eine wirksame Koordination beginnt damit, dass jeder Beteiligte darlegt, welche Maßnahme er ergreifen kann und welche Beweise er benötigt.

Eingriffe bergen ebenfalls Risiken. Eine falsche Zuordnung kann unschuldige Nutzer blockieren, während dauerhafte Blacklists sich von Werkzeugen zur Vorfallsreaktion zu umfassenderen Mechanismen zur Transaktionsbeschränkung ausweiten können. Eine vertretbare Reaktion stützt sich auf bestätigte Beweise, eng begrenzte und zeitlich befristete Einschränkungen, ein Einspruchsverfahren, transparente Aktionsprotokolle und eine Überprüfung nach dem Vorfall. Wo einem System selektive Kontrollen fehlen, hilft eine transparente Offenlegung der Fähigkeiten dabei, realistische Erwartungen zu setzen. Wo Ermessensspielraum besteht, können veröffentlichte Kriterien und eine rechenschaftspflichtige Entscheidungsfindung konsistente Reaktionen unterstützen.

2. Den Exploit-Pfad durchbrechen und eindämmen: Ein systematisches Defense-in-Depth-Sicherheitsrahmenwerk

Aufbauend auf dem in Abschnitt 1 dokumentierten Vorfallpfad und der Reaktion darauf sowie unserer Erfahrung und Expertise schlagen wir das nachfolgende zweischichtige Rahmenwerk vor. Weitere Informationen dazu, warum Code-Audits und Monitoring nicht den gesamten Pfad der Geldbehandlung abdecken, finden Sie unter Why Crypto Institutions Need Blockchain Penetration Testing [13].

• Der offengelegte Exploit-Pfad verläuft vom Sicherheitsprodukt des Drittanbieters bis zu den On-Chain-Transfers.
• Die Präventions- und Erkennungsschicht des Rahmenwerks umfasst die ersten drei Sicherheitspraktiken. Die Abschnitte 2.1 und 2.2 untersuchen, wie Kontrollen für privilegierten Zugriff und eine unabhängige Verifizierung der Absicht verhindern können, dass ein Fuß in der Infrastruktur bis zur Signierung vordringt. Abschnitt 2.3 behandelt die Überwachung von Vermögensflüssen, die ausgehende Anomalien erkennt und eskaliert und riskante eingehende Einzahlungen zurückhalten kann.
• Die Reaktions- und Wiederherstellungsschicht umfasst die vierte Praktik. Sie kann durch ein Signal mit hoher Verlässlichkeit aus einem beliebigen Teil der Präventions- und Erkennungsschicht oder durch einen operativen Fehler ausgelöst werden. Abschnitt 2.4 behandelt die unabhängige Fähigkeit, betroffene Vorgänge zu pausieren oder gefährdete Vermögenswerte an verifizierte sichere Ziele zu übertragen.

Jeder Unterabschnitt folgt derselben Struktur: das Sicherheitsziel, das durch den Vorfallpfad offengelegte Risiko und die präventiven, detektiven oder reaktiven Fähigkeiten, die Institutionen aufbauen können. Diese Praktiken sollten sich auf getrennte Befugnisse und Nachweise stützen. Zusammen verringern sie die Abhängigkeit von einer einzelnen Schutzmaßnahme und geben Institutionen vorbereitete Optionen zur Eindämmung von Verlusten an die Hand.

2.1 Privilegierter Zugriff und Auszahlungsbefehle

Das Ziel besteht darin zu verhindern, dass die Kompromittierung von Infrastruktur oder privilegierten Systemen ausreicht, um einen vertrauenswürdigen Auszahlungsbefehl zu erzeugen.

Ein Produkt eines Drittanbieters benötigt keinen direkten Zugriff auf die Signierung, um die Vermögensbewegung zu beeinflussen. Der Zugriff auf Anmeldedaten oder Systeme, die Auszahlungsbefehle formen, kann ausreichen, um zu bestimmen, was ein anderes System signiert. Solche Produkte gehören zur Web3-Angriffsfläche auf institutioneller Ebene [14]. Ihr Risiko hängt von dem Wert ab, den sie beeinflussen können, und den Systemen, die sie erreichen können.

Zu den erforderlichen Kontrollen gehören das Prinzip der geringsten Rechte, Netzwerksegmentierung, eingeschränkte Update- und Verwaltungspfade, kurzlebige Anmeldedaten, manipulationssichere Protokolle und ein getestetes Widerrufsverfahren. Interner Zugriff darf nicht automatisch die Fähigkeit gewähren, einen vertrauenswürdigen Auszahlungsbefehl zu erzeugen. Jeder Befehl sollte einen authentifizierten Ursprung, eine unveränderliche Anfrage-ID und eine signierte oder anderweitig authentifizierte Konfigurationsversion tragen. Befehlserstellung, Genehmigung, Signierung und Übertragung sollten getrennten Befugnissen zugeordnet sein, und nachgelagerte Systeme sollten Befehle mit unbekanntem Ursprung, veralteten Konfigurationen oder unvollständigen Bindungen ablehnen.

2.2 Auszahlungsabsicht und Signierung

Das Ziel besteht darin zu verhindern, dass ein gefälschter oder manipulierter Auszahlungsbefehl zu einer gültig signierten Transaktion wird.

Eine gültige Signatur bestätigt, dass der entsprechende private Schlüssel die Transaktionsdaten signiert hat; sie belegt nicht, dass die zugrunde liegende Auszahlungsanfrage echt war oder unabhängig genehmigt wurde.

Die Signaturgrenze sollte die erwartete Transaktion aus einer unabhängigen, vertrauenswürdigen Aufzeichnung rekonstruieren und jedes Feld vergleichen, das Werte verschieben kann. Mindestens sollte die Genehmigung Chain, Asset, Betrag, Empfänger, Quell-Wallet, Transaktions-Nonce, Gebührengrenzen, Ablaufzeit und die ursprüngliche Auszahlungs- oder Treasury-Anfrage binden.

Die Komponente, die eine Auszahlung erstellt, sollte nicht die einzige Quelle sein, die zu ihrer Autorisierung verwendet wird. Die Richtlinienauswertung sollte unabhängige Konto- und Risikodaten heranziehen, während das Signatursystem überprüft, ob die endgültigen Transaktionsdaten mit der genehmigten Absicht übereinstimmen. Der aktive Satz autorisierter Signierer, der Signaturschwellenwert, die Transaktions-Nonce und die Konfiguration müssen mit dem erwarteten Produktionszustand übereinstimmen. Menschliche Prüfer benötigen eine normalisierte Transaktionsansicht, die aus den exakten zu signierenden Bytes erzeugt wird, und keine veränderliche, vom anfordernden Backend bereitgestellte Zusammenfassung.

2.3 Ausgehende und eingehende Vermögensflüsse

Das Ziel besteht darin zu erkennen, wenn die tatsächliche Vermögensbewegung von der unabhängig rekonstruierten Geschäftsabsicht abweicht.

Eine Krypto-Institution kann sowohl Quelle als auch Ziel von Kryptowährungsflüssen sein. Die Überwachung ausgehender Flüsse sollte die tatsächliche Chain-Aktivität mit einem unabhängig rekonstruierten Satz genehmigter Auszahlungen vergleichen. Um die Unabhängigkeit zu wahren, sollte sich die Überwachung nicht ausschließlich auf denselben Befehl verlassen, der vom Auszahlungssystem erzeugt wurde.

Die Überwachung sollte erwartete Chain, Asset, Betrag, Empfänger, Zeitpunkt und Wallet aus einer separaten Geschäftsaufzeichnung ableiten. Sie sollte Verhalten über Dimensionen hinweg aggregieren, die transaktionsbezogene Limits übersehen:

• Kleine Testtransfers, gefolgt von schneller Eskalation.
• Wiederverwendung neuer Empfänger über Konten, Assets oder Chains hinweg.
• Ein plötzlicher Anstieg der Auszahlungsgeschwindigkeit oder des Gesamtrisikos.
• Gleichzeitige Abflüsse aus mehreren operativen Wallet-Ebenen.
• Eine Verschiebung hin zu nativen Assets, die schwerer einzufrieren sind.
• Unterschiede zwischen der genehmigten Anfrage, den signierten Transaktionsdaten und der übertragenen Transaktion.

Kontrollen sollten den kumulativen Betrag, die Geschwindigkeit, ob ein Ziel neu ist, die Wallet-Ebene, wie leicht ein Asset umgewandelt werden kann, und das Cross-Chain-Verhalten über ein Zeitfenster hinweg bewerten. Die anfänglichen ETH- und TRX-Bewegungen von Bitget verdeutlichen den Wert einer Bewertung von Transaktionen als Sequenz und nicht nur als isolierte Ereignisse [3]. Eine Abweichung mit hoher Verlässlichkeit sollte den in Abschnitt 2.4 beschriebenen Notfallreaktionspfad auslösen. Anomalien mit geringerer Verlässlichkeit erfordern möglicherweise eine zweite Genehmigung, eine Abkühlungsphase für das Ziel, ein reduziertes Limit oder eine vorübergehende Auszahlungssperre.

Die Überwachung eingehender Flüsse sollte Einzahlungen vor der Gutschrift prüfen und vor einer Auszahlung erneut prüfen. Sie sollte Mittel durch Bridges, dezentrale Börsen (DEXs), absichtsbasierte Routing-Dienste und Zwischenadressen verfolgen, da ein Abgleich nur mit der ersten Angreiferadresse nicht ausreicht. Übereinstimmungen mit hoher Verlässlichkeit erfordern ein dokumentiertes Verfahren zum Zurückhalten von Mitteln, zur Untersuchung der Übereinstimmung, zur Bearbeitung von Einsprüchen und zum Abschluss jeder rechtlichen Übergabe.

Der schnelle Informationsaustausch zwischen Börsen macht aus der Überwachung eingehender Flüsse einen Netzwerkeffekt. Eine Institution stellt den Vorfall möglicherweise fest, während eine andere die Erlöse sieht. Gemeinsam genutzte maschinenlesbare Indikatoren und aktuelle Kontakte verkürzen die Zeitspanne zwischen Zuordnung und Handlung.

2.4 Notfall-Pause und Vermögensübertragung

Das Ziel besteht darin, das verbleibende Risiko einzudämmen, sobald ein Sicherheitssignal mit hoher Verlässlichkeit oder ein operativer Fehler festgestellt wird.

Signale können Verletzungen des privilegierten Zugriffs oder der Befehlsintegrität, Abweichungen bei Auszahlungsabsicht oder Signierung, abnormale ausgehende, eingehende oder sonstige On-Chain-Aktivitäten sowie Abstimmungsfehler umfassen. Die Institution sollte dann in der Lage sein, betroffene Signatur-, Übertragungs-, Auszahlungs- oder Wallet-Vorgänge zu pausieren. Wenn Vermögenswerte weiterhin gefährdet sind, sollte sie diese außerdem von der verdächtigen Wallet zu vordefinierten sicheren Zielen verschieben können. Eine Pause verschafft Ermittlungszeit; eine Übertragung verringert das verbleibende Risiko.

• Unabhängige Pausenbefugnis: Die Pause muss verfügbar bleiben, selbst wenn das Hauptverwaltungssystem kompromittiert ist. Ihr Umfang sollte eng genug sein, um eine bestimmte Chain, Wallet, Asset oder einen Vorgang zu stoppen, sofern die Architektur dies zulässt. Aktivierung und Freigabe erfordern authentifizierte Befugnis, manipulationssichere Aufzeichnungen, explizite Wiederaufnahmekriterien und Tests unter beeinträchtigten Bedingungen.
• Kontinuität des Übertragungspfads: Eine Konfigurationsänderung darf den alten Notfallpfad nicht ungültig machen, bevor sein Ersatz bereitgestellt, autorisiert, signiert, gespeichert und getestet wurde.
• Bereitschaft ausführbarer Transaktionen: Gespeicherte Notfalltransaktionen können durch Nonce-Änderungen, unzureichende native Token-Guthaben zur Bezahlung von Gebühren, Änderungen des Quell-Asset-Guthabens, Änderungen im Gebührenmarkt, die signierte Gebührengrenzen unbrauchbar machen, Ablauf oder Konfigurationsaktualisierungen veralten. Bereitschaftsprüfungen sollten diese Abhängigkeiten fortlaufend validieren. Vollständig signierte Transaktionsdaten sollten verschlüsselt und zugriffskontrolliert bleiben, bis die Notfallmaßnahme genehmigt und zur sofortigen Übertragung bereit ist.
• Abdeckung und Failover: Jede operative Wallet, Chain, natives Asset und unterstützter Token benötigt primäre und alternative Übertragungspfade. Auch die Infrastruktur für Übertragung und Verifizierung benötigt Redundanz über Remote-Procedure-Call-Endpunkte (RPC), Betriebssysteme und manuelle Wiederherstellungswerkzeuge hinweg.
• Abschlussprüfungen und Übungen: Das Notfallreaktionsverfahren sollte den Abschluss durch bestätigte On-Chain-Ausführung, asset-bezogene Verifizierung, Prüfungen des Restguthabens und Abstimmung zwischen dem On-Chain-Zustand und internen Aufzeichnungen definieren. Es sollte außerdem Chain-Reorganisationen und fehlgeschlagene Transaktionen erkennen. Regelmäßige Übungen sollten die vollständige Wiederherstellungszeit von der Erkennung bis zur endgültigen Guthabenverifizierung messen.

Ein autorisierter Blockchain-Penetrationstest kann übergreifende Annahmen in Beweise umwandeln, indem er die laufende Umgebung innerhalb eines vereinbarten Umfangs prüft [15]. Für Tests in der Produktionsumgebung sollten dokumentierte Rules of Engagement (RoE) vor Testbeginn Autorisierung, zulässige Techniken, Abbruchkriterien, Wertgrenzen, Kommunikation, den Umgang mit Beweisen und die Pausenbefugnis festlegen [16].

Fazit

Der Bitget-Vorfall war weder eine Kompromittierung eines privaten Schlüssels noch ein Smart-Contract-Exploit. Bitget erklärte, dass die Angreifer eine Schwachstelle in einem Sicherheitsprodukt eines Drittanbieters ausnutzten, um Zugangsdaten zum Intranet zu erhalten, und dann Auszahlungsbefehle fälschten, die das Wallet-System zu gültig signierten On-Chain-Transfers verarbeitete [1, 2]. Nachdem Vermögenswerte die betroffene Institution verlassen haben, wird die Wiederherstellung zu einer gemeinsamen Anstrengung des Ökosystems. Die Reaktionen von Bitget, Binance, Bybit, THORChain und NEAR Intents zeigen, dass Teilnehmer auf unterschiedliche Weise reagieren können [8-12]. Wie die Community diese Fähigkeiten beim Auftreten eines schweren Sicherheitsvorfalls oder einer Bedrohung schnell und verantwortungsvoll koordinieren kann, bleibt eine umfassendere Herausforderung für die Krypto-Branche.

Der bekannte nachgelagerte Pfad bildet die Grundlage für das hier vorgeschlagene systematische Rahmenwerk, das Prävention und Erkennung mit Reaktion und Wiederherstellung verbindet. Institutionen können die Abhängigkeit von einer einzelnen Schutzmaßnahme verringern, indem sie den privilegierten Zugriff einschränken und den Ursprung von Befehlen authentifizieren, die genehmigte Auszahlungsabsicht bei der Signierung unabhängig rekonstruieren, ausgehende Sequenzen und eingehende Erlöse überwachen und unabhängig funktionsfähige Pause- und Übertragungspfade aufrechterhalten. Verwahrung bleibt unverzichtbar, und diese Praktiken ergänzen sie über die gesamte Kette der Geldbehandlung hinweg [13, 15].

Referenzen

[1] Bitget. Bitget Security Incident: Official Progress Update. https://www.bitget.com/campaigns/bitget-security-incident-2026

[2] Gracy Chen. Security Incident Root-Cause Boundary. https://x.com/GracyBitget/status/2104515761691939026

[3] The Block. Bitget Attacker Tested Risk Controls with Small Transfers Before $388 Million Theft, CEO Says. https://www.theblock.co/news/regulation/2026-09-28-bitget-attacker-tested-risk-controls-small-transfers-388-million-theft-ceo-says-417045

[4] Gracy Chen. Preliminary Attribution Assessment. https://x.com/GracyBitget/status/2103359775723626736

[5] Bitget. Live Tracing Dashboard and Fund-Flow Graph. https://trace.bgblockchain.xyz/v2#track

[6] Bitget. Live Tracing Information and Recovery Portal. https://x.com/bitget/status/2103485491220033607

[7] Gracy Chen. ETH Withdrawal Resumption Update. https://x.com/GracyBitget/status/2104886024979816508

[8] Binance. Richard Teng Puts Binance's Security Muscle Behind an Industry-Wide Response. https://www.binance.com/en/square/post/09-25-2026-binance-news-richard-teng-puts-binance-s-security-muscle-behind-an-industry-wide-response-370442242243629

[9] Ben Zhou. Bybit Support for Bitget. https://x.com/benbybit/status/2103328213141508335

[10] Gracy Chen. Request to THORChain. https://x.com/GracyBitget/status/2103812967066439817

[11] CoinDesk. THORChain Rejects Bitget Request to Block Hacker as $6 Million Moves to Bitcoin. https://www.coindesk.com/tech/2026/09/28/thorchain-rejects-bitget-request-to-block-hacker-as-usd6-million-moves-to-bitcoin

[12] Gracy Chen. NEAR Intents and SHIELD Response. https://x.com/GracyBitget/status/2104602301503816040

[13] BlockSec. From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing. https://blocksec.com/blog/why-crypto-institutions-need-blockchain-penetration-testing

[14] BlockSec. Web3 Attack Surfaces: A Penetration Testing Overview. https://blocksec.com/blog/web3-attack-surfaces-penetration-testing

[15] BlockSec. What Is Blockchain Penetration Testing? Definitions and Boundaries. https://blocksec.com/blog/what-is-blockchain-penetration-testing

[16] BlockSec. Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing. https://blocksec.com/blog/blockchain-penetration-testing-rules-of-engagement