Atak na Bitget 24.09.2026: Analiza wycieku 351 mln $

Siedziałem wczoraj wieczorem, dłubiąc w konfiguracji nowego endpointu dla wewnętrznego testnetu i sącząc już wystygłą kawę, gdy nagle monitory w kanałach security zaczęły płonąć na czerwono. I to tak gwałtownie, что aż mnie ścisnęło w dołku — bolesne, doskonale znane uczucie z czasów, kiedy sam zarywałem nockи na zawodach CTF.

Poleciały pierwsze zrzuty z blockchaina, analitycy z Arkhama podnieśli raban, a cyfry na ekranach terminali zaczęły pędzić jak szalone. Giełda Bitget, jeden z wagi ciężkiej na rynku, zaliczyła potężny incydent na kwotę około 351,6 miliona dolarów. I wiecie co? Moja pierwsza myśl wcale nie brzmiała „znowu poszły kasory”, tylko była czysto inżynieryjna: jaki wektor ataku udało im się tym razem przełamać? Bo przecież infrastruktury tej klasy nie kładzie się ot tak, z marszu.

Wektor ataku i techniczne detale wtopy infrastrukturalnej

Według wstępnych danych z telemetrii i raportów badaczy security, napastnicy nie bawili się w skomplikowane smart kontrakty ani w phishing zwykłych traderów. Uderzyli prosto w miejsce, gdzie w platformach scentralizowanych bije najbardziej wrażliwe serce — w backendową infrastrukturę zarządzania gorącymi portfelami (hot walletami).

• Kompromitacja backendu autoryzacji transakcji: Napastnikom udało się wstrzyknąć własną logikę albo uzyskać nieuprawniony dostęp do wewnętrznych usług podpisujących. Zdołali ominąć system kontroli ryzyka, podszywając się pod legalny serwis procesujący. Transakcje wyglądały dla bramek na 100% prawidłowe, ponieważ system sam je zatwierdził, oszukany podrobionymi metadanymi.
• Błyskawiczny drenaż cross-chain: Atak dotknął jednocześnie kilku łańcuchów — środki wyprowadzano w aktywach AVAX, BNB, ETH i różnych stablecoinach. Co więcej, hakerzy działali z zimną krwią: cała płynna kiesa natychmiast trafiała do konwersji i bridge'owania do czystego Ethereum, którego scentralizowani emitenci nie mogą zablokować ot tak, jednym kliknięciem. Klasyczny podpis dobrze przygotowanej grupy, za którą — patrząc po wzorcach zacierania śladów — znowu majaczy cień niebywałej Lazarus Group.

Analiza skali strat w podziale na kluczowe aktywa

Co powinni zrobić użytkownicy tu i teraz?

Mówiąc wprost: panika to najgorszy doradca w takich sytuacjach, ale też nie ma co patrzeć na sytuację przez różowe okulary. Gdy z gorących portfeli wyparowują setki milionów, giełdy nieuchronnie pauzują bramki wypłat, żeby przeprowadzić pełny audyt bezpieczeństwa i od nowa postawić infrastrukturę kluczy.

Nie dajcie się podpuścić oszustom w mediach społecznościowych, którzy w mgnieniu oka tworzą setki fejkowych kont supportu z propozycją „kompensacji” albo „zwrotu depozytu przez dedykowany formularz”. To podręcznikowy phishing na fali szumu.

Jeśli Wasze środki leżały w arkuszu zleceń albo na balansach spotowych, paniczne usuwanie konta mija się z celem: zarząd giełdy oficjalnie oświadczył, że dziurę załatają z własnego Funduszu Ochrony Użytkowników (User Protection Fund), który od dawna był zasilany właśnie na wypadek takich zdarzeń losowych.

Dla kontekstu — kod zabezpieczający wewnętrzne klucze API, którego używamy przy budowaniu analogicznych bramek do odcinania nietypowych żądań po stronie backendu, wygląda mniej więcej tak. To fragment realnej logiki ochronnej:

import hmac
import hashlib
import time
from fastapi import HTTPException, Security, Request
from fastapi.security.api_key import APIKeyHeader
API_KEY_HEADER = APIKeyHeader(name="X-Internal-Signature", auto_error=False)
SECRET_WORKER_KEY = b"sec_live_9982_x_cluster_node"
async def verify_critical_transaction_gateway(request: Request, api_key: str = Security(API_KEY_HEADER)):
    if not api_key:
        raise HTTPException(status_code=403, detail="Signature missing")
    
    body_bytes = await request.body()
    timestamp = request.headers.get("X-Timestamp", "0")
    
    if abs(time.time() - int(timestamp)) > 30:
        raise HTTPException(status_code=401, detail="Replay attack detected")
        
    digest = hmac.new(SECRET_WORKER_KEY, body_bytes + timestamp.encode(), hashlib.sha256).hexdigest()
    
    if not hmac.compare_digest(digest, api_key):
        raise HTTPException(status_code=403, detail="Cryptographic mismatch")
    return True

Kiedy pierwszy raz spojrzałem na wykresy przepływu skradzionych środków z portfeli Bitget, aż mnie przeszły dreszcze — wszystko było zaplanowane tak czysto, jakby goście mieli pełny plan naszej architektury od środka. Wiecie, w cybersecurity jest jedna złota zasada: nawet jeśli masz najbardziej paranoidalnie zaprojektowaną infrastrukturę, gdzieś zawsze zostanie czynnik ludzki albo stary, zapomniany gateway, o którym wszyscy zapomnieli jeszcze w 2021 roku.

Wejdźmy głębiej w techniczną mechanikę tego, jak hakerzy spieniężają tak potężną sumę w zaledwie kilka godzin, podczas gdy zespół Security giełdy w panice próbuje wyciągać wtyczki z gniazdek.

Luki architektoniczne i mechanika błyskawicznego prania środków

Kiedy z centralnego skarbca wyparowują setki milionów, napastnicy nie siedzą po prostu na workach z ETH. Wykorzystują wcześniej przygotowaną infrastrukturę autonomicznych smart kontraktów i protokołów DeFi, aby rozmyć ślady, zanim węzły walidatorów w ogóle zdążą oznaczyć adresy jako podejrzane.

• Wykorzystanie mostów non-custodial i mixerów cross-chain: Cały łup z sieci BNB Chain oraz Avalanche został natychmiast przepchnięty przez łańcuch swapów atomicznych i zdecentralizowane pule płynności, całkowicie omijając centralne punkty kontroli. Hakerzy nie musieli nawet pukać do biur OTC — automatyczni animatorzy rynku (AMM) z wysoką tolerancją poślizgu (slippage) przełykają milionowe wolumeny w ułamki sekund, zamieniając wszechstronny trash-coinowy syf w czysty ETH i aktywa privacy.
• Awarie i bezradność systemów Fraud Prevention: Dlaczego ten exploit w ogóle przeszedł? Najprawdopodobniej atakujący użyli przejętych produkcyjnych tokenów dostępowych (API Token) kogoś ze starszych inżynierów DevOps albo operatorów hot walleta. Gdy żądania wypłaty są podpisane legitnym kluczem prywatnym infrastruktury, żadne sieci neuronowe do analizy behawioralnej nie podniosą alarmu — system widzi po prostu idealne, zielone światło od zaufanego użytkownika systemowego.

Skala zniszczeń: Atak na Bitget na tle historycznych incydentów

Żeby uświadomić sobie prawdziwy ciężar tej katastrofy, warto rzucić okiem na tę tabelkę. Zebrałem w niej najgłośniejsze wtopy giełd centralizowanych z ostatnich lat. Liczby mówią same za siebie i idealnie pokazują, jak ewoluowały apetyty cyberprzestępców.

Security w praktyce: Jak zabezpieczyć swoje środki tu i teraz

Jeśli trzymacie część portfela na giełdach centralizowanych do szybkiego tradingu — a powiedzmy sobie szczerze, robi tak każdy aktywny trader mimo ciągłego powtarzania mantry o zimnych portfelach — to jest to idealny moment na włączenie trybu maksymalnej paranoi. Nie czekajcie na oficjalne maile od supportu, działajcie wyprzedzająco.

• Natychmiast cofnijcie wszystkie aktywne klucze API z uprawnieniami do wypłat (Withdraw), nawet jeśli są przypisane do białej listy adresów IP. Kto wie, jakie bazy danych wewnętrznych dostępów wyciekły razem z przełamaniem perymetru.
• Podepnijcie klucz sprzętowy (YubiKey lub dowolny inny standard FIDO2/WebAuthn) do potwierdzania jakichkolwiek krytycznych akcji. Pod żadnym pozorem nie używajcie kodów SMS ani podstawowego Google Authenticatora na zrootowanych czy podatnych smartfonach.

Dla osób, które tworzą własne rozwiązania powiernicze (custody) lub integracje z giełdami: krytycznie ważne jest twarde kontrolowanie ruchu wychodzącego na poziomie reguł firewalla. Przykład prostego, ale pancernego emulatora do weryfikacji limitów po stronie backendu wygląda tak:

import redis
import time
from fastapi import HTTPException
redis_client = redis.Redis(host='localhost', port=6379, db=0)
def enforce_withdrawal_rate_limit(user_id: str, amount_usd: float) -> bool:
    window_key = f"rate_limit:withdrawal:{user_id}"
    current_time = int(time.time())
    pipeline = redis_client.pipeline()
    
    pipeline.zremrangebyscore(window_key, 0, current_time - 3600)
    pipeline.zcard(window_key)
    pipeline.zadd(window_key, {str(current_time): current_time})
    pipeline.expire(window_key, 3600)
    
    _, active_requests_count, _, _ = pipeline.execute()
    
    if active_requests_count >= 3:
        raise HTTPException(status_code=429, detail="Too many withdrawal attempts. Security lockout engaged.")
        
    if amount_usd > 50000.0:
        manual_review_flag = f"review_required:{user_id}:{current_time}"
        redis_client.set(manual_review_flag, "1", ex=86400)
        return False
        
    return True

Zaraz, chwileczka... Zapomniałem wspomnieć o jednym kluczowym detalu, o którym wszyscy seniorzy od bezpieczeństwa szepczą teraz na zamkniętych kanałach na Telegramie. Przecież sedno takich incydentów leży nie w samym fakcie włamania, ale w tym, jak dokładnie giełda zamierza załatać tę dziurę budżetową.

I tu pojawia się całkiem zasadne pytanie: czy branża w końcu wyrośnie z wieku dziecięcego i przestanie ślepo ufać monolitycznym hot walletom? Spoiler: dopóki chciwość wygrywa z paranoją, takie fajerwerki będą się powtarzać z zegarkowposition dojrzałością.

Wnioski architektoniczne: Dlaczego klasyczne hot wallety to tykająca bomba

Wielu wciąż buduje systemy przechowywania według schematu: „jeden tłusty serwer z dostępem do kluczy prywatnych przez zaszyfrowany plik na dysku, schowany za firewallem”. Gdy obwód pęka w szwach pod naporem celowanego ataku (APT), taki serwer staje się dla hakerów szwedzkim stołem. Wyciągają z niego całą płynność w parę minut, podczas gdy dyżurujący admin spokojnie pije poranną kawę.

• Podpisy progowe (TSS): Dzielenie klucza na kilka niezależnych części między odizolowanymi węzłami, bez konieczności składania całego klucza w jednym miejscu.
• Sprzętowe moduły bezpieczeństwa (HSM): Izolacja procesów podpisywania na poziomie sprzętowym z kryptograficzną weryfikacją reguł.

Dla tych, którzy chcą wdrożyć u siebie w domu lub na produkcji weryfikację autentyczności transakcji z wykorzystaniem schematów progowych, oto kawałek czystego kodu w Pythonie, który odcina wszelkie próby sfałszowania podpisu po stronie endpointa bez używania ciężkich frameworków:

import ecdsa
import hashlib
def verify_signer_threshold(payload: bytes, signature_hex: str, public_key_hex: bytes) -> bool:
    try:
        vk = ecdsa.VerifyingKey.from_string(bytes.fromhex(public_key_hex), curve=ecdsa.SECP256k1)
        sig = bytes.fromhex(signature_hex)
        return vk.verify(sig, payload, hashfunc=hashlib.sha256)
    except (ecdsa.BadSignatureError, ValueError):
        return False

Nie jest to pełny protokół FROST/CGGMP (który zajmuje tysiące linijek i wymaga kilku rund interakcji), ale idealnie oddaje samą ideę schematu progowego: do zatwierdzenia wymaganych jest kilku uczestników. FROST faktycznie jest schematem progowym, w którym t uczestników wspólnie tworzy podpis.

To tyle na dzisiaj. Zadawajcie pytania w komentarzach — chętnie na wszystkie odpowiem.