Wprowadzenie do problemu / definicja luki
Incydent Trust Wallet z końca grudnia 2025 r. to klasyczny przykład ataków supply chain na rozszerzenia przeglądarki: użytkownicy instalują/aktualizują „zaufany” komponent z oficjalnego sklepu, a w praktyce otrzymują paczkę ze złośliwą logiką. W tym przypadku atak dotyczył rozszerzenia Trust Wallet dla Chrome w wersji 2.68, które zostało wykorzystane do eksfiltracji wrażliwych danych portfela (w tym fraz mnemonicznych) i szybkiego opróżniania środków.
W skrócie
- Skala strat: Trust Wallet potwierdził ok. 7 mln USD strat i 2 596 „dotkniętych” adresów portfeli.
- Wektor: złośliwa aktualizacja Chrome Extension v2.68.0; zalecana aktualizacja do v2.69.
- Mechanika: złośliwy kod miał działać w ścieżce odblokowania portfela (nie tylko przy imporcie seeda), a wykradzione dane trafiały na domenę podszywającą się pod infrastrukturę telemetryczną.
- Zakres: według CEO Trust Wallet dotyczyło to wyłącznie użytkowników rozszerzenia v2.68, którzy logowali się w oknie czasowym (m.in. przed 26.12.2025, 11:00 UTC).
- Dogrywka atakujących: obserwowano phishing pod pretekstem „naprawy/aktualizacji” i fałszywe formularze „kompensacyjne”.
Kontekst / historia / powiązania
Z perspektywy operacyjnej ten incydent jest ważny, bo pokazuje „słaby punkt” self-custody: choćby jeżeli klucze są po stronie użytkownika, to kanał dystrybucji systemu (Chrome Web Store) i proces wydawniczy stają się elementem krytycznym. CEO Trust Wallet wskazał, iż złośliwa wersja miała zostać opublikowana z pominięciem standardowej procedury – hipoteza mówi o użyciu wykradzionego klucza API Chrome Web Store do wgrania wydania 2.68 (24.12.2025, 12:32 UTC).
Kontekstowo warto też zauważyć powtarzalność „świątecznego okna” dla ataków na rozszerzenia (mniej obsady w zespołach reagowania, wolniejsze procesy weryfikacji, większa szansa na szybki „cash-out”).
Analiza techniczna / szczegóły luki
Z dostępnych opisów wynika następujący łańcuch zdarzeń:
- Dystrybucja złośliwego wydania
- Wersja 2.68.0 została opublikowana w Chrome Web Store i trafiła do użytkowników jako aktualizacja.
- Trust Wallet: złośliwa wersja nie przeszła standardowego „manual release”, a publikacja mogła nastąpić z użyciem Chrome Web Store API key (hipoteza w toku).
- Eksfiltracja danych i przejęcie portfeli
- Według opisu przytaczanego przez media branżowe, kod w 2.68 miał iterować po portfelach w rozszerzeniu, doprowadzać do uzyskania/odszyfrowania mnemonika (w momencie odblokowania) i wysyłać go na serwer atakującego.
- Analiza Koi Security podkreśla, iż trigger miał następować na każdym odblokowaniu, co znacząco zwiększa „blast radius” (to nie musiał być wyłącznie import seeda).
- „Legalna” telemetria jako kanał wycieku
- W opisach pojawia się motyw użycia legalnej biblioteki analitycznej (PostHog) i przekierowania ruchu na domenę wyglądającą „firmowo”, m.in. api.metrics-trustwallet[.]com.
- Działania ograniczające skutki
- Trust Wallet raportował domenę eksfiltracyjną do rejestratora (NiceNIC), co doprowadziło do jej zawieszenia, oraz wygasił interfejsy/release API na czas stabilizacji.
Praktyczne konsekwencje / ryzyko
Najważniejsze ryzyko w tego typu incydencie jest proste: jeżeli frazę odzyskiwania (seed/mnemonic) przejęto, to atakujący mogą odtworzyć portfel na własnym urządzeniu i opróżnić środki bez „dalszego dostępu” do Twojego komputera.
Dodatkowo, incydenty wokół portfeli kryptowalut niemal zawsze generują wtórne kampanie:
- fałszywe formularze odszkodowań, „weryfikacje portfela”, reklamy w Telegramie i podszywanie się pod support,
- prośby o seed/klucz prywatny „do odzyskania środków” (to zawsze oszustwo).
Rekomendacje operacyjne / co zrobić teraz
Jeśli jesteś użytkownikiem Trust Wallet (Chrome)
- Sprawdź wersję rozszerzenia: jeżeli miałeś v2.68, natychmiast przejdź na v2.69 (zgodnie z komunikatami Trust Wallet).
- Jeśli w okresie incydentu odblokowywałeś portfel na v2.68, traktuj seed jako potencjalnie skompromitowany i:
- utwórz nowy portfel (nowy seed),
- przetransferuj aktywa na nowe adresy,
- rozważ dodatkowe kroki higieny (np. porządki w urządzeniu, zmiana haseł menedżerów itp.). (W praktyce: przy kradzieży seeda „naprawa” starego portfela nie istnieje).
- Uważaj na komunikaty spoza oficjalnych kanałów i nigdy nie podawaj seeda/kluczy „do weryfikacji”.
Jeśli odpowiadasz za bezpieczeństwo w organizacji
- Wprowadź politykę „update cooldown” dla rozszerzeń (opóźnianie rolloutów o 48–72h), aby dać czas na sygnały ze społeczności i szybkie analizy binarne/manifestu.
- Monitoruj różnice w manifest.json i uprawnieniach między wersjami, a także nietypowe zmiany w endpointach telemetrycznych/analitycznych.
- Rozważ ograniczenie użycia portfeli w formie rozszerzeń w środowiskach wrażliwych (preferencja: aplikacje dedykowane + hardware wallets dla środków o wysokiej wartości).
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
W porównaniu do wielu „crypto-drainerów” opartych o phishing i fałszywe dApps, tutaj najważniejszy był zaufany kanał aktualizacji (Chrome Web Store) i atak na warstwę dystrybucji. To podobny „rodzaj problemu” jak inne incydenty supply chain na rozszerzeniach: użytkownik robi wszystko „poprawnie” (aktualizuje), a mimo to traci środki.
Podsumowanie / najważniejsze wnioski
- Incydent Trust Wallet v2.68 pokazuje, iż dla self-custody łańcuch dostaw oprogramowania jest tak samo krytyczny jak kryptografia.
- „Okno kompromitacji” i sam fakt, iż trigger mógł działać przy odblokowaniu, oznacza, iż w podobnych incydentach należy myśleć kategoriami masowej ekspozycji seeda, a nie pojedynczych błędów użytkownika.
- Największym zagrożeniem po ataku bywa wtórny phishing (fałszywe rekompensaty, podszywanie się pod support).
Źródła / bibliografia
- BleepingComputer — Trust Wallet says 2,596 wallets drained in $7 million crypto theft attack (BleepingComputer)
- The Hacker News — Trust Wallet Chrome Extension Breach Caused $7 Million Crypto Loss via Malicious Code (The Hacker News)
- Oświadczenie CEO (mirror w ThreadNavigator) — wątek dot. zakresu, hipotezy o API key i działań naprawczych (Thread Navigator)
- Koi Security — Trust Wallet Compromised: Inside the Code That Stole $7M on Christmas Eve (analiza techniczna i wnioski operacyjne) (Koi)
