Archiwa: Malware - Strona 119 z 125 - Security Bez Tabu

Cyberprzestępcy handlują 183 mln skradzionych poświadczeń na Telegramie i podziemnych forach — co naprawdę się stało (i co z tym zrobić)

Wprowadzenie do problemu / definicja luki

Na przełomie października 2025 r. firma Synthient przekazała do Have I Been Pwned (HIBP) ogromny zbiór danych z ekosystemu infostealerów i podziemnych kanałów wymiany (m.in. Telegram, fora, social media). Po normalizacji i deduplikacji w HIBP pozostało 183 mln unikatowych adresów e-mail z odpowiadającymi im hasłami oraz domenami serwisów, w których były użyte. Co istotne, 16,4 mln adresów nie pojawiało się wcześniej w publicznych naruszeniach monitorowanych przez HIBP.

W skrócie

  • Skąd dane? Głównie logi infostealerów oraz listy do credential stuffing zbierane z Telegrama i forów.
  • Skala: 3,5 TB surowych plików, 23 mld wierszy; po deduplikacji 183 mln unikatowych adresów.
  • Nowość danych: ok. 9% (16,4 mln) adresów wcześniej nie widziano w HIBP.
  • Nie był to „wyciek Gmaila”: Google zdementowało doniesienia o rzekomym włamaniu do Gmaila; to agregat danych z wielu źródeł, głównie z infekcji malware.

Kontekst / historia / powiązania

Publikacje branżowe i wpisy twórcy HIBP, Troya Hunta, podkreślają, że ekosystem wycieków na Telegramie jest mocno recyklingowany: te same logi i combolisty są wielokrotnie przepakowywane i udostępniane. Dlatego każdy taki zbiór wymaga oczyszczenia i weryfikacji. Właśnie ten proces przeprowadził HIBP przed dodaniem rekordu „Synthient Stealer Log Threat Data”. Równolegle w mediach przetoczyła się fala błędnych nagłówków o „wielkim włamaniu do Gmaila”, czemu Google publicznie zaprzeczyło.

Analiza techniczna / szczegóły luki

Źródła danych. Zgodnie z opisem Synthient, ich system przez wiele miesięcy monitorował ~20 kontami Telegrama kanały powiązane z handlem logami, wykrywał linki-zaproszenia, pobierał archiwa, parsował różne, niespójne formaty i deduplikował z użyciem hashy plików oraz struktur w ClickHouse. Główne role w ekosystemie: primary sellers (sprzedawcy pierwotni), aggregators (wtórni kolekcjonerzy) i traffers (dystrybutorzy malware).

Weryfikacja i statystyki.

  • HIBP raportuje rekord „Synthient Stealer Log Threat Data” z opisem pól: adres e-mail, witryna (np. gmail.com, facebook.com) i użyte hasło. Po odrzuceniu duplikatów: 183 mln unikatowych adresów.
  • Hunt opisuje, że próbka pokazała ~91–92% adresów już znanych HIBP (recykling), a ~8–9% było nowych; po pełnym załadowaniu to 16,4 mln wcześniej nieobecnych w HIBP. Dodatkowo część zbioru stanowią listy do credential stuffing, nie tylko czyste logi infostealerów.

„To nie wyciek Gmaila”.
Google wyjaśniło, że mówimy o zebranej mieszance z wielu incydentów i infekcji, nie o świeżym ataku na jedną platformę. To nie podważa ryzyka dla użytkowników, ale zmienia interpretację: nie ma jednego „źródła włamania”, lecz wieloletni dryft poświadczeń po kanałach przestępczych.

Praktyczne konsekwencje / ryzyko

  • Przejęcia kont (ATO) przez credential stuffing i logowanie z przejętych sesji.
  • Spear-phishing i oszustwa oparte na znajomości serwisów, w których ofiara ma konta (domena z logu).
  • Lateral movement do środowisk firmowych, jeśli e-mail prywatny i służbowy współdzielą hasła.
  • Ujawnienie wzorców haseł, ułatwiające łamanie kolejnych skrótów.
  • Ryzyko reputacyjne i prawne (RODO) w razie wtórnego naruszenia w organizacji.

Warto założyć, że część haseł wciąż działa, zwłaszcza tam, gdzie MFA nie jest egzekwowane i użytkownicy recyklingują hasła.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i pracowników:

  1. Sprawdź adresy e-mail w HIBP (adres + „pwned sites” / „pastes”). W razie trafienia — natychmiastowa zmiana haseł i włączenie MFA (lub passkeys jako preferowany mechanizm).
  2. Unikalne hasło per serwis + menedżer haseł.
  3. Higiena urządzeń: aktualizacje, EDR/anty-malware, ostrożność wobec załączników i cracków — to infostealery są pierwotnym źródłem wycieku.

Dla zespołów bezpieczeństwa:

  1. Masowy reset haseł i/lub wymuszenie rotacji tam, gdzie brak MFA lub wykryto recykling.
  2. Egzekwuj MFA / passkeys dla poczty, VPN, SaaS i krytycznych aplikacji. Google i branża wskazują to jako najlepszą obronę przed kradzieżą poświadczeń.
  3. Blokada recyklingu haseł (zasady złożoności + sprawdzanie przeciw słownikom wycieków przy zmianie hasła).
  4. Detekcja ATO: reguły SIEM/UEBA na nietypowe logowania (nowe ASN, niestandardowe UA, nietypowa pora/geo), korelacja z listami adresów z HIBP.
  5. Unieważnij sesje po zmianie haseł; włącz powiadomienia o nowych logowaniach.
  6. Hunting na infostealery: IOC/IOA popularnych rodzin (Raccoon, RedLine, Vidar, Lumma itd.), kontrola egzekucji przeglądarek i kradzieży browser creds.
  7. Hardening przeglądarek (wyłączenie zapamiętywania haseł, izolacja profili), konteneryzacja przeglądania dla ról wysokiego ryzyka.
  8. Zarządzanie tożsamością: wdrożenie risk-based auth, FIDO2, ograniczenie dostępu uprzywilejowanego, just-in-time.

Różnice / porównania z innymi przypadkami

  • Combolisty vs. logi infostealerów: combolisty są zlepkiem starych wycieków (często bez kontekstu), podczas gdy logi infostealerów zawierają pary e-mail-hasło + domena, co podnosi skuteczność ATO. Zbiór Synthient zawiera obie kategorie, stąd duża objętość i konieczność deduplikacji.
  • „Jedno wielkie naruszenie” vs. „agregat wielu źródeł”: tutaj mamy agregat; brak pojedynczego punktu kompromitacji (np. „Gmail breach”).

Podsumowanie / kluczowe wnioski

  • Zbiór 183 mln unikatowych adresów z hasłami to realne ryzyko ATO na masową skalę, nawet jeśli większość wpisów to dane recyklingowane. 16,4 mln „nowych” adresów czyni ten przypadek wyjątkowo istotnym operacyjnie.
  • To nie jest wyciek jednego dostawcy poczty. To skutek lat infekcji infostealerami i wtórnego obiegu danych na Telegramie. Źródłem problemu są zainfekowane urządzenia i recykling haseł.
  • Priorytetem powinno być pełne egzekwowanie MFA/passkeys, polityka unikalnych haseł, monitoring ATO i hunting na infostealery w środowisku.

Źródła / bibliografia

  1. SecurityWeek — „Cybercriminals Trade 183 Million Stolen Credentials on Telegram, Dark Forums” (28 paź 2025). (SecurityWeek)
  2. Troy Hunt — „Inside the Synthient Threat Data” (22 paź 2025). (Troy Hunt)
  3. Have I Been Pwned — wpis „Synthient Stealer Log Threat Data”. (Have I Been Pwned)
  4. Synthient — „The Stealer Log Ecosystem: Processing Millions of Credentials a Day” (21 paź 2025). (Synthient)
  5. BleepingComputer — „Google disputes false claims of massive Gmail data breach” (27–28 paź 2025). (BleepingComputer)

Kradzież kont Discord z użyciem infostealera opartego na RedTiger — jak działa atak i jak się bronić

Wprowadzenie do problemu / definicja luki

Atakujący zaczęli nadużywać otwartoźródłowego narzędzia RedTiger do budowy infostealera kradnącego konta Discord oraz dane płatnicze powiązane z aplikacją. Złośliwe ładunki, kompilowane najczęściej w PyInstaller, zbierają również hasła i cookies z przeglądarek, informacje o portfelach kryptowalut oraz kontach gamingowych. Najnowsza fala celuje przede wszystkim w użytkowników we Francji, ale mechanizm ataku jest uniwersalny i łatwo przenaszalny na inne rynki.

W skrócie

  • Wejście: pliki wykonywalne podszywające się pod narzędzia do gier/Discord („mods”, „boosters”, „cheaty”). Kompilacja kodu RedTiger w PyInstaller.
  • Kradzież: tokeny Discord (w tym status MFA/Nitro), e-maile, dane płatnicze (karty, PayPal), hasła/karty zapisane w przeglądarkach, cookies, portfele krypto, konta gier.
  • Triki: iniekcja JS do pliku index.js Discorda w celu przechwytywania logowań, zmian hasła i transakcji; anty-analiza; masowe uruchamianie procesów i tworzenie plików dla utrudnienia analizy.
  • Eksfiltracja: archiwum z danymi wysyłane do GoFile, link przekazywany przestępcy przez Discord webhook.
  • Zasięg: początkowo Francja (użytkownicy Discord), ale brak barier językowych/techniczych do globalizacji kampanii.

Kontekst / historia / powiązania

RedTiger to pythonowe „multi-tool” do pentestów, OSINT i… budowania malware’u (m.in. stealer, Discord injection, a w wersji „premium” nawet ransomware builder). Choć repozytorium podkreśla „tylko do legalnych celów”, brak mechanizmów kontroli dystrybucji sprawia, że projekt jest łatwy do nadużycia przez aktorów zagrożeń. Zainteresowanie i dostępność potwierdzają setki forków i wydania utrzymywane w 2025 r.

Analiza techniczna / szczegóły luki

  1. Łańcuch infekcji
    Kampanie dystrybucji nie są jednolite; badacze wskazują na typowe wektory dla sceny gamingowej: serwery/DM na Discord, witryny z „modami”, fałszywe poradniki/filmiki, malvertising. Binarne „dropy” mają nazwy sugerujące powiązanie z grami/Discordem.
  2. Kradzież i walidacja tokenów Discord
    Stealer skanuje system pod kątem plików baz danych Discorda i przeglądarek, wydobywa tokeny (także szyfrowane) m.in. przez regexy, waliduje je i pobiera profil, e-mail, status MFA/Nitro oraz informacje o subskrypcji/płatnościach.
  3. Iniekcja do klienta Discord
    Złośliwy kod modyfikuje index.js klienta, aby hakować wywołania API i przechwytywać zdarzenia (logowanie, zakup, zmiana hasła, dodanie karty/PayPal). To umożliwia kradzież na żywo, nawet po rotacji części artefaktów.
  4. Zasięg kradzieży
    Poza Discordem RedTiger wykrada: hasła/cookies/historię/karty z przeglądarek, sesje portfeli krypto, pliki gier (Steam, Riot, Epic), pliki „interesujące” (.TXT, .SQL, .ZIP), a nawet zrzuty ekranu i ujęcia z kamery.
  5. Eksfiltracja i C2
    Zebrane artefakty są pakowane i uploadowane do GoFile; link jest zwracany atakującemu przez Discord webhook wraz z metadanymi ofiary.
  6. Anty-forensics / anty-analiza
    Wykryto m.in. kontrolę środowisk sandbox/debug oraz taktykę spamowania setkami procesów i plików, by utrudnić analizę i zaszumieć telemetrykę.

Praktyczne konsekwencje / ryzyko

  • Przejęcie kont Discord (utrata społeczności/serwera, oszustwa „na administratora”, wtórna dystrybucja malware’u).
  • Ryzyko finansowe: wyciek danych kart/PayPal zapisanych w Discordzie lub przeglądarce; zakupy Nitro/boosty na koszt ofiary.
  • Kompromitacja przeglądarki: przejęte cookies = sesje do SaaS/Gmail/GitHub; możliwość lateral movement.
  • Ekspozycja kluczy/seedów: enumeracja rozszerzeń/plików portfeli krypto.
  • Ryzyko reputacyjne i prawne (RODO) w razie wycieku danych z urządzeń firmowych.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkownika/Helpdesku (IR – pierwsze 24–48 h):

  1. Natychmiast zmień hasło do Discorda; to unieważnia tokeny. Następnie wyloguj wszystkie sesje i przeinstaluj klienta Discord (czysta instalacja z oficjalnej strony).
  2. Włącz/egzekwuj MFA na Discordzie oraz wszędzie, gdzie to możliwe.
  3. Na zainfekowanym hostcie: uruchom pełne skanowanie AV/EDR, usuń pliki z folderów Discorda, wyczyść LSA/DPAPI cache (jeśli dotyczy), zresetuj hasła do kont zapisanych w przeglądarce, usuń cookies i autouzupełnianie kart.
  4. Sprawdź transakcje karty/PayPal, rozważ zamrożenie karty.

Dla SecOps/IT:

  • App Control: blokuj wykonywalne PyInstaller i niepodpisane EXE z katalogów użytkownika; egzekwuj allow-listę aplikacji.
  • EDR: reguły na modyfikacje Discord\*\resources\app\*.js oraz nietypowe „child processes” klienta Discord.
  • Network egress: monitoruj/blokuj wycieki do GoFile i nietypowe wywołania Discord webhooks z hostów końcowych.
  • Browser hardening: zabroń przechowywania kart płatniczych; egzekwuj dojrzalszy menedżer haseł i polityki „no cookies reuse” dla systemów wrażliwych.
  • Uświadamianie użytkowników: kampanie przeciwko „modom/cheatom/boosterom” z nieznanych źródeł.
  • Hunting: IOC-y z bieżących raportów vendorów (np. Netskope Threat Labs), korelacja z logami proxy/EDR.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

W porównaniu do klasycznych infostealerów (np. Vidar, RedLine, Lumma), wariant bazujący na RedTiger wyróżnia:

  • nastawienie na Discord (tokeny + iniekcja JS do klienta, przechwytywanie zdarzeń zakupowych i zmian bezpieczeństwa),
  • builder” dostępny w repozytorium OSS, co obniża próg wejścia dla aktorów o niskich kompetencjach,
  • techniki anty-forensics (spam procesów/plików) nastawione na utrudnienie analizy po incydencie.

Podsumowanie / kluczowe wnioski

  • Otwartoźródłowe narzędzia red-teamowe, takie jak RedTiger, są coraz częściej weaponizowane w kampaniach masowych.
  • Discord pozostaje atrakcyjnym celem: token-stealing + JS-injection zapewniają atakującym długotrwały dostęp i możliwość monetyzacji.
  • Obrona wymaga połączenia higieny użytkownika (MFA, brak „cheatów”) z kontrolą aplikacji, telemetrią EDR i huntingiem pod konkretne artefakty (modyfikacje index.js, uploady do GoFile, webhooks).

Źródła / bibliografia

  1. BleepingComputer — „Hackers steal Discord accounts with RedTiger-based infostealer”, 26 października 2025. (BleepingComputer)
  2. Netskope Threat Labs — „RedTiger in the Wild: Targeting Gamers & Discord Accounts” (analiza kampanii, TTP, zasięg geograficzny). (Netskope)
  3. GitHub — RedTiger-Tools (funkcje: stealer, Discord injection, malware builder; aktywność repo 2025). (GitHub)

ONZ przyjmuje „Hanoi Convention”: globalny traktat przeciw cyberprzestępczości otwarty do podpisu. Co to oznacza dla SOC-ów i compliance?

Wprowadzenie do problemu / definicja luki

25 października 2025 r. ONZ otworzyła w Hanoi do podpisu pierwszy globalny traktat przeciw cyberprzestępczości („UN Convention against Cybercrime”, nieformalnie: Hanoi Convention). Wydarzenie zgromadziło delegacje dziesiątek państw i ma usprawnić współpracę międzynarodową w sprawach takich jak phishing, ransomware, handel ludźmi online czy mowa nienawiści. Już podczas ceremonii podpisania dokument zyskał szerokie poparcie – choć towarzyszą mu poważne zastrzeżenia dotyczące praw człowieka i wolności badań bezpieczeństwa.

W skrócie

  • Status: traktat otwarty do podpisu 25 października 2025 r. w Hanoi; 65 państw podpisało w pierwszym dniu. Wejście w życie: po złożeniu 40 dokumentów ratyfikacyjnych. Okno podpisów pozostaje otwarte do 31 grudnia 2026 r.
  • Cel: ujednolicenie przestępstw, procedur dowodowych i kanałów współpracy transgranicznej w sprawach cyber.
  • Kto podpisuje: m.in. UE oraz państwa członkowskie (zgoda na podpis wyrażona wcześniej przez Radę UE).
  • Kontrowersje: branżowe porozumienie Cybersecurity Tech Accord (m.in. Microsoft, Meta) i organizacje praw człowieka ostrzegają przed ryzykiem nadużyć („traktat nadzoru”) i penalizacją etycznych badań.

Kontekst / historia / powiązania

Negocjacje konwencji prowadziło UNODC po latach dyskusji nad potrzebą globalnych, a nie tylko regionalnych (np. europejskich), ram walki z cyberprzestępczością. Sekretarz Generalny ONZ podkreślił koszt cyberprzestępczości liczony w „bilionach dolarów rocznie” i konieczność ułatwienia współpracy między organami ścigania.
Strona konwencji prowadzona przez UNODC potwierdza harmonogram: podpis w Hanoi, a następnie możliwość podpisywania w siedzibie ONZ w Nowym Jorku, z wejściem w życie 90 dni po 40. ratyfikacji.

Analiza techniczna / szczegóły traktatu

Choć pełny tekst jest obszerny, trzon instrumentu obejmuje trzy bloki, które mają największe znaczenie dla praktyków cyberbezpieczeństwa i zespołów prawnych:

  1. Katalog przestępstw – od oszustw (phishing), przez ataki z użyciem malware/ransomware, po przestępstwa związane z treścią (np. mowa nienawiści) definiowane według standardów ONZ. To rozszerzenie tradycyjnych ujęć „komputerowych” czynów zabronionych o kategorie, które w wielu jurysdykcjach są nadal rozproszone.
  2. Procedury dowodowe i e-dowody – zharmonizowane zasady zabezpieczania, utrwalania i udostępniania danych elektronicznych (logi, metadane, treści), ułatwiające szybką i zgodną z prawem wymianę materiału dowodowego między państwami. UNODC wskazuje, że konwencja ma promować „legalne badania” i zawiera klauzule ochrony praw człowieka.
  3. Współpraca transgraniczna – kanały pomocy prawnej, tryb „nagłych wniosków” i punkty kontaktowe 24/7, aby skrócić czas reakcji w incydentach transgranicznych. UE potwierdziła zamiar podpisu i wdrażania zgodnie z własnymi standardami praw człowieka.

Praktyczne konsekwencje / ryzyko

Dla firm (CISO, SOC, DPO):

  • Więcej wezwań międzynarodowych o dane: krótsze terminy na „preservation” i przekazanie logów/treści organom zagranicznym – zwłaszcza dla usług chmurowych i platform o zasięgu globalnym.
  • Zwiększona interoperacyjność procedur dowodowych – potencjalnie mniej „tarć” prawnych przy przekazywaniu e-dowodów do państw sygnatariuszy.
  • Ryzyka praw człowieka i R&D – Tech Accord ostrzega, że nieprecyzyjne definicje mogą ułatwić nadmierny nadzór i kryminalizować testy penetracyjne/bezpieczeństwa prowadzone w dobrej wierze, jeśli lokalne prawo implementujące będzie restrykcyjne. Potrzebne będą wyraźne wyjątki i bezpieczne przystanie dla badaczy (np. coordinated vulnerability disclosure).

Dla organów ścigania i CERT/CSIRT:

  • Szybszy dostęp do danych transgranicznych i łatwiejsze wspólne operacje w sprawach ransomware czy oszustw finansowych.

Rekomendacje operacyjne / co zrobić teraz

  1. Mapa jurysdykcyjna & readiness: zidentyfikuj, które kraje kluczowe dla Twojej działalności podpisały konwencję i śledź proces ratyfikacji (próg 40). Zaktualizuj playbooki SOC/LERT o tryby współpracy transgranicznej.
  2. Retencja i łańcuch dowodowy: ustandaryzuj politykę data preservation (czas, zakres, integralność), aby spełnić oczekiwania nowych kanałów pomocy prawnej.
  3. Legal & privacy by design: oceniaj wnioski o dane pod kątem zgodności z lokalnym prawem, RODO oraz klauzulami praw człowieka przewidzianymi przez konwencję; dokumentuj podstawy prawne i proporcjonalność.
  4. Program CVD/bug bounty: wprowadź/wyraźnie opisz zasady coordinated vulnerability disclosure i zakres „dozwolonych testów” (safe harbor) – to ogranicza ryzyko penalizacji etycznych badań w krajach o ostrzejszej implementacji. (Obawy branży: Cybersecurity Tech Accord).
  5. Ćwiczenia purple team: przetestuj scenariusze żądań danych z państw trzecich (różne formaty, SLA, szyfrowanie end-to-end), uwzględniając eskalacje do DPO/Legal.

Różnice / porównania z innymi przypadkami

Konwencja ONZ ma ambicję globalnego zasięgu i wspólnych, minimalnych standardów. W porównaniu z dotychczasową mozaiką porozumień i instrumentów regionalnych, stawia mocny akcent na ułatwienie dostępu do e-dowodów i mechanizmy 24/7. Jednocześnie zakres kategorii przestępstw i możliwe ingerencje w prywatność są szersze niż w wielu dotychczasowych reżimach – stąd krytyka NGO i sektora technologicznego, by implementacje krajowe nie prowadziły do nadużyć.

Podsumowanie / kluczowe wnioski

  • To się dzieje teraz: 25 października 2025 r. w Hanoi ruszył proces podpisywania; 65 podpisów na starcie podnosi szansę na szybkie przekroczenie progu 40 ratyfikacji.
  • Dla biznesu: przygotuj się na więcej i szybsze żądania o dane z zagranicy oraz audyty łańcucha dowodowego.
  • Dla bezpieczeństwa i prywatności: zadbaj o jasne wyjątki dla badań i procesy oceny proporcjonalności – inaczej istnieje ryzyko „efektu mrożącego” dla społeczności security.

Źródła / bibliografia

  • Reuters: „UN cybercrime treaty to be signed in Hanoi to tackle global offences” (25 października 2025). (Reuters)
  • UNODC (press): „UN Convention against Cybercrime opens for signature in Hanoi, Viet Nam” (25 października 2025). (UNODC)
  • UNODC (status): „United Nations Convention against Cybercrime — status & entry into force”. (UNODC)
  • Rada UE: „Fighting cybercrime: EU to sign UN Convention on cybercrime” (13 października 2025). (Consilium)
  • Cybersecurity Tech Accord: „Calls for changes to new UN treaty…” (29 lipca 2024) – stanowisko branży. (Cybersecurity Tech Accord)

Fałszywe „wnioski pośmiertne” w LastPass: kampania CryptoChameleon wyłudza hasła główne i celuje także w passkeys

Wprowadzenie do problemu / definicja luki

LastPass ostrzega przed trwającą od połowy października kampanią socjotechniczną podszywającą się pod mechanizm „dziedziczenia” (legacy/emergency access). Ofiary dostają e-maile sugerujące, że członek rodziny wnioskował o dostęp do sejfu po rzekłej śmierci właściciela, a w treści znajduje się „link do anulowania wniosku”. Kliknięcie prowadzi na fałszywą stronę „lastpassrecovery[.]com”, gdzie napastnicy wyłudzają hasło główne; w części przypadków atak jest wzmacniany telefonem od „pracownika LastPass” (tzw. hybrid phishing/call-back). Źródła i artefakty przypisują kampanię do grupy CryptoChameleon (UNC5356), wcześniej znanej z wyłudzeń na użytkownikach giełd krypto oraz z klonów stron logowania Okta/Gmail/iCloud/Outlook.

W skrócie

  • TTPs: e-mail z tematem “Legacy Request Opened (URGENT IF YOU ARE NOT DECEASED)” → call-to-action „Cancel request” → phishing na lastpassrecovery[.]com → kradzież hasła głównego; dodatkowo fałszywe telefony kierujące ofiarę na stronę phishingową; domeny pod passkeys (np. mypasskey[.]info, passkeysetup[.]com).
  • Atrybucja: infrastruktura i domeny powiązane z CryptoChameleon/UNC5356 (powiązania z kampaniami krypto-phishing).
  • Skala/zasięg: kampania aktywna od połowy października 2025 r.; część infrastruktury wygaszona, ale pojawiają się kolejne klony.
  • Ryzyko: kompromitacja sejfu haseł i/lub kradzież środków krypto, przejęcia kont, eskalacja na środowiska firmowe (SSO, poczta, CI/CD). Kontekst historyczny podnosi wagę ataku.

Kontekst / historia / powiązania

W 2022 r. LastPass ujawnił kradzież zaszyfrowanych kopii sejfów oraz danych niezaszyfrowanych (m.in. URL-e), co w kolejnych miesiącach korelowało z seriami kradzieży krypto u wybranych ofiar. W 2025 r. amerykańskie organy ścigania w dokumentach sądowych łączyły część dużych kradzieży (ok. 150 mln USD) z kompromitacjami związanymi z LastPass z 2022 r.

Dodatkowo 15 października 2025 r. raportowano inną kampanię phishingową celującą w użytkowników LastPass i Bitwarden, która wmawiała „włamanie” i skłaniała do instalacji „bezpieczniejszej wersji desktopowej” — w praktyce prowadziła do przejęcia stacji roboczej. To pokazuje ciągłe zainteresowanie ekosystemem managerów haseł przez cyberprzestępców.

Analiza techniczna / szczegóły luki

Wektor socjotechniczny:

  • Narracja „pośmiertna”: e-mail informuje o uruchomieniu procedury dziedziczenia (upload „aktu zgonu”) i zawiera fikcyjny numer agenta/case ID oraz priorytet sprawy — elementy, które podnoszą wiarygodność i presję czasu.
  • Phishing URL: przycisk „Cancel request” kieruje do lastpassrecovery[.]com (wskaźniki z przypisaniem do CryptoChameleon; hostowanie m.in. w NICENIC). Lista IOCs obejmuje także dziesiątki domen podszywających się pod Coinbase/Binance/Gemini/Gmail.
  • Call-back (voice social engineering): napastnicy dzwonią jako „LastPass Support” i nakłaniają do wpisania hasła głównego na stronie phishingowej.
  • Celowanie w passkeys: obecność wielu wariantów domen typu mypasskey[.]info i passkeysetup[.]com wskazuje na rozszerzenie ataku na FIDO2/WebAuthn (kradzież/eskalacja tokenów i sekwencji rejestracji).

Mechanizm „dziedziczenia” w LastPass (legalny): właściciel sejfu może zdefiniować kontakt awaryjny; po żądaniu dostępu biegnie okres karencji, po którym dostęp jest nadawany automatycznie, jeśli właściciel nie zareaguje. Atak nawiązuje do tej logiki, by zmuszać ofiarę do „anulowania” i wejścia w lewą stronę.

Praktyczne konsekwencje / ryzyko

  • Użytkownicy indywidualni: ujawnienie hasła głównego = pełne przejęcie sejfu, pivot na mail/SSO/krypto; przy przechowywaniu seedów do portfeli – natychmiastowa kradzież środków. Kontekst z 2022–2025 r. pokazuje, że to nie są ataki hipotetyczne.
  • Firmy: ryzyko kompromitacji kont uprzywilejowanych, łańcuchowe przejęcia usług (MFA reset, IdP, repozytoria), BEC i naruszenia danych.
  • Zespół helpdesku: podatność na „voice phishing” i eskalacje na wewnętrzne procesy wsparcia (np. błędna weryfikacja tożsamości).

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników (natychmiast):

  1. Nigdy nie wpisuj hasła głównego po kliknięciu w link z e-maila/telefonu. Wchodź wyłącznie przez oficjalną aplikację lub ręcznie wpisany lastpass.com.
  2. Sprawdź w skrzynce temat: Legacy Request Opened (URGENT IF YOU ARE NOT DECEASED). Jeśli go masz — prześlij jako załącznik na abuse@lastpass.com.
  3. Włącz MFA dla LastPass i wszystkich krytycznych kont; rozważ zmianę hasła głównego i rotację haseł do kont wysokiej wartości (banki, krypto, e-mail).
  4. Jeśli używasz passkeys – upewnij się, że nie rejestrowałeś ich poprzez żaden link z e-maila; odrzuć nieoczekiwane prośby o rejestrację/uwierzytelnienie.

Dla SecOps/IT (w organizacji):

  1. Blokuj/monitoruj IOCs z bieżącej kampanii (domena lastpassrecovery[.]com, warianty mypasskey[.]info, podszycia pod giełdy i Gmail) w DNS/web proxy/EDR. Wdróż detekcje „Legacy Request” w treściach maili.
  2. Playbook SOAR: runbook na hybrydowy phishing + call-back (weryfikacja telefoniczna tylko poprzez oddzwonienie na oficjalne numery; żaden pracownik LastPass nie poprosi o hasło główne).
  3. Awareness: mikro-kampania dla pracowników (60-sek. wideo/komunikat) nt. „fałszywego dziedziczenia” i zasad bezpiecznej rejestracji passkeys.
  4. Zarządzanie tajemnicami: rozdziel sejfy prywatne/służbowe, segmentuj tajemnice; wymuś MFA hardware (FIDO2) tam, gdzie możliwe; rozważ detekcje anomalii w menedżerach haseł (próby odzyskiwania, masa-eksport haseł).
  5. Incident response: jeżeli podejrzewasz wpisanie hasła na phishingu – wymuś natychmiastową rotację i sprawdź eksport historii sejfu, logi logowań i ewentualne exfiltration events.

Różnice / porównania z innymi przypadkami

  • Październik 2025 (ten case): nacisk na dziedziczenie + call-back i targetowanie passkeys (nowość względem klasycznego phishingu na hasło główne).
  • 15 października 2025: osobna kampania „fałszywych alertów o włamaniu” wymuszająca instalację „bezpieczniejszej aplikacji” (wektor malware/PC hijack zamiast credential harvesting).
  • Kontekst 2022–2025: długofalowe skutki wycieku sejfów (brute-force offline na słabych hasłach, kradzieże krypto) – obecna kampania wykorzystuje te narracje i dane do skuteczniejszej socjotechniki.

Podsumowanie / kluczowe wnioski

  • To nie jest bug w LastPass, lecz wyrafinowana socjotechnika wykorzystująca realny proces „emergency access”.
  • Kampania CryptoChameleon łączy phishing mailowy, voice phishing i nowe cele (passkeys), co zwiększa skuteczność.
  • Organizacje powinny natychmiast wprowadzić bloki IOC, szkolenia „micro-awareness” i runbooki na call-back phishing; użytkownicy — MFA wszędzie, zerowa tolerancja na linki z e-maili i zgłaszanie podejrzanych wiadomości na abuse@lastpass.com.

Źródła / bibliografia

  • BleepingComputer: „Fake LastPass death claims used to breach password vaults”, 24.10.2025. (BleepingComputer)
  • LastPass (oficjalny blog): „Possible CryptoChameleon Social Engineering Campaign…”, 23.10.2025. (The LastPass Blog)
  • BleepingComputer: „Fake LastPass, Bitwarden breach alerts lead to PC hijacks”, 15.10.2025. (BleepingComputer)
  • KrebsOnSecurity: „Feds Link $150M Cyberheist to 2022 LastPass Hacks”, 07.03.2025. (Krebs on Security)
  • LastPass (komunikat): „Notice of Recent Security Incident”, 22.12.2022. (The LastPass Blog)

3 000 filmów na YouTube jako pułapki malware. „YouTube Ghost Network” rozbite — co to było i jak się bronić

Wprowadzenie do problemu / definicja luki

Check Point Research ujawnił skoordynowaną operację dystrybucji złośliwego oprogramowania na YouTube, nazwaną YouTube Ghost Network. Sieć wykorzystywała przejęte lub fałszywe konta, by publikować filmy-tutoriale (cracki, „haki” do gier), które prowadziły do pobrania stealerów informacji. Zidentyfikowano ponad 3 000 złośliwych filmów, z których wiele miało setki tysięcy wyświetleń. Po zgłoszeniach badaczy Google usunął większość treści. Źródło przypisuje aktywność co najmniej od 2021 r., a w 2025 r. liczba filmów potroiła się.


W skrócie

  • Skala: >3 000 filmów na przejętych kanałach; rekordowe pojedyncze wideo ~293 tys. wyświetleń (Photoshop), inne ~147 tys. (FL Studio).
  • Wektor socjotechniczny: „darmowe” cracki i cheaty (m.in. Roblox, Adobe, FL Studio), komentarze i lajki budujące fałszywą wiarygodność.
  • Rodziny malware: głównie infostealery – Lumma (przed jej wiosennym rozbiciem), później Rhadamanthys, a także RedLine, StealC, Phemedrone/0debug; bywał łańcuch z HijackLoaderem.
  • Łańcuch infekcji: linki w opisie, przypiętych komentarzach lub „instrukcji wideo” → skracacze URL → Google Sites/Blogger/Telegra.ph lub dyski Dropbox/Google Drive/MediaFirearchiwum z hasłem + prośba o wyłączenie Defendera → payload.
  • Reakcja branży: Check Point + Google usunęli większość treści; media branżowe potwierdziły skalę i modus operandi.

Kontekst / historia / powiązania

  • Lumma Stealer był „hitem” w sieci do czasu międzynarodowej akcji Microsoftu i Europolu (16 marca–16 maja 2025 r.), po której operatorzy kampanii częściej przechodzili na Rhadamanthys.
  • Zjawisko „Ghost Network” wcześniej opisywano na GitHubie (kampania Stargazers Ghost Network), gdzie masowo podszywano się pod wiarygodne repozytoria do dystrybucji złośliwych plików. YouTube to kolejna odsłona tej samej taktyki „platform-as-distribution”.

Analiza techniczna / szczegóły luki

Architektura ról (operacja na YouTube):

  1. Video-accounts – publikują filmy-wabiki i udostępniają linki (w opisie, przypiętym komentarzu lub jako „hasło+link” w samym wideo).
  2. Post-accounts – publikują posty społeczności z linkami i hasłami do archiwów; aktualizują wpisy, by omijać zgłoszenia; możliwe użycie AI do interakcji.
  3. Interact-accounts – dodają „lajki” i entuzjastyczne komentarze („works!”, „no virus”), podbijając sygnały zaufania.

Łańcuch dystrybucji i unikanie detekcji:

  • Skracacze URL maskujące destynację.
  • Hosty plików i usługi Google (Sites/Blogspot/Drive) – wysoka reputacja domen utrudnia filtrowanie reputacyjne.
  • Archiwa chronione hasłem (często „1337”) – brak możliwości skanowania zawartości bez hasła.
  • Instrukcje „wyłącz Defendera na chwilę” – celowe osłabienie ochrony podczas instalacji.
  • Pliki o dużych rozmiarach lub MSI instalujące HijackLoadera, który dociąga właściwy stealer (np. Rhadamanthys).

Cele i treści przynęt:

  • Cracki do Adobe Photoshop/Premiere/Lightroom, FL Studio, CorelDRAW, cheaty do gier (np. Roblox).
  • Kierowanie do grup docelowych (twórcy wideo/muzyki, gracze), gdzie popyt na „darmowe” narzędzia jest wysoki.

Praktyczne konsekwencje / ryzyko

  • Utrata danych uwierzytelniających (przeglądarki, menedżery haseł, cookie session tokens), portfele kryptowalut, poczta i konta społecznościowe — typowe dla stealerów.
  • Przejęcia kont korporacyjnych przez wykradzione sesje (SSO, M365, Slack, Git).
  • Wektory wtórne: zainfekowane endpointy stają się punktem wyjścia do BEC, ransomware lub dalszych kradzieży danych. (Wynika z typowych zdolności Lumma/Rhadamanthys i obserwacji Check Point dot. infostealerów w kampanii).

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/IT (organizacje)

  1. Zablokuj ryzykowne kategorie transferów: egzekwuj polityki dla popularnych skracaczy URL i hostingów plików (Dropbox/Drive/MediaFire) w ruchu korporacyjnym — co najmniej kontrola i logowanie + izolacja przeglądarkowa dla niezweryfikowanych pobrań.
  2. Reguły detekcji:
    • Alerty na pobrania archiwów z hasłem z przeglądarki i nietypowe uruchomienia msiexec/exe po pobraniu.
    • Telemetria EDR dla wskaźników typowych dla Rhadamanthys/Lumma (procesy z nietypową komunikacją C2, kradzież danych z przeglądarek). (Uzasadnienie: kampania dostarczała właśnie te stealer-y).
  3. Zasady anty-tampering: wymuś niemożność wyłączenia Defendera/AV przez użytkownika bez uprawnień admina; monitoruj zdarzenia prób wyłączenia ochrony w czasie instalacji.
  4. Twarde uwierzytelnianie: MFA odporne na phishing (FIDO2/Passkeys), krótkie TTL sesji, automatyczne unieważnianie tokenów po incydencie ze stealerem. (Kontekst: masowe kradzieże cookies przez stealery).
  5. Kontrola aplikacji i uprawnień: blokada uruchamiania niepodpisanych MSI/EXE spoza zaufanych katalogów; WDAC/AppLocker; zasada least privilege na endpointach.
  6. DTR/IR playbook dla stealerów: natychmiastowa rotacja haseł/kluczy/API, reset sesji, przegląd logowania z nowych lokacji, przegląd skrzynek i reguł przekierowań.

Dla użytkowników (awareness)

  • Nie instaluj cracków i „hacków do gier” — to w 2025 r. najczęstsza przynęta w tej kampanii.
  • Weryfikuj kanały i linki: jeśli link prowadzi przez skracacz lub na Google Sites/Telegra.ph i wymaga hasła do archiwum – traktuj to jako czerwone flagi.
  • Nie wyłączaj antywirusa „na chwilę” z powodu filmu w sieci.
  • Używaj menedżera haseł + MFA i aktualizuj system.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • GitHub „Stargazers Ghost Network” (2024–2025) i YouTube Ghost Network (2025) to ta sama logika „Ghost accounts as a service” na różnych platformach: manipulacja sygnałami zaufania (gwiazdki/forciowanie repo vs. wyświetlenia/komentarze), treści przynęt (narzędzia/dev-tool vs. cracki/cheaty), lecz cel identyczny — masowa dystrybucja infostealerów przy użyciu „dobrych” domen i funkcji społecznościowych.

Podsumowanie / kluczowe wnioski

  • Kampania YouTube Ghost Network pokazała, jak łatwo zbrodnicze grupy weaponizują platformy społecznościowe — od SEO i komentarzy po posty społeczności — by sprzedawać wiarygodność i dostarczać malware na masową skalę.
  • Cracki i cheaty pozostają najbardziej ryzykownym typem treści dla użytkowników; to na nich żerują operatorzy stealerów.
  • Higiena tożsamości, polityki pobrań i kontrola aplikacji są dziś równie ważne, co sygnaturowe AV.
  • Po rozbiciu Lumma napastnicy przechodzą na alternatywy (Rhadamanthys), co wymaga ciągłej adaptacji detekcji.

Źródła / bibliografia

  • Check Point Research: Dissecting YouTube’s Malware Distribution Network (23 października 2025). (Check Point Research)
  • The Hacker News: 3,000 YouTube Videos Exposed as Malware Traps… (24 października 2025). (The Hacker News)
  • The Register: Google and Check Point nuke massive YouTube malware… (23 października 2025). (The Register)
  • Help Net Security: Researchers expose large-scale YouTube malware distribution network (23 października 2025). (Help Net Security)
  • Europol: Europol and Microsoft disrupt world’s largest infostealer Lumma (21 maja 2025). (Europol)

GlassWorm: samorozprzestrzeniający się robak infekuje rozszerzenia VS Code i uderza w łańcuch dostaw

Wprowadzenie do problemu / definicja luki

Badacze bezpieczeństwa opisali nową kampanię malware nazwaną GlassWorm, która samodzielnie rozprzestrzenia się poprzez zainfekowane rozszerzenia Visual Studio Code publikowane w rejestrach Open VSX i Microsoft VS Code Marketplace. Atak celuje w łańcuch dostaw oprogramowania – wprost w narzędzia deweloperskie – kradnie poświadczenia (npm, GitHub), przejmuje środowiska i wykorzystuje maszyny programistów jako infrastrukturę przestępczą.


W skrócie

  • Skala: ok. 35,8 tys. instalacji złośliwych rozszerzeń; co najmniej kilka–kilkanaście paczek w obiegu w OpenVSX i na rynku Microsoftu.
  • Techniki ukrywania: „niewidzialny kod” z użyciem niewidocznych znaków Unicode w źródłach rozszerzeń, utrudniający przegląd i detekcję.
  • Zdolności: kradzież tokenów npm/GitHub, celowanie w 49 wtyczek portfeli krypto, uruchamianie SOCKS proxy i ukrytego VNC/RAT dla pełnego zdalnego dostępu.
  • Propagacja: użycie wykradzionych poświadczeń do publikowania zainfekowanych aktualizacji i przejmowania kolejnych kont/paczek.

Kontekst / historia / powiązania

Pierwsze publiczne raporty pojawiły się 20–24 października 2025 r.. Media branżowe i dostawcy bezpieczeństwa (m.in. BleepingComputer, Dark Reading) potwierdzają, że to jedna z najpoważniejszych jak dotąd kampanii wymierzonych w ekosystem VS Code. Część źródeł wiąże odkrycie z pracą badaczy Koi Security, a rozszerzenia w OpenVSX miały zostać podmienione 17 października; 2 dni później część z nich nadal rozprowadzała malware.


Analiza techniczna / szczegóły luki

Vektor wejścia. GlassWorm trafia do środowisk poprzez instalację (lub aktualizację) zainfekowanych rozszerzeń VS Code z OpenVSX oraz Microsoft Marketplace. Atakujący przejmują konta wydawców lub łańcuch CI/CD i publikują skażone wersje.

„Niewidzialny” kod. Krytycznym elementem jest ukrywanie złośliwej logiki z użyciem znaków sterujących Unicode (np. kierunków zapisu/bidirectional control), które sprawiają, że fragmenty kodu nie są widoczne przy zwykłym przeglądzie i mogą mylić zarówno recenzentów, jak i niektóre narzędzia SAST. Efekt: czysty diff, pozornie prawidłowa składnia, złośliwe ścieżki wykonania zaszyte między literami.

Zdolności po infekcji. Po zainstalowaniu, GlassWorm:

  • eksfiltruje poświadczenia npm i GitHub oraz inne sekrety deweloperskie,
  • skanuje przeglądarkę/środowisko pod kątem 49 rozszerzeń portfeli krypto i próbuje drenować środki,
  • wdraża SOCKS proxy, aby wykorzystywać hosta jako przekaźnik,
  • instaluje ukryte VNC/RAT dla pełnego zdalnego dostępu, utrzymując się w systemie,
  • używa skradzionych tokenów do przejęcia kolejnych pakietów/rozszerzeń i samoreplikacji.

Skala i telemetry. Według niezależnych relacji prasowych i firm badawczych mówimy o ~35,8 tys. instalacji/udanych pobrań skażonych rozszerzeń; atak dotknął co najmniej kilka–kilkanaście pakietów w popularnych rejestrach rozszerzeń.


Praktyczne konsekwencje / ryzyko

  • Kompromitacja łańcucha dostaw: przejęte tokeny npm/GitHub = ryzyko publikacji trojanów w repozytoriach firmy/OSS.
  • Ryzyko finansowe: celowanie w portfele krypto i możliwa utrata środków.
  • Infrastruktura przestępcza: hosty dev stają się proxy i zdalnymi stacjami sterowanymi przez atakujących (VNC/RAT) – ekspozycja sieci wewnętrznej.
  • „Blind spot” w code review: użycie niewidzialnych znaków obchodzi kontrolę peer review i statyczną analizę, co utrudnia tradycyjne procesy SDLC.

Rekomendacje operacyjne / co zrobić teraz

Natychmiast (IR – Incident Response):

  1. Inwentaryzacja rozszerzeń VS Code w organizacji (OpenVSX/Microsoft Marketplace). Wytypować i odinstalować podejrzane/ostatnio aktualizowane.
  2. Rotacja i unieważnienie wszystkich tokenów npm/GitHub/PAT, kluczy CI/CD, cookies sesyjnych przeglądarki; włączyć 2FA i ograniczyć zakres uprawnień (fine-grained PAT).
  3. Izolacja stacji roboczych dev: odłączenie od sieci, skan EDR/AV, detekcja SOCKS proxy i ukrytych usług VNC/RAT; przegląd autostartów i harmonogramów zadań.
  4. Przegląd repozytoriów i rejestrów: niezwłoczne sprawdzenie ostatnich publikacji/commitów/wersji paczek pod kątem nietypowych zmian i „niewidzialnego” Unicode.

W kolejnych dniach (hardening):

  • Wymuś weryfikację wydawcy i pinning zaufanych rozszerzeń; ogranicz instalację do listy dozwolonych (allow-list). (Praktyka zalecana przez branżę w kontekście tego incydentu).
  • W pipeline’ach dodaj kontrole Unicode (detekcja znaków sterujących Bidi, zero-width, itd.) i policy skanów dla rozszerzeń/artefaktów przed dopuszczeniem do stacji dev.
  • Egzekwuj zasadę najmniejszych uprawnień dla tokenów (scopes, TTL, rotacja), ochronę sekretów i monitoring publikacji (alerty przy zmianie maintainerów lub kluczy publikacyjnych).
  • Użyj EDR z regułami na nietypowe połączenia proxy/VNC i anomalie narzędzi deweloperskich; przegląd ruchu wychodzącego pod kątem tuneli SOCKS.

Artefakty/detekcja (przykłady do playbooka IR):

  • Skan plików źródłowych pod kątem znaków: \u202E, \u2066\u2069, \u200B itd. (Bidi/zero-width).
  • Audyt folderów rozszerzeń ~/.vscode/extensions / %USERPROFILE%\.vscode\extensions pod kątem niepodpisanych/nieznanych vendorów i recent-modified. (Dobre praktyki zgodne z doniesieniami o wektorze).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

W porównaniu z wcześniejszymi incydentami „tylko” trojanizującymi pojedyncze rozszerzenie, GlassWorm łączy samopropagację (wykorzystanie świeżo wykradzionych tokenów do publikacji kolejnych zainfekowanych aktualizacji) z niewidzialnym kodem Unicode, co utrudnia review i automatyczną analizę. To jakościowy skok względem znanych kampanii typosquattingu i przejęć paczek NPM/VS Code.


Podsumowanie / kluczowe wnioski

  • GlassWorm uderza w samo serce SDLC – narzędzia deweloperskie – i omija klasyczne bramki kontrolne dzięki „niewidzialnym” trikom Unicode.
  • Organizacje powinny traktować sprawę jak incydent bezpieczeństwa łańcucha dostaw: natychmiastowa rotacja sekretów, czyszczenie stacji dev, whitelisting rozszerzeń i kontrole Unicode w pipeline’ach.
  • Nawet po usunięciu skażonych wtyczek, skradzione tokeny mogą umożliwiać dalsze nadużycia – higiena kluczy i monitoring publikacji są krytyczne.

Źródła / bibliografia

  • The Hacker News – „Self-Spreading ‘GlassWorm’ Infects VS Code Extensions…” (24 października 2025). (The Hacker News)
  • BleepingComputer – „Self-spreading GlassWorm malware hits OpenVSX, VS Code registries” (20 października 2025). (BleepingComputer)
  • Dark Reading – „Self-Propagating GlassWorm Attacks VS Code Supply Chain” (20 października 2025). (Dark Reading)
  • Truesec – „GlassWorm – Self-Propagating VSCode Extension Worm” (analiza techniczna, październik 2025). (Truesec)
  • Koi Security (blog) – przegląd zdolności GlassWorm i TTP (październik 2025). (koi.ai)

Raportowanie Incydentów W Zgodzie Z NIS2 – Jak Działa Zasada 24h/72h

Dlaczego raportowanie incydentów stało się kluczowe w dyrektywie NIS2

Dyrektywa NIS2 (Network and Information Systems Directive 2) wprowadza jednolite wymogi w całej UE dotyczące cyberbezpieczeństwa, w tym obowiązek szybkiego zgłaszania poważnych incydentów bezpieczeństwa. Organizacje uznane za podmioty kluczowe lub istotne (ang. essential and important entities) muszą raportować incydenty o znaczącym wpływie na usługi zgodnie z zasadą 24h/72h.

Czytaj dalej „Raportowanie Incydentów W Zgodzie Z NIS2 – Jak Działa Zasada 24h/72h”