~418 Mio. $ verloren: Bitget- und NEAR-Intents-Exploits | BlockSec Weekly

In den letzten zwei Wochen (21.09.2026 - 04.10.2026) ereigneten sich 8 Vorfälle im Bereich der Blockchain-Sicherheit mit einem geschätzten Gesamtschaden von rund 418,4 Mio. USD.

Gründe für die Auswahl

• Bitget: Der Vorfall macht den größten Teil der Verluste des Berichtszeitraums aus und lässt sich von einer Off-Chain-Kompromittierung über gefälschte Auszahlungsbefehle bis zu gültigen On-Chain-Transfers zurückverfolgen, ohne dass private Schlüssel oder Smart Contracts kompromittiert wurden.
• NEAR Intents: Ein Fehler bei der Rückerstattungsvalidierung und ein fehlendes State-Rollback verwandelten eine fehlgeschlagene Auflösung von Cross-Chain-Einzahlungen in ungedeckte interne Guthaben, die den normalen Auszahlungsweg passieren konnten.

Bitget

Am 24. September verließen rund 387,5 Mio. USD Teile der Hot- und Warm-Wallet-Infrastruktur von Bitget über Ethereum und andere EVM-Netzwerke, XRP Ledger, Zcash und TRON. Die On-Chain-Transaktionen trugen gültige Wallet-Signaturen. Bitget gab an, dass der Angreifer eine Schwachstelle in einem Sicherheitsprodukt eines Drittanbieters ausnutzte, sich Zugangsdaten für das Intranet verschaffte und Auszahlungsbefehle fälschte, während private Schlüssel und Cold Wallets sicher blieben[1][2].

Überblick über den Vorfall

Die unabhängigen Untersuchungsberichte liefern zusätzliche Details zum Angriffsweg, ohne die beiden betroffenen Sicherheitsprodukte zu benennen. SlowMist führte die frühesten bösartigen Aktivitäten bei Produkt A auf den 31. August zurück und identifizierte einen Zero-Day-Fehler, der einen Dienst auf einem Knoten betraf. Mandiant stellte privilegierten Zugriff auf zwei Sicherheits-Appliances, eine Web-Shell und eine Command-and-Control-Verbindung bei Produkt B sowie eine seitliche Bewegung hin zum Produktions-Wallet-Job-Server fest.

SlowMist stellte außerdem fest, dass der Angreifer eine interne Mitarbeiteridentität nutzte, um auf die Management-Plattform von Produkt B zuzugreifen. Die Ermittler fanden zudem ein maßgeschneidertes Auszahlungstool, das Risikokontrollparameter fälschte, Auszahlungsanfragen erstellte und den Auszahlungsprozess auslöste. Wie sich der Angreifer zwischen allen beteiligten Systemen bewegte, ist weiterhin Gegenstand der Untersuchung. Die öffentlichen Chains erfassten lediglich die endgültig signierten Transfers, nicht diese vorgelagerten Vorgänge.

On-Chain-Aufzeichnungen zeigen, dass die ersten Bewegungen 93 TRX und, 11 Sekunden später, 0,84 ETH um 18:31 UTC betrugen. Bitgets aktuelle Zeitlinie verzeichnet die Erkennung bei der Abstimmung um 19:05 UTC und die Aktivierung der höchsten Notfallreaktionsstufe um 19:14 UTC[1]. Ein separater Transfer von 20,59 Mio. TRX erreichte die vom Angreifer kontrollierte TRON-Adresse um 19:16 UTC; Chen beschrieb 17 größere Transfers über acht weitere Netzwerke mit einem Gesamtwert von rund 361 Mio. USD[3]. Die Eindämmung begann um 19:40 UTC, und die Wallet-Auszahlungs- und Signaturdienste wurden um 21:44 UTC abgeschaltet[1].

Status der Gelder und Reaktion der Community

Um 16:35:28 UTC am 29. September meldete Bitgets offizieller Holdings-Tracker aktuelle Bestände des Angreifers in Höhe von 322,67 Mio. USD, etwa 632.700 USD eingefroren, 312.500 USD in von Emittenten einfrierbaren Stablecoins und 55,87 Mio. USD in Transit oder noch in Analyse. Die separate Adressansicht zeigte Guthaben, die sich auf BTC (288,51 Mio. USD), ZEC (28,91 Mio. USD) und ETH (7,17 Mio. USD) konzentrierten; diese Ansicht verwendet einen anderen Klassifizierungsrahmen als die Übersicht.

Binance teilte Informationen und unterstützte die Rückverfolgung der Gelder, während Bybit LazarusBounty aktualisierte und Hilfe anbot[4][5]. Infrastrukturanbieter trafen unterschiedliche Entscheidungen. Bitget bat THORChain, gelisteten Angreiferadressen den Dienst zu verweigern, und argumentierte, Dezentralisierung solle die Zirkulation bekannter gestohlener Gelder nicht schützen[6]. THORChain lehnte selektives Blacklisting ab und erklärte, seine Kontrollmechanismen könnten umfassendere Aktivitäten oder eine Chain-Route stoppen, nicht jedoch eine einzelne Adresse oder Transaktion[7].

NEAR Intents berichtete, dass SHIELD nach Filterung von Duplikaten mehr als 50 Mio. USD an versuchten, mit dem Angreifer verbundenen Flüssen identifizierte und blockierte. Etwa 503.000 USD wurden während der Ausführung eingefroren, und rund 166.000 USD wurden durchgeleitet; die 50-Mio.-USD-Zahl ist ein versuchter Fluss, kein eingefrorener oder wiederhergestellter Betrag[8]. Der Tracker klassifizierte später 293.507 USD als bei NEAR Intents eingefroren, und öffentliche Quellen gleichen die Differenz nicht aus.

Lessons Learned

• Der Angreifer gelangte über Sicherheitsprodukte von Drittanbietern hinein, erreichte den Wallet-Job-Server und verwandelte gefälschte Auszahlungsanfragen in gültig signierte Transaktionen. Jedes Drittanbieterprodukt mit dieser Reichweite gehört zur effektiven Sicherheitsgrenze der Vermögenswerte: Institutionen sollten es isolieren, Identitäten und Rechte einschränken, sein Verhalten überwachen und die Auszahlungsabsicht vor der Signierung unabhängig überprüfen.
• Die Befugnis zur Wiederherstellung war über Börsen, Stablecoin-Emittenten, Routing-Dienste und Basisprotokolle verteilt, sodass kein Beteiligter die Reaktion allein steuern konnte. Die betroffene Institution muss verifizierte Adressen und Transaktionsdaten schnell weitergeben, während Infrastrukturanbieter und Sicherheitsteams Rückverfolgung, Einfrieren, Transaktionsprüfung und Wiederherstellung im Rahmen ihrer technischen und organisatorischen Möglichkeiten koordinieren.
• Die aus diesem Vorfall abgeleiteten präventiven Maßnahmen sind unter Bitget's $387.5M Off-Chain Breach: Beyond Keys and Contracts beschrieben, wo ein mehrstufiges Verteidigungskonzept für privilegierten Zugriff, Auszahlungsabsicht, Überwachung von Vermögensflüssen und Notfallreaktion entwickelt wird.

NEAR Intents

Zwischen dem 30. September und dem 1. Oktober verlor NEAR Intents rund 3,87 Mio. USD, nachdem ein Fehler bei der Rückerstattungsvalidierung und ein fehlendes State-Rollback in intents.near ein internes Guthaben ohne entsprechende Vermögensdeckung erzeugten. Der Angreifer nutzte dieses Guthaben, um gültige HOT-MPC-Auszahlungssignaturen zu erhalten und reale USDT aus dem BNB-Chain-Vault des Protokolls freizugeben[9][10].

Hintergrund

NEAR Intents ist ein Intent-Ausführungssystem auf NEAR. Sein Kernvertrag, intents.near, hält Omni-Assets, verzeichnet die internen Guthaben der Nutzer und verarbeitet Asset-Swaps und Auszahlungen basierend auf signierten Intents.

Bei einer Cross-Chain-Einzahlung sperrt ein Vault auf der Quellchain den realen Vermögenswert. Omni erstellt das entsprechende Omni-Asset auf NEAR und überträgt es an intents.near, das das interne Guthaben des Nutzers gutschreibt.

Bei einer Auszahlung bittet intents.near Omni, das entsprechende Omni-Asset zu verbrennen und einen Auszahlungsdatensatz zu erstellen. HOT MPC überprüft diesen Datensatz und stellt eine Signatur aus. Der Vault der Zielchain überprüft die Signatur, bevor er den realen Vermögenswert freigibt. Dieser Prozess setzt voraus, dass die von intents.near verzeichneten internen Guthaben weiterhin durch die vom Vertrag tatsächlich gehaltenen Omni-Assets gedeckt sind.

Schwachstellenanalyse

Der Einzahlungspfad schrieb das interne Guthaben des Empfängers gut, bevor die Cross-Contract-Übertragung vollständig abgeschlossen war. Während der Auflösung begrenzte resolve_deposit_internal() den vom Empfänger kontrollierten requested_refund durch das Gesamtguthaben des Empfängers für dieses Token, nicht jedoch durch deposited, den tatsächlich übertragenen Betrag der aufzulösenden Einzahlung. Das Gesamtguthaben zeigte lediglich, was das Konto zahlen konnte; deposited legte fest, was dieser Transfer zurückerstatten durfte. Ohne diese zweite Begrenzung konnte ein Empfänger mit einem großen, bereits bestehenden Guthaben eine Rückerstattung weit über der aktuellen Einzahlung anfordern[10].

Bei einer gebündelten Einzahlung mit vielen langen Token-IDs vergrößerten die fehlerhaften Rückerstattungswerte das serialisierte MtBurnEvent. Der Pfad check_refund().unwrap_or_panic_display().emit() löste dann einen Panic aus, als das Event die Gesamtlogbegrenzung von NEAR überschritt, was den Fehlschlag der mt_resolve_deposit-Receipt verursachte.

Das interne Guthaben war in einer früheren Receipt gutgeschrieben worden. Der Panic machte die versuchten Guthaben- und Supply-Abzüge der Callback-Receipt rückgängig, hob jedoch diese frühere Gutschrift nicht auf. Omni gab daraufhin die übertragenen Vermögenswerte an den Absender zurück, wodurch der Angreifer ein auszahlbares internes Guthaben zurückbehielt, das nicht mehr mit den von intents.near gehaltenen Omni-Assets übereinstimmte. Die Schwachstelle kombinierte einen Fehler bei der Rückerstattungsvalidierung mit einem fehlenden State-Rollback über die asynchrone Receipt-Sequenz hinweg.

Angriffsanalyse

Die folgende Rekonstruktion basiert auf öffentlich verfügbaren Informationen[11].

Phase 1: Erzeugung eines ungedeckten internen Guthabens auf NEAR

• Schritt 1: Der Angreifer zahlte 10 USDT über den BNB-Chain-Omni/HOT-Vault ein, wodurch das bösartige Empfängerkonto ein Omni-Asset-Guthaben größer als null auf NEAR erhielt.

• Schritt 2: Der Angreifer rief mt_batch_transfer_call() auf v2_1.omni.hot.tg auf. In mt_on_transfer() schrieb intents.near dem Empfänger zunächst über deposit() gut, benachrichtigte anschließend den bösartigen Empfänger und übergab dessen Antwort an mt_resolve_deposit().

• Schritt 3: Der bösartige Empfänger gab einen requested_refund weit über der aktuellen Einzahlung zurück. Da die Validierung das Gesamttoken-Guthaben des Empfängers als Obergrenze verwendete, gelangte der abnormale Wert in die Rückerstattungsverarbeitung.

• Schritt 4: Über die gebündelten Einträge hinweg ließen die überhöhten Rückerstattungswerte das serialisierte MtBurnEvent die Gesamtlogbegrenzung von NEAR überschreiten. Der mt_resolve_deposit-Callback löste einen Panic aus, der seine versuchten Rückerstattungsabzüge zurücksetzte, jedoch nicht die durch die frühere Receipt bereits festgeschriebene interne Gutschrift. Omni gab die übertragenen Vermögenswerte zurück, während das gutgeschriebene Guthaben in intents.near weiterhin verfügbar blieb. Die Wiederholung dieser Sequenz erzeugte ein ungedecktes Guthaben, das der Angreifer auszahlen konnte.

Phase 2: Auszahlung realer Vermögenswerte aus dem BNB-Chain-Vault

• Schritt 5: Um 18:57 und 20:05 UTC am 30. September nutzte der Angreifer gültige HOT-MPC-Autorisierungen, um den BNB-Chain-Vault mit Auszahlungen von 10 USDT und 11 USDT zu testen. Die erste Testtransaktion bestätigte, dass der Vault die vorgelagerte Autorisierung akzeptierte.

• Schritt 6: Von 23:54 UTC am 30. September bis 06:08 UTC am 1. Oktober nahm der Angreifer fünf größere Auszahlungen in Höhe von 800.000 USDT, 1,2 Mio. USDT, 1,5 Mio. USDT, 330.000 USDT und 35.000 USDT vor. Diese Transaktionen gaben insgesamt 3,865 Mio. USDT aus dem Vault frei.

Fazit

NEAR Intents wurde durch eine fehlerhafte Rückerstattungsvalidierung und ein fehlendes Rollback nach einem gescheiterten Abschluss der Einzahlungsauflösung ausgenutzt. Der Angreifer nutzte überhöhte Rückerstattungsanfragen, um ein internes Guthaben zu bewahren, nachdem die zugrunde liegenden Vermögenswerte bereits zurückgegeben worden waren, und verwendete dieses ungedeckte Guthaben anschließend, um Auszahlungen anzufordern. Omni erstellte die entsprechenden Auszahlungsdatensätze, HOT MPC signierte sie, und der BNB-Chain-Vault gab reale USDT frei.

Die Rückerstattungsverarbeitung sollte die Rückerstattung pro Token durch den Betrag der aufzulösenden Einzahlung begrenzen. Das Protokoll sollte außerdem die Gutschrift von Guthaben und die Auflösung, wo möglich, atomar gestalten oder nach einem Fehlschlag ein garantiertes kompensierendes Rollback anwenden. Vor der Ausstellung von Auszahlungssignaturen sollte es die aggregierten internen Guthaben mit den tatsächlichen Omni-Asset-Beständen abgleichen und Auszahlungen bei jeder Abweichung pausieren. Auch die Event-Erzeugung muss begrenzt werden, damit ein überdimensioniertes Log keinen für den Zustand kritischen Auflösungspfad abbrechen kann.

Referenzen

[1] https://www.bitget.com/academy/bitget-security-incident-what-happened-timeline-impact-response

[2] https://x.com/GracyBitget/status/2104515761691939026

[3] https://www.theblock.co/news/regulation/2026-09-28-bitget-attacker-tested-risk-controls-small-transfers-388-million-theft-ceo-says-417045

[4] 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

[5] https://x.com/benbybit/status/2103328213141508335

[6] https://x.com/GracyBitget/status/2103812967066439817

[7] https://www.coindesk.com/tech/2026/09/28/thorchain-rejects-bitget-request-to-block-hacker-as-usd6-million-moves-to-bitcoin

[8] https://x.com/GracyBitget/status/2104602301503816040

[9] https://x.com/near_intents/status/2105642219357241796

[10] https://github.com/near/intents/pull/362

[11] https://x.com/Phalcon_xyz/status/2105680009687957909

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die unseren Kunden helfen, Code-Audits durchzuführen (einschließlich Smart Contracts, Blockchain und Wallets), Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illegale Gelder zurückzuverfolgen und AML/CFT-Verpflichtungen zu erfüllen – über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg.

BlockSec hat mehrere Fachartikel zur Blockchain-Sicherheit auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert, um mehr als 20 Millionen Dollar zu retten, und Kryptowährungen im Wert von mehreren Milliarden Dollar gesichert.

• Offizielle Website: https://blocksec.com/

• Offizieller Twitter-Account: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Anfrage senden

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance