Wprowadzenie do problemu / definicja luki
Najnowsze ustalenia analityków blockchain wskazują, iż część długofalowych kradzieży kryptowalut wynika nie z bieżących kampanii malware czy phishingu, ale z konsekwencji wycieku danych z LastPass z 2022 r.: napastnicy pozyskali kopie zaszyfrowanych sejfów (vaultów) i w kolejnych miesiącach oraz latach stopniowo je „otwierali” (offline cracking), aby wydobyć przechowywane w nich sekrety – w skrajnych przypadkach także klucze prywatne i frazy seed portfeli krypto.
To ważna zmiana perspektywy: w takim modelu incydent nie „kończy się” w dniu naruszenia. jeżeli atakujący ma kopię vaulta, może wracać do niego wielokrotnie – aż trafi na słabsze hasło główne, niższe parametry KDF albo użytkownika, który nigdy nie zrotował sekretów.
W skrócie
- TRM Labs powiązało wieloetapowe drenaże portfeli (w falach) z wyciekiem zaszyfrowanych vaultów LastPass z 2022 r.; fundusze miały być prane m.in. przez rosyjski ekosystem wymiany/off-ramp.
- TRM podaje, iż prześledziło ponad 35 mln USD (28 mln w przepływach 2024–początek 2025 oraz 7 mln w fali z września 2025), zaznaczając, iż to prawdopodobnie zaniżony obraz.
- LastPass informował, iż w 2022 r. napastnik uzyskał dostęp do kopii zapasowych zawierających backupy wszystkich vaultów klientów, przy czym część pól metadanych (np. URL-e) mogła nie być szyfrowana tak jak reszta.
- W 2025 r. wątek „pękających vaultów” był wzmacniany również w materiałach organów ścigania (m.in. sekwestracje środków po dużych kradzieżach).
Kontekst / historia / powiązania
Łańcuch zdarzeń z 2022 r. (w uproszczeniu) wygląda tak:
- Incydent w środowisku developerskim – LastPass przekazał, iż atakujący uzyskał dostęp do części środowiska rozwojowego i wykradł fragmenty kodu oraz informacje techniczne.
- Drugi, powiązany incydent – według komunikatu z 22 grudnia 2022 r. napastnik wykorzystał informacje z pierwszego etapu, by dobrać się do środowiska przechowywania kopii zapasowych (cloud storage) i skopiować dane z backupów, w tym dane klientów oraz powiązane metadane.
- Efekt opóźniony w czasie – skoro w rękach atakującego znalazły się kopie vaultów, możliwy stał się scenariusz „powolnego otwierania sejfów”: brute force/łamanie offline na tych vaultach, które da się złamać (słabe hasło główne, brak rotacji, itp.), a potem drenaż kont w dogodnym momencie. Taki obraz opisują zarówno analitycy (TRM), jak i relacje dotyczące dochodzeń.
Analiza techniczna / szczegóły luki
1) Dlaczego „zaszyfrowany vault” przez cały czas bywa problemem
Szyfrowanie vaulta w modelu „zero-knowledge” oznacza, iż dostawca nie zna hasła głównego użytkownika i nie przechowuje go wprost. To jednak nie jest tarcza absolutna. jeżeli atakujący kradnie kopię vaulta, może uruchomić ataki offline – bez limitów logowania, bez MFA, bez alarmów typu „podejrzane logowanie”.
W praktyce odporność vaulta zależy od:
- siły i unikalności master password (długa fraza, brak reuse),
- parametrów funkcji wyprowadzania klucza (KDF) oraz tego, czy użytkownik nie miał słabszych ustawień,
- tego, czy użytkownik trzymał w vaultcie „sekrety o nieodwracalnych skutkach”, np. frazy seed/klucze prywatne (po ich przejęciu nie „resetujesz hasła” jak w e-mailu – tracisz środki).
2) Co faktycznie mogło zostać wyniesione
W aktualizacji LastPass z marca 2023 r. firma wskazywała, iż w kopiach zapasowych znajdowały się m.in. backupy wszystkich vaultów klientów, a zdecydowana większość wrażliwej zawartości vaulta była szyfrowana, z zastrzeżeniem wyjątków typu URL-e i niektóre ścieżki plików (oraz określone przypadki e-maili).
To istotne z operacyjnego punktu widzenia:
- metadane (np. URL) pomagają atakującemu typować „wysokowartościowe” cele (giełdy, usługi krypto, bankowość),
- a jeżeli w notatkach/sekretach znalazły się frazy seed czy klucze prywatne – skutki są natychmiastowo krytyczne.
3) Wzorce kradzieży i „demixing”
TRM opisuje, iż kradzieże następowały falami (nie „zaraz po wycieku”), co pasuje do hipotezy stopniowego łamania vaultów i późniejszego użycia kluczy.
Dodatkowo analitycy podkreślają, iż choćby przy próbach ukrywania przepływów przez CoinJoin (np. Wasabi Wallet), możliwe jest klastrowanie i analiza behawioralna („demixing”) w skali infrastruktury, co ułatwia łączenie kampanii w dłuższym horyzoncie.
Praktyczne konsekwencje / ryzyko
Dla użytkowników indywidualnych
- Ryzyko jest długoterminowe: choćby jeżeli od incydentu minęły lata, vault może zostać złamany „dziś”, jeżeli master password był słaby lub nigdy nie został zmieniony.
- Kryptowaluty są szczególnie narażone: przejęcie seed/private key często oznacza nieodwracalną utratę środków (brak centralnej instytucji, która „cofnie” transakcję).
- Brak typowych sygnałów włamania: w części spraw opisywanych w kontekście dochodzeń podkreślano brak oznak phishingu/malware na urządzeniach – bo atak mógł zacząć się od gotowego klucza z vaulta.
Dla firm (i zespołów security)
- Jeśli pracownicy przechowywali w managerze haseł elementy dot. portfeli firmowych (seed, klucze API giełd, recovery codes), incydent przeradza się w problem klasy „key compromise”, a nie tylko „hasło do serwisu”.
- Atakujący może wykonywać ciche przejęcia (bez interakcji z użytkownikiem): logowania do usług finansowych, wymiany kluczy API, wypłaty, zmiana danych odzyskiwania.
Rekomendacje operacyjne / co zrobić teraz
Poniżej podejście „minimalizuj skutki choćby po latach”, wprost pod scenariusz z wykradzionym vaultem.
1) jeżeli kiedykolwiek trzymałeś w vaultcie dane do portfeli krypto
- Załóż, iż seed/private key mógł zostać ujawniony i potraktuj to jak kompromitację klucza.
- Utwórz nowy portfel (najlepiej sprzętowy), wygeneruj nową frazę seed offline i przenieś środki (tam gdzie to możliwe) – a stary portfel uznaj za nieufny.
- Zmień/odwołaj klucze API giełd i usług krypto, jeżeli były zapisane w managerze haseł.
2) Wzmocnij „punkt centralny”: master password i konfigurację
- Ustaw długą passphrase (kilka losowych słów + unikalny element), bez reuse.
- Włącz i egzekwuj MFA dla kont powiązanych (e-mail, giełdy, bank), ale pamiętaj: MFA nie chroni przed offline crackingiem vaulta – chroni przed logowaniem do usługi.
- Zastosuj zalecenia dostawcy dotyczące zabezpieczenia konta po incydencie (LastPass publikował kroki i działania zalecane klientom).
3) Rotacja sekretów i „damage control”
- Rotuj hasła do usług najwyższego ryzyka: e-mail, giełdy, bankowość, konta chmurowe.
- Zmień pytania odzyskiwania / recovery e-mail / numery telefonu tam, gdzie mają znaczenie.
- Monitoruj transakcje i ustaw alerty (adresy, wypłaty, zmiany kluczy API).
4) Polityka bezpieczeństwa: czego NIE trzymać w password managerze
- Nie przechowuj frazy seed, kluczy prywatnych, plików keystore w narzędziach, które synchronizują się do chmury (chyba iż masz model ryzyka i dodatkowe warstwy, a i tak rozważ „dedykowane” rozwiązania do kluczy).
- W organizacjach: rozważ separację sekretów (password manager do haseł aplikacyjnych vs. HSM/secret manager do kluczy i tokenów o krytycznych skutkach).
Różnice / porównania z innymi przypadkami
„Wyciek vaultów” vs klasyczne przejęcie konta
- Klasycznie: phishing/malware → przejęcie sesji → szybka kradzież.
- Tutaj: kradzież zaszyfrowanej bazy → atak offline → drenaż po wielu miesiącach/latach, często bez śladów infekcji.
„Szyfrowanie” vs praktyka operacyjna
Szyfrowanie w password managerach jest fundamentem, ale realne bezpieczeństwo kończy się na najbardziej „ludzkich” elementach: sile master password, higienie rotacji i tym, czy użytkownicy nie używają vaulta jako „sejfu na wszystko” (łącznie z seedami).
CoinJoin/mixery vs analityka na poziomie kampanii
TRM podkreśla, iż choćby przy technikach prywatności (CoinJoin) długoterminowa spójność infrastruktury i ekosystemu „off-ramp” może zostawiać ślady pozwalające łączyć zdarzenia.
Podsumowanie / najważniejsze wnioski
- Incydent z 2022 r. przez cały czas „pracuje”, bo skradzione vaulty umożliwiają łamanie offline i selektywne, wieloletnie kradzieże.
- TRM wiąże fale drenaży z lat 2024–2025 z tym scenariuszem i opisuje śledzenie >35 mln USD oraz elementy wskazujące na rosyjski ekosystem prania/off-ramp.
- W praktyce obrony liczy się nie tylko „mam MFA”, ale rotacja sekretów i zasada: seed/private key to nie hasło – kompromitacja oznacza migrację do nowego klucza/portfela.
Źródła / bibliografia
- BleepingComputer – „Cryptocurrency theft attacks traced to 2022 LastPass breach” (02.01.2026). (BleepingComputer)
- TRM Labs – „TRM Traces Stolen Crypto from 2022 LastPass Breach…” (24.12.2025). (TRM Labs)
- LastPass – „Notice of Security Incident” (22.12.2022). (The LastPass Blog)
- LastPass – „Security Incident Update and Recommended Actions” (01.03.2023). (The LastPass Blog)
- KrebsOnSecurity – „Feds Link $150M Cyberheist to 2022 LastPass Hacks” (07.03.2025). (Krebs on Security)
