Bitget potwierdza atak zero-day w zewnętrznych systemach bezpieczeństwa po kradzieży 387,5 mln dolarów - Security Bez Tabu

Bitget potwierdza atak zero-day w zewnętrznych systemach bezpieczeństwa po kradzieży 387,5 mln dolarów

Cybersecurity news

Wprowadzenie do problemu / definicja

Bitget potwierdził, że źródłem incydentu prowadzącego do kradzieży kryptowalut o wartości 387,5 mln dolarów było wykorzystanie luki typu zero-day w zewnętrznych produktach bezpieczeństwa. To klasyczny przykład ataku na łańcuch zaufania, w którym napastnicy nie uderzają bezpośrednio w główny system ofiary, lecz przejmują komponent pośredni odpowiedzialny za ochronę, nadzór lub obsługę operacyjną.

Tego rodzaju scenariusz jest szczególnie groźny dla giełd kryptowalutowych, ponieważ zaufane narzędzia bezpieczeństwa często mają szeroki dostęp do infrastruktury, procesów administracyjnych i systemów obsługujących transakcje. Jeśli taki element zostanie skompromitowany, może stać się uprzywilejowanym kanałem wejścia do środowiska produkcyjnego.

W skrócie

  • Bitget powiązał incydent z luką zero-day w zewnętrznych produktach bezpieczeństwa.
  • Napastnicy uzyskali uprzywilejowany dostęp do środowiska wewnętrznego i uruchomili niestandardowe narzędzia do fałszywych wypłat.
  • Z infrastruktury giełdy wyprowadzono aktywa z hot walleti i warm walleti o łącznej wartości 387,5 mln dolarów.
  • Incydent objął wiele blockchainów i wskazuje na długotrwałą, dobrze przygotowaną operację.
  • Sprawa uwypukla ryzyko związane z nadmiernym zaufaniem do dostawców i systemów pośrednich.

Kontekst / historia

24 września 2026 roku Bitget poinformował o wykryciu nieautoryzowanych transferów oraz o czasowym wstrzymaniu wypłat. Wstępne ustalenia wskazywały, że naruszenie objęło portfele operacyjne obsługujące wiele sieci blockchain, a skala zdarzenia wymagała rozszerzonej analizy logów, telemetrii hostów oraz artefaktów pozostawionych w systemach wspierających bezpieczeństwo i operacje portfelowe.

Z późniejszych ustaleń wynika, że pierwsze ślady aktywności napastników mogły pojawić się już 31 sierpnia 2026 roku. Oznacza to, że atak nie miał charakteru jednorazowego, lecz był kilkuetapową kampanią obejmującą rekonesans, utrzymywanie dostępu i przygotowanie narzędzi dopasowanych do środowiska ofiary.

Według dostępnych informacji incydent objął 11 sieci blockchain. Wśród dotkniętych aktywów znalazły się między innymi XRP, ETH, USDT, USDC, ZEC, BNB, AVAX, TRX, ALGO i TIA. Rozproszenie środków pomiędzy różne łańcuchy sugeruje, że sprawcy dobrze rozumieli zarówno architekturę wypłat, jak i zależności pomiędzy systemami operacyjnymi giełdy.

Analiza techniczna

Techniczny rdzeń incydentu miał polegać na kompromitacji zewnętrznych urządzeń lub platform bezpieczeństwa używanych przez Bitget. W jednym z takich komponentów napastnicy wykorzystali nieznaną wcześniej lukę zero-day w usłudze działającej na węźle systemowym. Po uzyskaniu wykonania kodu lub równoważnego dostępu uruchomiono ukryty skrypt w kontekście procesu usługi, a następnie odczytano zmienne środowiskowe zawierające dane potrzebne do połączenia z bazą danych.

To ważny element całego ataku. Przechowywanie sekretów w zmiennych środowiskowych jest powszechne, jednak po przejęciu hosta taki model ochrony przestaje być skuteczny. W praktyce bezpieczeństwo danych uwierzytelniających zależy więc nie tylko od ich ukrycia przed użytkownikiem, ale przede wszystkim od integralności hosta, procesu uruchomieniowego i całej warstwy pośredniej.

Dalsza analiza wykazała podobne ślady aktywności na kolejnych węzłach, co wskazuje na kontrolowaną ekspansję w środowisku. 25 września atakujący mieli uzyskać dostęp do platformy zarządzającej innym produktem bezpieczeństwa z wykorzystaniem tożsamości wewnętrznego pracownika. Na tym etapie odnotowano próby wstrzykiwania poleceń systemowych do parametrów zadań, zapis złośliwych plików oraz użycie funkcji wykonawczych aplikacji webowej do modyfikacji konfiguracji serwera i wdrożenia kolejnych komponentów.

Badacze odzyskali również usunięte pliki zawierające wyspecjalizowane narzędzie przeznaczone do kradzieży środków. Nie był to klasyczny malware ogólnego zastosowania, lecz oprogramowanie przygotowane pod konkretną logikę systemu wypłat Bitget. Taki komponent potrafił generować operacje wyglądające jak legalne polecenia transferu, co znacząco zwiększało szanse na ominięcie części mechanizmów kontroli.

Po przejęciu zewnętrznych appliance’ów bezpieczeństwa sprawcy wykonali ruch lateralny do produkcyjnego serwera zadań portfelowych. Tam wdrożono złośliwe pakiety oraz ustanowiono trwały kanał komunikacji typu command-and-control. Ten etap był kluczowy, ponieważ umożliwił wykonywanie działań z poziomu zaufanego elementu infrastruktury, a więc z pozycji, która naturalnie budzi mniejsze podejrzenia niż aktywność pochodząca z zewnętrznego źródła.

Z perspektywy architektury bezpieczeństwa to scenariusz wyjątkowo niebezpieczny. Gdy systemy odpowiedzialne za egzekwowanie polityk, kontrolę ruchu lub inspekcję zostaną przejęte, mogą same stać się narzędziem kompromitacji środowiska produkcyjnego. W praktyce oznacza to odwrócenie roli mechanizmów obronnych i załamanie łańcucha zaufania.

Konsekwencje / ryzyko

Najbardziej bezpośrednią konsekwencją była utrata aktywów o ogromnej wartości finansowej. Jednak z punktu widzenia cyberbezpieczeństwa skutki incydentu są znacznie szersze. Sprawa podważa zaufanie do integracji pomiędzy giełdą a zewnętrznymi narzędziami ochronnymi, pokazując, że pojedynczy słaby punkt po stronie dostawcy może umożliwić obejście zabezpieczeń w środowisku krytycznym.

Drugim poważnym ryzykiem jest długi czas niewykrytej obecności napastnika. Jeśli pierwsze oznaki kompromitacji faktycznie pojawiły się pod koniec sierpnia 2026 roku, oznacza to wielotygodniowe okno operacyjne. W tym czasie przeciwnik mógł prowadzić rekonesans, mapować zależności, pozyskiwać poświadczenia i budować narzędzia dopasowane do procesów biznesowych ofiary.

Incydent zwraca również uwagę na problem ochrony sekretów i tożsamości uprzywilejowanych. Odczyt haseł z pamięci procesu, zmiennych środowiskowych lub zasobów konfiguracyjnych pozostaje częstym etapem po przejęciu systemu pośredniego. Jeżeli organizacja nie stosuje krótkiego czasu życia poświadczeń, silnej segmentacji uprawnień i niezależnej autoryzacji operacji wysokiego ryzyka, skutki naruszenia mogą objąć całe środowisko.

W tle pozostaje także wymiar operacyjny i geopolityczny. Wstępne przypisanie ataku podmiotom powiązanym z Koreą Północną sugeruje kampanię realizowaną przez przeciwnika dysponującego znacznymi zasobami, zdolnego do łączenia exploitów zero-day, kradzieży tożsamości, ruchu lateralnego i monetyzacji dostępu na wielu blockchainach jednocześnie.

Rekomendacje

Organizacje działające w sektorze kryptowalut powinny traktować zewnętrzne systemy bezpieczeństwa jako komponenty wysokiego ryzyka, a nie jako elementy automatycznie zaufane. Niezbędna jest ścisła segmentacja pomiędzy appliance’ami bezpieczeństwa, warstwą zarządzania, serwerami zadań portfelowych i systemami przechowującymi sekrety.

  • Ograniczyć możliwość samodzielnego inicjowania krytycznych wypłat przez pojedynczy system techniczny.
  • Wdrożyć niezależną, wielokanałową autoryzację transferów wysokiego ryzyka.
  • Zastąpić długowieczne sekrety krótkotrwałymi tokenami i menedżerami sekretów.
  • Wymuszać rotację poświadczeń po każdej zmianie stanu incydentowego.
  • Monitorować uruchamianie procesów potomnych przez usługi bezpieczeństwa oraz nietypowe połączenia wychodzące z appliance’ów.
  • Wykrywać modyfikacje konfiguracji serwerów, web shelle, ukryte skrypty i nieautoryzowane transfery plików do katalogów wykonywalnych.
  • Wymagać od dostawców szybkiej wymiany IoC, jawnych procedur reagowania i możliwości natychmiastowego odłączenia zagrożonej funkcji bez utraty kontroli nad środowiskiem krytycznym.

Dobrą praktyką jest także prowadzenie ćwiczeń purple team uwzględniających scenariusz kompromitacji zaufanego narzędzia bezpieczeństwa. Takie testy pomagają zweryfikować, czy organizacja potrafi wykrywać nadużycia pochodzące z własnego łańcucha zaufania, a nie wyłącznie z zewnętrznej sieci.

Podsumowanie

Incydent w Bitget pokazuje, że współczesne ataki na infrastrukturę kryptowalutową coraz częściej koncentrują się na systemach pośrednich, a nie wyłącznie na samych portfelach czy kluczach prywatnych. Wykorzystanie luki zero-day w produkcie bezpieczeństwa, przejęcie tożsamości wewnętrznej, ruch lateralny do środowiska portfelowego oraz użycie wyspecjalizowanego narzędzia do generowania fałszywych wypłat tworzą obraz operacji precyzyjnie przygotowanej pod konkretną ofiarę.

Najważniejsza lekcja dla branży jest jednoznaczna: zaufane komponenty ochronne również muszą być traktowane jako potencjalny wektor ataku. Odporność operacyjna nie wynika wyłącznie z liczby wdrożonych zabezpieczeń, lecz z ich separacji, niezależności i zdolności do wykrywania nadużyć wewnątrz własnej infrastruktury.

Źródła

  • The Hacker News — Bitget Confirms Third-Party Zero-Day Behind $387.5 Million Cryptocurrency Theft — https://thehackernews.com/2026/10/bitget-confirms-third-party-zero-day.html
  • Bitget — Initial disclosure on unauthorized transfers — https://www.bitget.com/support/articles/12560603827960
  • SlowMist — Progress report on the Bitget security incident — https://github.com/slowmist/bitget-incident-report
  • Mandiant — Technical statement on third-party appliance compromise and lateral movement — https://img.bgstatic.com/misc/mandiant-bitget-incident-summary.pdf
  • Bitget — Follow-up analysis of abnormal transfers and mitigation actions — https://www.bitget.com/support/articles/12560603828114