Dyrektywa NIS2 (Network and Information Systems 2) nakłada na organizacje z wielu sektorów obowiązek wdrożenia zaawansowanych środków cyberbezpieczeństwa oraz wykazania zgodności z wymaganiami regulacyjnymi. Dla menedżerów, CISO oraz specjalistów IT odpowiedzialnych za bezpieczeństwo oznacza to konieczność opracowania kompleksowego planu działania – od fazy planowania, przez realizację technicznych i organizacyjnych zabezpieczeń, aż po przygotowanie dowodów zgodności na potrzeby audytu.
Badacze ThreatFabric ujawnili nową rodzinę mobilnego malware’u na Androida o nazwie Herodotus. To trojan bankowy typu Device Takeover (DTO), który podczas zdalnego sterowania telefonem symuluje ludzkie pisanie – wprowadza znaki pojedynczo z losowymi przerwami 0,3–3 s – aby zmylić mechanizmy antyfraudowe oparte na tempie interakcji i rytmie klawiatury. Kampanie potwierdzono m.in. we Włoszech i Brazylii, a zestawy fałszywych nakładek („overlays”) przygotowano także dla banków i serwisów krypto w USA, Wielkiej Brytanii, Turcji i Polsce.
W skrócie
Nowość: wprowadzanie tekstu z losowymi opóźnieniami imituje człowieka i utrudnia wykrycie automatyzacji.
Zdolności: przejęcie urządzenia (DTO) przez nadużycie Accessibility Service, nakładki na aplikacje bankowe, podgląd ekranu, kradzież kodów SMS/2FA.
Dystrybucja: smishing → dropper (sideloading), podszywanie się m.in. pod „Banca Sicura” i „Modulo Seguranca Stone”.
Model: zapowiedziany jako Malware-as-a-Service (MaaS), autor „K1R0”.
Kontekst / historia / powiązania
ThreatFabric wskazuje, że Herodotus nie jest prostą ewolucją, ale ma fragmenty kodu i technik znanych z trojana Brokewell (np. ciągi znaków „BRKWL_JAVA”, podobna obfuskacja). To sugeruje „zszycie” komponentów z nowymi elementami, w tym modułem do bardziej „ludzkich” interakcji.
Analiza techniczna / szczegóły luki
Wejście tekstu: zamiast wklejać cały ciąg (co bywa wykrywane jako nieludzkie), malware dzieli tekst na znaki i wstawia je z losowym opóźnieniem 300–3000 ms. Celem jest ominięcie detekcji behawioralnej opartej na czasie wprowadzania danych.
Zdalne sterowanie: polecenia obejmują m.in. kliknięcia po elementach/koordynatach, gesty, akcje globalne (Back/Home/Recents), wpisywanie tekstu, a także VNC/screen-sharing.
Ukrywanie aktywności: „blocking overlay” – pełnoekranowa nakładka imitująca ekran ładowania, która maskuje działania oszusta podczas przelewów.
Kradzież danych: fałszywe strony logowania nad aplikacjami banków/krypto, przechwytywanie SMS (2FA), logowanie zawartości ekranu.
Dystrybucja i łańcuch infekcji: smishing prowadzący do droppera napisanego przez tego samego autora; dropper pomaga obejść ograniczenia Android 13+ dla Accessibility, uruchamia payload i prosi ofiarę o nadanie uprawnień.
Infrastruktura: komunikacja MQTT; domena google-firebase[.]digital z wieloma subdomenami przypisywanymi do różnych operatorów kampanii.
Praktyczne konsekwencje / ryzyko
Bankowość mobilna i fintech: Kontrole antyfraudowe polegające wyłącznie na tempie/rytmie interakcji mogą zostać zdegradowane – przerwy „jak u człowieka” obniżają ryzyko z punktu widzenia prostych silników behawioralnych. Potrzebne jest korelacyjne podejście (ryzyko urządzenia + sygnały sesyjne + behawioryka na poziomie indywidualnego wzorca).
Użytkownicy w Polsce: choć potwierdzone kampanie to Włochy i Brazylia, istnieją gotowe nakładki na aplikacje bankowe w Polsce, co wskazuje na realne ryzyko lokalnych kampanii.
Behawioralne modele per-użytkownik: zamiast prostych progów tempa wpisywania, modelować indywidualne wzorce; łączyć z detekcją anomalii na poziomie sekwencji UI (np. trajektorie kliknięć, wzorce nawigacji).
Weryfikacja transakcji wysokiego ryzyka: step-up auth niezależny od SMS (np. FIDO2/push w zaufanej aplikacji), geokorelacja, challenge-response w obrębie aplikacji.
Honeypoty anty-overlay: dynamiczne elementy UI i ukryte pola wykrywające „set text”/clipboard zamiast realnych zdarzeń klawiszy.
Nie instaluj z SMS-ów/WWW – tylko Google Play i sprawdzony vendor MDM; wyłącz „instalację z nieznanych źródeł”.
Uważaj na prośby o Accessibility – legalne aplikacje rzadko tego potrzebują do bankowości.
2FA bez SMS (aplikacyjna/push), aktualizacje Androida i Play Protect; w razie podejrzenia DTO – natychmiast rozłącz internet, zadzwoń do banku innym kanałem, zresetuj urządzenie i hasła.
Edukacja smishingowa (również dla helpdesku i contact center). Te zalecenia wynikają ze sposobu działania Herodotus (smishing→dropper→Accessibility→DTO).
Różnice / porównania z innymi przypadkami
Brokewell vs. Herodotus: Brokewell był wcześniejszą rodziną DTO; Herodotus wykorzystuje jego moduły i techniki, ale dodaje „humanizację” wejścia jako kluczową innowację anty-detekcyjną.
Na tle typowych trojanów bankowych: wklejanie danych/clipboard jest szybkie, ale „nieludzkie” – Herodotus celowo zwalnia i randomizuje. Media branżowe potwierdzają, że te przerwy potrafią wynosić do 3 sekund.
Podsumowanie / kluczowe wnioski
Herodotus to sygnał, że fraud na Androidzie wchodzi w erę „anty-behawioralną”: przestępcy modelują ludzkie zachowanie, żeby oszukać silniki antyfraudowe. Skuteczna obrona wymaga pełnej warstwowości: telemetryki urządzenia, detekcji DTO, modeli per-użytkownik, silnych metod weryfikacji transakcji i restrykcji instalacji aplikacji. Organizacje w Polsce powinny traktować temat priorytetowo, bo nakładki na krajowe aplikacje są już w arsenale operatorów.
The Record (Recorded Future News): „New Android malware mimics human typing to evade detection, steal money” (28.10.2025) – streszczenie i regionalizacja (Włochy, Brazylia; nakładki m.in. Polska). (The Record from Recorded Future)
The Hacker News: „New Android Trojan ‘Herodotus’ Outsmarts Anti-Fraud Systems by Typing Like a Human” (28.10.2025) – potwierdzenie MaaS, Brokewell, zakres opóźnień. (The Hacker News)
BankInfoSecurity: „‘Herodotus’ Android Trojan Mimics Human Sluggishness” (28.10.2025) – opis anty-detekcji (opóźnienia do 3 s) i łańcucha infekcji. (BankInfoSecurity)
The Register: „Android malware types like your gran to steal banking creds” (28.10.2025) – omówienie kampanii i infrastruktury (domena google-firebase[.]digital). (The Register)
Najnowsze obserwacje firm badawczych wskazują na gwałtowny wzrost mocy wolumetrycznych ataków DDoS realizowanych przez klasę botnetów „TurboMirai”. Najgłośniejszy przedstawiciel — Aisuru — ma za sobą publicznie raportowane uderzenia przekraczające 20 Tb/s oraz 4 Gpps, w większości wymierzone w ekosystem gier online. Paradoksalnie, kod Aisuru nie generuje ruchu ze sfałszowanymi źródłami (no-spoofing), co ułatwia śledzenie i sanację zainfekowanych urządzeń po stronie operatorów sieci i dostawców internetu.
W skrócie
Moc ataków: >20 Tb/s i/lub >4 Gpps; notowane incydenty sięgały nawet ~29,6 Tb/s (krótkie „testy” mocy).
Pochodzenie: klasa TurboMirai — warianty Mirai z naciskiem na direct-path (bez refleksji/amplifikacji) i zwiększoną przepustowość per węzeł.
Brak spoofingu: ułatwia traceback i powiązanie ruchu z konkretnymi abonentami (SAV na brzegu dostępowym + brak uprawnień w urządzeniach).
Celowniki: głównie gaming/ISP, ale wpływ bywa systemowy (zatory międzyoperatorskie, awarie line-cardów).
Kompozycja botnetu: routery SOHO, rejestratory DVR, kamery IP i inne CPE ze wspólnymi OEM-ami/firmware.
Kontekst / historia / powiązania
Aisuru zadebiutował publicznie w 2024 r. w kontekście ataków na platformy gamingowe. W 2025 r. skala i częstotliwość rosły — od 6,3 Tb/s (incydent na KrebsOnSecurity w maju) przez przekroczenia 11 Tb/s, a następnie publiczne demonstracje mocy >22 Tb/s i ~29,6 Tb/s w październiku. Trend potwierdza szerszą narrację branżową: ostatnie lata to wysyp „hiper-wolumetrycznych” ataków oraz przejście od prostego DDoS do DDoD (Distributed Denial of Defense) — kampanii projektowanych do przeciążania samych systemów obrony.
Analiza techniczna / szczegóły luki
Wektory i charakterystyki ruchu
Direct-path UDP/TCP/GRE z przewagą średnich rozmiarów pakietów (ok. 540–750 B); widoczne także małe pakiety w atakach pps-owych. Zmienność flag TCP; obserwowano nawet 119 kombinacji w jednym ataku.
„Carpet bombing” oraz pseudo-losowa rotacja portów źródłowych/docelowych.
Wysokie Gpps uszkadzały/wybijały karty liniowe routerów szaszetowych (chassis line cards).
Większość kampanii z Aisuru to pojedynczy wektor direct-path; okazjonalnie łączony z innymi usługami booter/stresser w multivektor.
Dlaczego brak spoofingu? Malware działa bez przywilejów w systemach CPE, a na brzegu wielu sieci dostępnych działa SAV/BCP38, co uniemożliwia fałszowanie źródeł. Efekt uboczny: możliwy traceback → korelacja z abonentem → kwarantanna/remediacja.
Skład i funkcje botnetu Węzły to głównie routery domowe, CCTV, DVR i pokrewne CPE. Operatorzy aktywnie poszerzają pulę infekowalnych urządzeń, a Aisuru oferuje też usługę proxy rezydencyjnych do odbijania ataków L7/HTTPS z zewnętrznych harnessów.
Praktyczne konsekwencje / ryzyko
Operatorzy/ISP: z Aisuru znane są odpływy (outbound) >1 Tb/s z sieci dostępowych wskutek botów u abonentów; skutkiem bywa kongestia między AS-ami, degradacja QoS dla „postronnych” klientów, a w skrajnych przypadkach awarie kart liniowych.
Dostawcy gier / CDN / hosting: krótkotrwałe, ale ekstremalne piki mogą przewyższać lokalną/trasową pojemność, powodując łańcuchowe zakłócenia i re-routingi.
Przedsiębiorstwa: choć większość kampanii celuje w gaming/ISP, model direct-path i warstwa L3/L4 oznacza, że dowolny nieutwardzony zasób internetowy może zostać „przetestowany” lub wykorzystany do demonstracji mocy. Trend strategiczny DDoD pokazuje, że celem bywa sama obrona, nie tylko usługa.
Rekomendacje operacyjne / co zrobić teraz
Dla operatorów i dużych AS-ów
Instrumentacja wszystkich krawędzi (w tym outbound/crossbound), by detekcja i tłumienie wychodzących ataków miały ten sam priorytet co inbound.
IDMS + iACL/BCP-y: stosować inteligentne systemy łagodzenia (np. Arbor TMS/Sightline) oraz najlepsze praktyki iACL, Flowspec i S/RTBH, pamiętając o limitach sprzętowych na reguły.
SAV/BCP38 konsekwentnie na brzegu dostępowym; automatyzacja traceback→powiadomienie→kwarantanna dla zainfekowanych CPE.
Proaktywny rekonesans wewnętrzny w celu identyfikacji podatnych CPE u klientów (policyjne procedury remediacji/wymiany).
Segmentacja i separacja: rozdzielone łącza dla ruchu użytkowników wewnętrznych vs. usług publicznych; whitelisty protokołów/portów i limity rate.
Ćwiczenia: regularne testy „table-top” i techniczne (z udziałem dostawcy scrubbingu), w tym scenariusze krótkich hiper-pików Tb/s.
Dla zespołów SecOps/NetOps
Telemetria L3/L4 z wysoką rozdzielczością (pps/bps/rozmiary pakietów), alerting na outbound anomaliach i „carpet-bombing”.
Higiena CPE w politykach zakupowych i SLA z ISP (wymagania dot. aktualizacji, wyłączenia usług zbędnych, domyślne hasła).
Różnice / porównania z innymi przypadkami
Mirai (2016) vs. TurboMirai (2025): Mirai słynęło z refleksji/amplifikacji i rekordów setek Gb/s; TurboMirai/Aisuru dostarcza wieloterabitowe piki bez spoofingu, czystym direct-path z botów CPE, przy czym moc per węzeł jest większa, a wektory bardziej zróżnicowane (np. GRE).
Klasyczne DDoS vs. DDoD: dzisiejsze kampanie nie zawsze „idą w wolumen” — często atakują mechanizmy obrony i łańcuchy dostawcze (multidestination, poziomy horyzontalne), co wymaga odporności architekturalnej, nie tylko „większej rury”.
Podsumowanie / kluczowe wnioski
Aisuru to na dziś najgroźniejszy przykład klasy TurboMirai: ataki >20 Tb/s, rekordowe piki ~29,6 Tb/s, uderzenia głównie w gaming/ISP, ale z efektem ubocznym dla szerokiego internetu.
Brak spoofingu to zarówno słabość (łatwiejszy traceback), jak i ostrzeżenie: jeśli outbound suppression nie jest wdrożony, wasza sieć może stać się źródłem problemu.
Priorytet na krawędziach: równoważenie inbound/outbound, testy gotowości, modernizacja narzędzi IDMS oraz egzekwowanie BCP.
Źródła / bibliografia
SecurityWeek: TurboMirai-Class ‘Aisuru’ Botnet Blamed for 20+ Tbps DDoS Attacks (28 października 2025). (SecurityWeek)
NETSCOUT ASERT: Aisuru and Related TurboMirai Botnet DDoS Attack Mitigation and Suppression—October 2025—v1.0 (24 października 2025). (NETSCOUT)
KrebsOnSecurity: DDoS Botnet Aisuru Blankets US ISPs in Record DDoS (10 października 2025) oraz KrebsOnSecurity Hit With Near-Record 6.3 Tbps DDoS (20 maja 2025). (Krebs on Security)
Akamai: Move Over, DDoS: It’s the Era of Distributed Denial of Defense (DDoD) (16 września 2025) – szerszy kontekst trendów. (akamai.com)
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:
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).
Unikalne hasło per serwis + menedżer haseł.
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:
Masowy reset haseł i/lub wymuszenie rotacji tam, gdzie brak MFA lub wykryto recykling.
Egzekwuj MFA / passkeys dla poczty, VPN, SaaS i krytycznych aplikacji. Google i branża wskazują to jako najlepszą obronę przed kradzieżą poświadczeń.
Blokada recyklingu haseł (zasady złożoności + sprawdzanie przeciw słownikom wycieków przy zmianie hasła).
Detekcja ATO: reguły SIEM/UEBA na nietypowe logowania (nowe ASN, niestandardowe UA, nietypowa pora/geo), korelacja z listami adresów z HIBP.
Unieważnij sesje po zmianie haseł; włącz powiadomienia o nowych logowaniach.
Hunting na infostealery: IOC/IOA popularnych rodzin (Raccoon, RedLine, Vidar, Lumma itd.), kontrola egzekucji przeglądarek i kradzieży browser creds.
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
SecurityWeek — „Cybercriminals Trade 183 Million Stolen Credentials on Telegram, Dark Forums” (28 paź 2025). (SecurityWeek)
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
Ł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.
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.
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.
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.
Eksfiltracja i C2 Zebrane artefakty są pakowane i uploadowane do GoFile; link jest zwracany atakującemu przez Discord webhook wraz z metadanymi ofiary.
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ę.
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):
Natychmiast zmień hasło do Discorda; to unieważnia tokeny. Następnie wyloguj wszystkie sesje i przeinstaluj klienta Discord (czysta instalacja z oficjalnej strony).
Włącz/egzekwuj MFA na Discordzie oraz wszędzie, gdzie to możliwe.
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.
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
BleepingComputer — „Hackers steal Discord accounts with RedTiger-based infostealer”, 26 października 2025. (BleepingComputer)
Netskope Threat Labs — „RedTiger in the Wild: Targeting Gamers & Discord Accounts” (analiza kampanii, TTP, zasięg geograficzny). (Netskope)
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:
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.
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.
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
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.
Retencja i łańcuch dowodowy: ustandaryzuj politykę data preservation (czas, zakres, integralność), aby spełnić oczekiwania nowych kanałów pomocy prawnej.
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ść.
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).
Ć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)
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.
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):
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.
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.
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).
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):
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.
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).
Awareness: mikro-kampania dla pracowników (60-sek. wideo/komunikat) nt. „fałszywego dziedziczenia” i zasad bezpiecznej rejestracji passkeys.
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ł).
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)
