Włamanie do Binance (2026): Jak skradziono 6,3 mld USD i czym jest EIP-7702?

W czwartek, 29 października, analitycy on-chain oraz użytkownicy zaczęli alarmować o nietypowych, masowych wypływach środków z portfeli powiązanych z największą giełdą kryptowalut na świecie. W pierwszej fazie kryzysu komunikacyjnego przedstawiciele Binance zapewniali, że aktywa są bezpieczne, a ruchy wynikają z rutynowych operacji technicznych. Krótko po tym giełda wstrzymała jednak wypłaty w wielu sieciach i oficjalnie potwierdziła incydent bezpieczeństwa.

Współzałożyciel platformy, Changpeng Zhao (CZ), przyznał w serwisie X, że sytuacja wygląda na włamanie. Dynamika szacunków pokazała skalę uderzenia: w ciągu niespełna 24 godzin wstępne wyliczenia wzrosły z „co najmniej 2 mld USD” do astronomicznych 6,3 mld USD, co czyni ten atak największą kradzieżą w historii sektora kryptowalut.

Dla właściwej oceny skali: według agregatora DefiLlama, tuż przed atakiem Binance przechowywało na swoich adresach aktywa o łącznej wartości około 144 mld USD. Z perspektywy czysto bilansowej ubytek rzędu 4,3% całości rezerw pozwala analitykom rynkowym oceniać, że incydent nie powinien zachwiać bezpośrednią wypłacalnością giełdy. Należy jednak pamiętać, że jest to ocena rynkowa oparta na publicznych danych on-chain, a nie formalna gwarancja audytorska.

Jak mogło dojść do ataku: dwie warstwy operacji

Z dotychczasowych komunikatów oraz niezależnych analiz wyłania się obraz ataku dwuwarstwowego, łączącego klasyczną infiltrację korporacyjnej infrastruktury IT z zaawansowaną manipulacją mechanizmami sieci Ethereum.

Warstwa 1: Wejście do infrastruktury (kompromitacja stacji roboczej)

We wstępnych ustaleniach Binance wskazało, że łańcuch ataku rozpoczął się od przejęcia laptopa należącego do pracownika. Część mediów branżowych precyzuje, że chodziło o stację roboczą inżyniera DevOps. W architekturze nowoczesnych firm technologicznych tego typu urządzenia stanowią cel o najwyższym priorytecie – posiadają aktywne sesje do klastrów kontenerowych, systemów CI/CD, repozytoriów kodu oraz menedżerów sekretów.

Wykorzystując przejęte poświadczenia i uprawnienia z laptopa, atakujący zdołali uzyskać dostęp do wewnętrznego kontenera usługi odpowiedzialnej za obsługę transakcji, co otworzyło im drogę do autoryzowania wypłat z pominięciem standardowych procedur weryfikacji użytkownika.

Warstwa 2: Wyprowadzenie pieniędzy i wykorzystanie EIP-7702

Drugą część układanki przedstawiła firma Blockaid, specjalizująca się w bezpieczeństwie blockchaina. Według jej badaczy napastnicy użyli mechanizmu autoryzacji wprowadzonego w aktualizacji Ethereum EIP-7702.

Z analizy Blockaid wynika, że atakujący wygenerowali aż 50 żądań autoryzacji, z których jedno skutecznie trafiło w gorący portfel oznaczony jako „Binance 14” i przekierowało jego logikę na złośliwy inteligentny kontrakt kontrolowany przez hakerów. Dlaczego potrzebowali aż 50 prób? Portfel „Binance 14” w momencie ataku cały czas przetwarzał tysiące legalnych wypłat klientów. W sieci Ethereum każda kolejna transakcja z danego adresu musi posiadać ściśle określony, rosnący numer porządkowy (nonce). Ponieważ portfel był w ciągłym ruchu, precyzyjne trafienie z właściwym numerem nonce wymagało zasypania sieci serią autoryzacji wycelowanych w przewidywane, przyszłe wartości licznika.

Ważne zastrzeżenie: opis wykorzytania EIP-7702 pochodzi na ten moment od jednego dostawcy analiz (Blockaid) i nie został jeszcze oficjalnie potwierdzony w raporcie technicznym samego Binance.

Czym jest EIP-7702 (w skrócie technicznym)

EIP-7702 to propozycja ulepszenia sieci Ethereum wdrożona w 2025 roku (w ramach aktualizacji Pectra), stanowiąca pomost w stronę pełnej abstrakcji kont (Account Abstraction). Mechanizm ten pozwala zwykłemu portfelowi kontrolowanemu przez klucz prywatny (EOA – Externally Owned Account) tymczasowo lub trwale wskazać adres inteligentnego kontraktu, którego kod ma być wykonywany w imieniu tego portfela.

W codziennych zastosowaniach daje to ogromną wygodę: zwykły portfel może grupować wiele operacji w jedną transakcję (np. approve + swap) albo pozwalać na opłacanie gazu przez podmiot trzeci. Jednak z punktu widzenia bezpieczeństwa EIP-7702 zmienia model zagrożeń:

• W klasycznym scenariuszu atakujący musi podpisać transakcję przesyłającą konkretny token lub ETH.
• W scenariuszu z EIP-7702 wystarczy uzyskać jeden ważny podpis autoryzacji delegacji. Po jego zatwierdzeniu konto EOA zaczyna wykonywać kod złośliwego kontraktu, co pozwala opróżnić portfel ze wszystkich zasobów w jednym kroku.

Z tego powodu w systemach korporacyjnych podpisywanie obiektów autoryzacji EIP-7702 musi podlegać tak samo rygorystycznym politykom bezpieczeństwa, jak podpisywanie bezpośrednich transferów wielomilionowych kwot.

Czego jeszcze nie wiemy?

1. Jak wygenerowano prawidłowe podpisy kryptograficzne? Binance utrzymuje, że w toku dotychczasowego dochodzenia nie znaleziono dowodów na bezpośredni wyciek kluczy prywatnych (private keys). Z kolei eksperci TRM Labs oceniają, że doszło do „kompromitacji infrastruktury podpisującej gorących portfeli”. Te dwa twierdzenia wcale się nie wykluczają. W systemach klasy enterprise klucz prywatny (lub jego udziały MPC/HSM) nigdy nie leży w pliku tekstowym – dostęp do niego ma wyizolowana usługa (signing daemon). Jeśli napastnik przejmie kontener mający prawo wysyłać do tej usługi sfabrykowane, ale poprawne strukturalnie żądania, moduł podpisujący posłusznie wygeneruje ważny podpis bez ujawniania samego klucza na zewnątrz. Jest to nasza techniczna interpretacja architektury, czekająca na potwierdzenie w końcowym post-mortem.
2. Jaka jest ostateczna kwota strat? Różnice w szacunkach (6,3 mld, 6,36 mld, 6,4 mld USD) wynikają z wahań kursowych skradzionych altcoinów w momencie przewalutowania przez hakerów na zdecentralizowanych giełdach (DEX) oraz różnej klasyfikacji adresów pośredniczących.
3. Kto dokładnie stoi za operacją? Zbieżność taktyk, technik i procedur (TTP) – w tym uderzenie w stację roboczą inżyniera, błyskawiczne rozproszenie środków przez mosty cross-chain i miksery – skłoniła TRM Labs oraz Chainalysis do wskazania na północnokoreańską grupę TraderTraitor. To ta sama jednostka, którą FBI obarczyło odpowiedzialnością za kradzież około 1,5 mld USD z giełdy Bybit w lutym 2025 roku. Jak pokazuje historia cyberbezpieczeństwa, wczesna atrybucja bywa jednak korygowana w miarę napływu dowodów z analizy logów serwerowych.

Reakcja rynku i zamrażanie aktywów

Skala ataku wymusiła bezprecedensową koordynację podmiotów emitujących scentralizowane aktywa cyfrowe:

• Tether poinformował o dodaniu adresów agresora do czarnej listy i zablokowaniu ponad 1,5 mld USDT.
• Circle zamroziło portfele zawierające około 800 mln USDC.
• Binance oszacowało, że dzięki współpracy z partnerami branżowymi, mostami i innymi giełdami udało się unieruchomić aktywa o łącznej wartości około 3 mld USD. Jednocześnie giełda przesunęła ponad 6,3 mld USD ze swoich rezerw oraz funduszu awaryjnego SAFU w celu pełnego pokrycia niedoborów.

Wnioski dla firm i zespołów bezpieczeństwa (Blue Team / SecOps)

1. Stacje robocze administratorów i DevOps to cel numer jeden. Oddziel stacje robocze służące do zarządzania infrastrukturą produkcyjną (PAW – Privileged Access Workstations) od komputerów do codziennej komunikacji, przeglądania sieci czy testowania zewnętrznych paczek kodu. Wymuś sprzętowe uwierzytelnianie FIDO2, EDR w trybie blokowania oraz dostęp warunkowy (Zero Trust).
2. Niezależna warstwa walidacji w usłudze podpisującej (Policy Engine). Moduł HSM/MPC nie może bezkrytycznie ufać kontenerowi aplikacyjnemu tylko dlatego, że żądanie pochodzi z wewnętrznej sieci. Wdróż twarde limity kwotowe w oknach czasowych (rate-limiting wartości), białe listy adresów docelowych oraz niezależną symulację skutków transakcji przed złożeniem podpisu.
3. Monitoring transakcji typu 0x04 (EIP-7702). Większość starszych reguł SIEM i skryptów monitorujących portfele korporacyjne śledzi wyłącznie wywołania transfer, approve lub zmianę właściciela w kontraktach multisig. Dodaj natychmiastowe reguły alertowania na pojawienie się autoryzacji delegacji EIP-7702 na adresach EOA, które z założenia nigdy nie powinny delegować swojego kodu.
4. Rygorystyczna minimalizacja sald na gorących portfelach. Gorący portfel powinien zawierać wyłącznie płynność niezbędną do obsłużenia bieżącego okna wypłat (np. 15–30 minut ruchu), a reszta środków musi spoczywać w architekturze air-gapped / cold storage z wieloosobowym, fizycznym zatwierdzaniem przesunięć.
5. Gotowe kanały eskalacji z emitentami stablecoinów. W przypadku drenażu liczy się każda minuta, zanim napastnik zamieni USDT/USDC na natywne ETH lub BTC w pulach płynności. Procedury Incident Response w firmach Web3 muszą zawierać bezpośrednie, zweryfikowane kontakty 24/7 do zespołów bezpieczeństwa największych emitentów i mostów.

Co to oznacza dla zwykłego użytkownika?

Choć Binance zadeklarowało pełne pokrycie strat i przywraca obsługę sieci, pamiętaj, że oświadczenie prasowe firmy to deklaracja biznesowa, a nie państwowa gwarancja depozytowa pokroju BFG.

• Uważaj na falę wtórnego phishingu: Po każdym głośnym włamaniu grupy przestępcze rozsyłają tysiące fałszywych wiadomości SMS i e-mail podających się za giełdę, informujących o konieczności „weryfikacji konta po ataku”, „odbioru rekompensaty z funduszu SAFU” lub „migracji środków na bezpieczny portfel”.
• Nie klikaj w żadne linki z powiadomień: Loguj się wyłącznie przez oficjalną aplikację mobilną lub adres wpisany własnoręcznie w przeglądarce.
• Sprawdź swoje zabezpieczenia: Upewnij się, że na koncie giełdowym masz aktywny klucz sprzętowy (Passkey/FIDO2) oraz włączoną białą listę adresów wypłat (Withdrawal Whitelist) z blokadą czasową na dodawanie nowych portfeli.

Coś więcej…

Patrząc na techniczny przebieg tego incydentu, najbardziej uderza nas jeden szczegół architektoniczny, o którym rzadko mówi się w oficjalnych komunikatach: zjawisko „ślepego zaufania” wewnątrz potoków podpisujących. Przez ostatnie dwa lata branża krypto wydała setki milionów dolarów na audyty inteligentnych kontraktów i kryptografię progową (MPC). Problem w tym, że nawet najdoskonalszy klaster MPC staje się bezużyteczny, jeśli decyzję o tym, co zostaje podpisane, podejmuje pojedynczy kontener mikroserwisu, do którego dostęp ma inżynier z poziomu swojego laptopa.

Zwróćcie uwagę na wykorzystanie EIP-7702 i 50 prób wstrzelenia się w licznik nonce portfela „Binance 14”. To dowodzi, że atakujący nie mieli pełnej, spokojnej kontroli nad kolejką transakcji – musieli „ścigać się” z legalnym ruchem giełdy. Gdyby po stronie silnika podpisującego działał prosty filtr behawioralny blokujący nietypowe typy transakcji (gorący portfel giełdowy służący do prostych wypłat nie ma żadnego biznesowego powodu, by nagle wysyłać transakcję typu 0x04 delegującą kod konta EOA!), cały atak za 6,3 mld dolarów rozbiłby się o ścianę w ułamku sekundy, mimo przejętego laptopa DevOps. Dla nas w redakcji to ostateczny dowód na to, że zasada „Not your keys, not your crypto” ma dziś drugie dno: na giełdzie Twoje środki są tak bezpieczne, jak najgorzej zabezpieczony laptop inżyniera utrzymującego jej kontenery. Traktujcie giełdy jak kantor wymiany, nie jak sejf.