Wprowadzenie do problemu / definicja luki
Pod koniec grudnia 2025 r. doszło do klasycznego incydentu supply chain w ekosystemie przeglądarkowych portfeli krypto: do oficjalnego kanału dystrybucji (Chrome Web Store) trafiła złośliwa wersja rozszerzenia Trust Wallet. Skutek był natychmiastowy: użytkownicy zgłaszali „opróżnianie” portfeli po zwykłym odblokowaniu wtyczki, a Trust Wallet potwierdził incydent i wskazał, iż dotyczy on wyłącznie wersji 2.68, z zaleceniem pilnej aktualizacji do 2.69.
W skrócie
- Co się stało: złośliwa aktualizacja rozszerzenia Trust Wallet dla Chrome (v2.68) wprowadziła mechanizm wykradania fraz mnemonicznych (seed phrase).
- Skala: Trust Wallet komunikował ok. 7 mln USD strat i zapowiedział refundacje dla poszkodowanych.
- Okno czasowe: publikacja złośliwej wersji nastąpiła 24 grudnia 2025, a incydent dotyczył aktywności użytkowników w dniach 24–26 grudnia 2025 (z komunikacji wynika też graniczny czas aktywności przed 26.12, 11:00 UTC).
- Dodatkowe ryzyko: równolegle obserwowano kampanie phishingowe podszywające się pod „naprawy” Trust Wallet i wyłudzające seedy.
Kontekst / historia / powiązania
Ataki na rozszerzenia przeglądarkowe są atrakcyjne, bo aktualizacje „zaufanych” wtyczek rozchodzą się automatycznie i mają szerokie uprawnienia. W omawianym przypadku analitycy zwracają uwagę na powtarzalny schemat: złośliwy update w okresie świątecznym, szybkie wykrycie przez społeczność, ale i realne straty zanim organizacje/ użytkownicy zareagują.
Analiza techniczna / szczegóły luki
1) Co dokładnie robiła złośliwa wersja 2.68
Z technicznego punktu widzenia to nie była „pojedyncza luka”, tylko złośliwa modyfikacja logiki aplikacji. Wersja 2.68 miała zawierać kod, który:
- uruchamia się w przepływie odblokowania portfela (nie tylko przy imporcie seed phrase),
- iteruje po portfelach w profilu (multi-wallet),
- pozyskuje/dekoduje mnemonik i wysyła go na zewnętrzny endpoint podszywający się pod telemetrię/analytics.
Istotny detal z analiz: raporty medialne często sugerowały, iż zagrożeni byli tylko ci, którzy „importowali seeda”. Tymczasem analiza kodu wskazuje, iż sam fakt odblokowania rozszerzenia w oknie kompromitacji mógł wystarczyć, by seed został wyeksfiltrowany.
2) Eksfiltracja pod przykrywką analityki (PostHog)
W badaniach opisywano „sprytny” zabieg: modyfikację inicjalizacji analityki tak, aby dane (w tym seed phrase) trafiały na domenę wyglądającą jak infrastruktura Trust Wallet, np. api.metrics-trustwallet[.]com.
3) Artefakty i wskaźniki kompromitacji (IOC)
W materiałach analitycznych pojawiają się m.in. następujące IOC:
- Extension ID: egjidjbpglichdcondbcbdnbeeppgdph
- Compromised Version: 2.68.0
- Malicious domain: metrics-trustwallet[.]com (w tym api.metrics-trustwallet[.]com)
- Malicious files (przykłady): 4482.js, 8423.js
- Przykładowy IP dla infrastruktury eksfiltracji: 138.124.70.40
4) Prawdopodobny wektor: kanał publikacji / klucze do dystrybucji
Wątek najważniejszy operacyjnie: jak złośliwa wersja przeszła przez oficjalny kanał? W relacjach wskazywano możliwość nadużycia mechanizmu publikacji (np. uprawnień / klucza API Chrome Web Store), co ma znaczenie dla wszystkich dostawców rozszerzeń, nie tylko Trust Wallet.
Praktyczne konsekwencje / ryzyko
Najważniejszy wniosek dla użytkownika: kradzież seed phrase oznacza pełną, trwałą kompromitację — nie da się tego „odkręcić” zmianą hasła do rozszerzenia. jeżeli seed wyciekł, atakujący może odtworzyć portfel i podpisać transfery poza Twoją kontrolą.
Dodatkowo incydenty tego typu napędzają wtórne ryzyko: kampanie phishingowe „na gorąco”, w których przestępcy podsuwają fałszywe formularze/strony naprawcze i wyłudzają seedy od spanikowanych użytkowników.
Rekomendacje operacyjne / co zrobić teraz
Jeśli używałeś Trust Wallet w Chrome (szczególnie 24–26.12.2025)
- Nie uruchamiaj ponownie rozszerzenia, dopóki nie upewnisz się, iż masz wersję 2.69 (lub nowszą).
- Jeśli w tym oknie czasowym odblokowałeś rozszerzenie w wersji 2.68: potraktuj seed jako ujawniony.
- Przenieś środki do nowego portfela utworzonego na świeżym seedzie (najlepiej na urządzeniu/hardware wallet).
- Sprawdź zatwierdzenia (approvals/allowances) w dAppach, z których korzystałeś, i cofnij podejrzane/niepotrzebne (to ogranicza „drenaż” tokenów z kontraktów).
- Uważaj na „pomoc” w DM, reklamy Telegram/Google, „formularze kompensacyjne” spoza oficjalnych kanałów. W samym incydencie obserwowano podszywanie się pod naprawę i wyłudzanie seedów.
- Jeśli poniosłeś straty: korzystaj z oficjalnego formularza roszczeń Trust Wallet i nigdy nie podawaj tam seed phrase ani kluczy prywatnych (formularz tego nie wymaga).
Jeśli odpowiadasz za bezpieczeństwo w organizacji (IT/SecOps)
- Wprowadź politykę „update cooldown” dla rozszerzeń (np. opóźnienie wdrożeń o 48–72h) oraz monitorowanie różnic manifestów/artefaktów między wersjami — to prosta kontrola, która często „wygrywa” z atakami świątecznymi.
- Traktuj portfele przeglądarkowe jak oprogramowanie wysokiego ryzyka (uprzywilejowany kontekst) i rozważ ograniczenia: allowlist rozszerzeń, izolowane profile przeglądarki, EDR z regułami na nietypowe domeny telemetryczne, itp.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
To zdarzenie przypomina inne głośne incydenty, w których legalny mechanizm aktualizacji rozszerzeń stał się wektorem ataku, a kluczową rolę odegrało okno „poza godzinami” i opóźniona reakcja części użytkowników. W analizach podkreślano, iż wzorzec „świąteczny supply chain na Chrome Web Store” zaczyna być powtarzalny i warto go uwzględniać w planowaniu kontroli zmian.
Podsumowanie / najważniejsze wnioski
- To nie była „zwykła luka”, tylko kompromitacja łańcucha dostaw: złośliwy update Trust Wallet Chrome Extension 2.68.
- Seed phrase mogły wyciekać przy samym odblokowaniu — dlatego najważniejsze jest założenie kompromitacji i migracja środków na nowy seed.
- Równolegle działał phishing wykorzystujący chaos informacyjny.
- Dla firm i zespołów: minimalnym „must-have” staje się kontrola aktualizacji rozszerzeń (cooldown + monitoring zmian), bo oficjalny kanał dystrybucji nie gwarantuje bezpieczeństwa.
Źródła / bibliografia
- The Hacker News — opis incydentu, wersje 2.68/2.69, refundacje, szczegóły publikacji i komunikacji Trust Wallet (The Hacker News)
- BleepingComputer — timeline, podejrzana domena, obserwacje kampanii phishingowych (BleepingComputer)
- Koi Security — analiza techniczna (mechanizm eksfiltracji, pliki, IOC, „update cooldown”) (Koi)
- Trust Wallet (Freshdesk) — oficjalny formularz roszczeń i zakres dat incydentu (Browser Extension Claims)
- The Verge — podsumowanie mainstreamowe i potwierdzenie skali strat (The Verge)
