Bitget: anatomia kradzieży 387 milionów dolarów

24 września 2026 roku z portfeli giełdy Bitget wyprowadzono kryptowaluty o wartości około 387,5 mln dolarów. Napastnicy nie musieli przejmować kluczy prywatnych. Wykorzystali podatność zewnętrznego produktu bezpieczeństwa, uzyskali dostęp do wewnętrznej infrastruktury i doprowadzili do podpisania fałszywych zleceń wypłat przez system samej giełdy. Wstępne raporty Mandiant i SlowMist oraz analizy blockchainowe pozwalają odtworzyć przebieg włamania.

Co wydarzyło się 24 września?

Pierwsze nieautoryzowane transfery z infrastruktury Bitget odnotowano 24 września o godzinie 18:31 UTC. Początkowo giełda oszacowała straty na 351,6 mln dolarów. Po przeanalizowaniu dodatkowych transakcji, w tym transferów w sieciach Zcash i TRON, podniosła tę kwotę do około 387,5 mln dolarów.

Korekta nie oznaczała kolejnej kradzieży. Wynikała z pełniejszego rozliczenia wcześniejszych operacji. Według informacji przekazanych przez Bitget incydent objął część infrastruktury portfeli hot i warm. Portfele cold wallet pozostały nienaruszone. Dotychczasowa analiza nie wykazała również kompromitacji kluczy prywatnych.

Nie ucierpiał osobny produkt Bitget Wallet, działający na innej infrastrukturze niż portfele giełdy.

Bitget czasowo wstrzymał wypłaty, utrzymując możliwość handlu i przyjmowania depozytów. Przywracanie usług rozpoczęto 28 września. Finansowe skutki incydentu giełda zadeklarowała pokryć z własnego funduszu ochronnego.

Punkt wejścia: podatność produktu bezpieczeństwa

30 września Bitget udostępnił wstępne raporty przygotowane przez Mandiant (Google Cloud) i SlowMist.

Z ustaleń obu firm wynika, że napastnicy najpierw wykorzystali lukę w jednym z systemów bezpieczeństwa używanych przez Bitget. Następnie przejęli kolejne elementy infrastruktury, uzyskując dostęp do wewnętrznych systemów giełdy. Najwcześniejsze ślady aktywności przypisanej do tego incydentu pochodzą z 31 sierpnia 2026 roku.

SlowMist zidentyfikował wykorzystanie nieznanej wcześniej podatności (zero-day) w usłudze działającej na jednym z węzłów produktu oznaczonego w raporcie jako "Product A".

Napastnik uruchomił ukryty skrypt w kontekście procesu usługi. Następnie odczytał ze zmiennej środowiskowej hasło do bazy danych i nawiązał z nią połączenie. Podobne działania zaobserwowano na kolejnych węzłach 23 i 25 września.

Drugi produkt, określany jako "Product B", został wykorzystany do dalszego przemieszczania się wewnątrz infrastruktury. Raport Mandiant potwierdza umieszczenie na nim web-shella oraz zestawienie połączenia z infrastrukturą Command and Control (C2).

SlowMist opisał również wykorzystanie tożsamości pracownika do uzyskania dostępu do platformy zarządzającej produktem B. Zarejestrowano próby wstrzykiwania poleceń, modyfikowania konfiguracji oraz przesyłania złośliwych plików.

Nie oznacza to jednak, że w produkcie B również wykorzystano podatność zero-day. Dostępne ustalenia nie dają podstaw do takiego stwierdzenia.

Z przejętego appliance'a napastnik przedostał się następnie na produkcyjny serwer obsługujący zadania systemu portfelowego (wallet job server).

Mandiant opisuje wdrożenie na nim złośliwych komponentów określanych jako malicious packages. Nie precyzuje jednak ich formatu, ani mechanizmu dystrybucji. Nie ma zatem podstaw, aby interpretować ten etap jako atak typu dependency confusion, wykorzystanie zainfekowanych zależności NPM/PyPI czy klasyczne naruszenie łańcucha dostaw oprogramowania.

Potwierdzono ponadto obecność złośliwych komponentów na serwerze wykorzystywanym w dalszej części ataku. Szczegóły ich implementacji nie zostały publicznie ujawnione.

Nazwy producentów obu produktów bezpieczeństwa również pozostają na chwilę obecną niejawne. Nie opublikowano identyfikatora CVE dotyczącego wykorzystanej podatności więc nie można obecnie wiarygodnie tudzież rzetelnie ocenić, czy analogiczne zagrożenie występuje u innych klientów tych dostawców.

Jak wykonano transfery bez kradzieży kluczy?

To najważniejsza część całego incydentu. Z raportu SlowMist wynika, że badacze odzyskali usunięte przez napastnika narzędzie przygotowane specjalnie do współpracy z systemem wypłat Bitget.

Program potrafił fałszować parametry wykorzystywane przez mechanizmy kontroli ryzyka, konstruować żądania wypłat i uruchamiać właściwy proces ich obsługi. Pierwsze wykonanie narzędzia odnotowano 25 września o godzinie 01:49 czasu UTC+8, czyli 24 września o 17:49 UTC.

Dzięki wcześniejszemu przejęciu uprzywilejowanego dostępu napastnik mógł wprowadzać fałszywe dyspozycje do wewnętrznego obiegu transakcji. System portfelowy przetwarzał je następnie jako operacje podlegające standardowej procedurze autoryzacji.

W ten sposób infrastruktura Bitget generowała prawidłowe kryptograficznie podpisy pod transakcjami przygotowanymi na podstawie sfałszowanych danych. Z punktu widzenia blockchaina podpisy były poprawne. Problem wystąpił wcześniej - w systemie odpowiedzialnym za przygotowanie i autoryzowanie operacji.

Analiza Hypernative i Bitquery ujawniła dodatkową cechę nieautoryzowanych transferów w sieciach zgodnych z EVM. W odróżnieniu od typowych wypłat klientów część z nich wykorzystywała stałe, zaokrąglone wartości gas limit, m.in. 100 000 i 200 000. Nie jest to samodzielny dowód na konkretny sposób przełamania zabezpieczeń backendu. Stanowi jednak istotny wskaźnik odmienności tych transakcji od rutynowej aktywności portfeli giełdy.

Podobną anomalię stwierdzono również w Zcash. W transparentnej części tej sieci obowiązuje model UTXO (Unspent Transaction Output), w którym wejścia transakcji wskazują wcześniej otrzymane, niewydane jeszcze wyjścia innych transakcji.

Dwie transakcje prowadzące do atakującego wykorzystały odpowiednio 1074 i 956 takich wejść, a tymczasem w przeanalizowanej przez Bitquery wcześniejszej aktywności tego portfela żadna transakcja nie przekraczała 54 wejść... Tak duża różnica wskazuje na operacje zdecydowanie odbiegające od dotychczasowego profilu pracy portfela. Sama liczba wejść nie pozwala jednak przesądzić o szczegółach mechanizmu włamania.

Według ustaleń SlowMist napastnik próbował ponadto wywołać dodatkowe wypłaty BTC poprzez bezpośrednią modyfikację rekordów w bazie systemu portfelowego. Dwa sfałszowane zlecenia trafiły do przetwarzania, ale zakończyły się błędami.

Trzy godziny, które kosztowały 387 milionów

Dane blockchainowe pozwalają dość dokładnie odtworzyć przebieg kradzieży. Pierwsze dwa transfery miały niewielką wartość. Według rekonstrukcji Bitquery i Hypernative były to 93 TRX oraz 0,84 ETH, wysłane o 18:31 UTC na świeże adresy w odstępie jedenastu sekund.

W rozmowie z The Block szefowa Bitget, Gracy Chen, podała inne wartości: 193 TRX oraz 0,184 ETH. Według jej relacji obie operacje znajdowały się poniżej progów kontroli ryzyka i nie wywołały alarmu. W dalszej rekonstrukcji przyjmujemy wartości wynikające z analizy transakcji on-chain, zachowując tę rozbieżność jako odrębne ustalenie.

O godzinie 18:58 UTC napastnik rozpoczął wyprowadzanie znacznie większych kwot. Następnie przeprowadził dwie główne serie transferów.

Dwie główne serie były oddalone od siebie o około 15 minut. Każda trwała jednak zaledwie kilkanaście sekund: pierwsza 15, druga 9.

Łącznie wyprowadzono w nich około 290,4 mln dolarów, czyli blisko trzy czwarte całej wartości skradzionych aktywów. Istotna jest również chronologia reakcji giełdy.

Pierwotne komunikaty Bitget wskazywały godzinę 18:31 jako moment wykrycia incydentu. W późniejszym wywiadzie Gracy Chen wyjaśniła jednak, że niewielkie transfery testowe nie uruchomiły alarmu.

Oficjalna chronologia podaje 19:05 UTC jako moment wykrycia istotnej rozbieżności przez system uzgodnień i automatycznego zablokowania wypłat klientów. Według Chen nastąpiło to siedem minut po pierwszym transferze o dużej wartości.

Nie zatrzymało to wszystkich nieautoryzowanych operacji. Transfery do portfeli napastnika występowały jeszcze do około 21:23 UTC. O godzinie 21:44 wyłączono usługi wypłat portfelowych, w tym podpisywanie transakcji, oraz odizolowano związany z nimi dostęp.

Ta różnica ma zasadnicze znaczenie: blokada standardowych wypłat klientów nie była równoznaczna z natychmiastowym zatrzymaniem całej infrastruktury zdolnej do podpisywania transakcji.

Dokąd trafiły skradzione kryptowaluty?

Największą część strat stanowiły aktywa w XRP Ledger - około 103 mln XRP, wyceniane w chwili transferów na blisko 158 mln USD.

Znaczącą część środków wyprowadzono również w ETH oraz tokenach działających w sieciach zgodnych z EVM. Wśród pozostałych aktywów znajdowały się m.in. ZEC, TRX, BNB i AVAX. Bitquery zidentyfikował 23 transfery bezpośrednio z portfeli giełdy do adresów atakującego na dziewięciu blockchainach.

W szerszym zestawieniu incydentu Bitget wymienia 11 sieci: Ethereum, XRP Ledger, Zcash, TRON, Arbitrum, Optimism, Base, BNB Smart Chain, Avalanche, Algorand i Celestię. Wśród objętych incydentem aktywów giełda wskazuje również ATOM, ALGO i TIA.

Różnica w liczbie sieci wynika z zakresu poszczególnych zestawień i nie powinna być traktowana jako sprzeczność dotycząca samej wartości kradzieży. Dla transferów na sieciach EVM jednym z głównych adresów odbiorczych był: 0x770b10b273fC44Fe9197D6bF20F145c2e98463Ee

Napastnik stosunkowo szybko rozpoczął zamianę aktywów, których emitenci dysponują mechanizmami zamrażania. USDT, USDC i inne aktywa podatne na działania swoich emitentów były sprzedawane albo przenoszone do kolejnych sieci. Łączna wartość tej grupy, obejmującej również token XAUt powiązany ze złotem, wynosiła około 88 mln dolarów.

Nie wszystkie aktywa przemieszczano jednak od razu - znaczne ilości ETH początkowo pozostawały na nowych portfelach. Dopiero po kilku dniach zaobserwowano kolejne transfery oraz zamiany części środków na BTC.

Skradzione XRP trafiały m.in. do protokołów umożliwiających wymianę aktywów pomiędzy różnymi blockchainami. Według stanu przedstawionego przez Bitquery 28 września około 90,5% skradzionych XRP zostało zamienionych na Bitcoin.

Część środków pochodzących z TRON i BNB Chain przechodziła przez THORChain oraz Chainflip. W przypadku Zcash analitycy odtworzyli transfery łącznie 18 916,72 ZEC, wartych w momencie kradzieży około 29,4 mln USD. Do 30 września około 3259 ZEC trafiło do prywatnej puli Ironwood.

Dalsze śledzenie tych środków wyłącznie na podstawie publicznych danych blockchainowych stało się niemożliwe. Pozostałe około 15 657 ZEC nadal znajdowało się wówczas na obserwowanym adresie. Wszystkie te wartości opisują stan ustalony na konkretne dni. Śledztwo trwa, a środki nadal mogą być przemieszczane.

Czy za atakiem stoi Korea Północna?

Prawdopodobieństwo powiązania incydentu z podmiotami działającymi na rzecz Korei Północnej jest oceniane jako wysokie, choć nie wszystkie firmy analityczne sformułowały równie kategoryczne lub daleko idące wnioski.

Szefowa Bitget, Gracy Chen, wskazywała na podobieństwa do wcześniejszych operacji przypisywanych DPRK, w tym wykorzystanie infrastruktury VPN kojarzonej z północnokoreańskimi grupami oraz charakterystyczny sposób przemieszczania skradzionych aktywów.

Elliptic uznał powiązanie ataku z DPRK za wysoce prawdopodobne. Analitycy wskazali m.in. na związki pomiędzy infrastrukturą wykorzystywaną do prania środków z Bitget a portfelami uczestniczącymi we wcześniejszych kradzieżach przypisywanych Korei Północnej, w tym ataku na Bybit z lutego 2025 roku.

Chainalysis również zakwalifikował incydent jako powiązany z DPRK. Według firmy jego uwzględnienie podniosło łączną wartość kryptowalut skradzionych przez północnokoreańskich cyberprzestępców w 2026 roku do ponad miliarda dolarów.

Ostrożniejsze stanowisko przedstawił TRM Labs. Firma potwierdziła istotne podobieństwa i powiązania infrastruktury wykorzystywanej do przemieszczania środków, ale w swojej analizie nie przedstawiła definitywnej atrybucji samego włamania.

Raporty techniczne Mandiant i SlowMist również nie wskazują jednoznacznie sprawcy. Wspólna infrastruktura finansowa jest ważną przesłanką analityczną. Nie musi jednak dowodzić, że wszystkie powiązane incydenty zostały przeprowadzone przez dokładnie ten sam zespół operatorów.

Fundusz ochronny i szanse odzyskania pieniędzy

Przed incydentem wartość Bitget Protection Fund przekraczała 464 mln dolarów. Giełda zadeklarowała wykorzystanie go do pokrycia strat, tak aby włamanie nie wpłynęło na salda klientów. 29 września Bloomberg poinformował, że wartość funduszu spadła poniżej 200 mln dolarów. Było to wyliczenie redakcji oparte na trzech publicznie wskazanych przez Bitget adresach portfeli, a nie kwota ogłoszona przez samą giełdę.

30 września Bitget poinformował o uzupełnieniu funduszu własnym kapitałem do poziomu przekraczającego 300 mln dolaów. Zobowiązanie zostało zrealizowane przed upływem zapowiedzianego tygodniowego terminu. Równolegle trwały działania mające na celu zamrażanie i odzyskiwanie aktywów. Na początku października Gracy Chen poinformowała CNBC o zamrożeniu około 1,1 mln dolarów.

Trzeba jednak rozróżnić środki zamrożone od faktycznie odzyskanych. W pierwszym przypadku aktywa zostały unieruchomione, lecz niekoniecznie wróciły już pod kontrolę giełdy.

Chen nie ukrywała również ograniczonego optymizmu co do odzyskania znaczącej części pozostałych środków. Jest to uzasadniona ostrożność. Przenoszenie aktywów pomiędzy blockchainami, korzystanie z rozproszonych protokołów wymiany oraz wprowadzanie ZEC do prywatnej puli istotnie utrudniają dalsze śledzenie.

Nie oznacza to jednak, że odzyskanie środków jest niemożliwe. W grę mogą nadal wchodzić informacje pozyskane poza blockchainem, dane dostawców usług, współpraca organów ścigania lub późniejsza identyfikacja punktów, w których przestępcy próbują zamienić kryptowaluty na inne aktywa.

Kiedy wznowiono wypłaty?

Bitget przywracał wypłaty etapami, zgodnie z opublikowanym harmonogramem:

Giełda uzależniała otwieranie kolejnych usług od zakończenia kontroli bezpieczeństwa odpowiednich komponentów infrastruktury.

Co ten incydent mówi o bezpieczeństwie infrastruktury?

Włamanie do Bitget ujawniło kilka problemów istotnych nie tylko dla giełd kryptowalut. Pierwszy problem dotyczy uprawnień przyznawanych systemom bezpieczeństwa. Jeśli napastnik przejmie kontrolę nad jednym z nich, może wykorzystać jego dostęp, aby przedostać się do kolejnych systemów firmy. Tak właśnie wyglądał jeden z etapów ataku na Bitget.

Drugi problem dotyczy granic zaufania pomiędzy systemami biznesowymi a infrastrukturą podpisującą transakcje. Jeżeli komponent odpowiedzialny za podpisywanie przyjmuje adres odbiorcy i kwotę z systemu, który napastnik może przejąć lub zmodyfikować, poprawność kryptograficzna podpisu nie wystarcza do zapewnienia bezpieczeństwa.

Proces autoryzacji powinien niezależnie potwierdzać zgodność dyspozycji z uprawnionym zleceniem, którego nie może samodzielnie zmienić komponent inicjujący transfer. Duże znaczenie ma również właściwe odseparowanie systemów kontroli ryzyka od systemów wykonawczych - przejęcie jednego z nich nie powinno automatycznie pozwalać na obejście zabezpieczeń drugiego.

Trzecia kwestia to procedury awaryjne. Szczególnie istotna jest różnica między zablokowaniem wypłat użytkowników a zatrzymaniem samej ścieżki wykonawczej portfela.

O 19:05 system uzgodnień zablokował standardowe żądania wypłat, ale nieautoryzowane transfery były realizowane jeszcze przez ponad dwie godziny. Dopiero o 21:44 wyłączono usługi portfelowe odpowiedzialne również za podpisywanie transakcji.

Z punktu widzenia architektury bezpieczeństwa pokazuje to potrzebę istnienia niezależnego mechanizmu awaryjnego (global kill switch), który umożliwia natychmiastowe zatrzymanie nowych podpisów i transferów, niezależnie od stanu interfejsu użytkownika, API wypłat czy backendu przygotowującego zadania.

Taka blokada powinna działać możliwie blisko warstwy wykonawczej. W przeciwnym razie przejęcie komponentu generującego dyspozycje może pozwolić atakującemu na dalsze wykonywanie operacji pomimo zatrzymania obsługi standardowych żądań klientów.

Publiczne raporty nie opisują na tyle szczegółowo architektury Bitget, aby przesądzić, czy problem dotyczył konkretnej implementacji HSM, KMS, kolejki zadań czy innego komponentu systemu podpisującego. Nie można również na ich podstawie jednoznacznie stwierdzić, że odpowiedni mechanizm awaryjny w ogóle nie istniał. Znane są natomiast godziny kolejnych działań i fakt, że pierwsza blokada nie zakończyła natychmiast nieautoryzowanych transferów.

Wreszcie, zabezpieczenia i monitoring muszą obejmować wszystkie obsługiwane blockchainy. Koncentracja na sieciach EVM pozostawia istotne luki w widoczności operacji wykonywanych m.in. na XRP Ledger, TRON czy Zcash.

Wnioski?

Bitget stracił około 387,5 mln dolarów, mimo że według dotychczasowych ustaleń jego klucze prywatne nie zostały przejęte, a portfele cold wallet pozostały bezpieczne.

Atak wymierzono w infrastrukturę poprzedzającą właściwe podpisanie transakcji: systemy bezpieczeństwa, uprawnienia wewnętrzne i mechanizmy przygotowywania dyspozycji wypłat. Atakujący nie musiał/nie musieli przełamywać kryptografii. Doprowadził do sytuacji, w której prawidłowo działający mechanizm kryptograficzny zatwierdzał operacje, których nigdy nie powinien otrzymać.

Dla operatorów infrastruktury finansowej jest to przypomnienie, że ochrona kluczy stanowi tylko jeden z elementów bezpieczeństwa.

Równie ważne jest niezależne sprawdzanie tego, co właściwie ma zostać podpisane, przez kogo zostało zlecone i czy rzeczywiście powinno zostać wykonane.