Co znajdziesz w tym artykule?
- 1 Wprowadzenie do problemu / definicja luki
- 2 W skrócie
- 3 Kontekst / historia / powiązania
- 4 Analiza techniczna / szczegóły luki
- 5 Praktyczne konsekwencje / ryzyko
- 6 Rekomendacje operacyjne / co zrobić teraz
- 7 Różnice / porównania z innymi przypadkami
- 8 Podsumowanie / kluczowe wnioski
- 9 Źródła / bibliografia
Wprowadzenie do problemu / definicja luki
CTM360 opisało szeroko zakrojoną kampanię, w której przestępcy „uzbrajają” zaufane usługi Google (Google Groups, Google Docs, Google Drive), aby przemycać linki do złośliwych plików i ominąć mechanizmy filtracji oparte na reputacji domen. Klucz jest prosty: użytkownik widzi „bezpieczny” ekosystem Google i obniża czujność, a organizacyjne zabezpieczenia często przepuszczają ruch do takich usług.
W tej operacji wykorzystano ponad 4 000 złośliwych grup Google oraz ponad 3 500 URL-i hostowanych w Google do dystrybucji dwóch rodzin zagrożeń:
- Lumma Stealer (Windows) – infostealer kradnący dane uwierzytelniające i sesje,
- Ninja Browser (Linux) – trojanizowana przeglądarka na bazie Chromium z mechanizmami trwałości i rozszerzeniami o złośliwej funkcjonalności.
W skrócie
- Atak startuje od socjotechniki w Google Groups: posty udające realne wątki techniczne (problemy z siecią, błędy autentykacji, konfiguracje).
- Linki prowadzą przez skracacze / przekierowania (Docs/Drive), które rozpoznają system operacyjny ofiary i podają inny ładunek dla Windows i Linux.
- Na Windows: archiwum o ~950 MB po rozpakowaniu, w praktyce „napompowane” do omijania skanowania statycznego; uruchomienie prowadzi do rekonstrukcji i odpalenia payloadu Lumma m.in. przez komponenty AutoIt.
- Na Linux: „Ninja Browser” instaluje po cichu rozszerzenia (np. NinjaBrowserMonetisation) oraz utrzymuje trwałość (harmonogramowane zadania, ciche aktualizacje).
Kontekst / historia / powiązania
Lumma Stealer (LummaC2) jest rozwijany i sprzedawany w modelu Malware-as-a-Service (MaaS) co zwiększa skalę i dostępność zagrożenia. MITRE klasyfikuje Lumma jako rodzinę infostealera używaną co najmniej od 2022 r. i opisuje jej typowe techniki (m.in. kradzież danych z przeglądarek, użycie AutoIt, komunikację po HTTP).
W 2024–2025 obserwowano wyraźny wzrost aktywności infostealerów, a ESET raportował silny wzrost detekcji Lumma (m.in. wskazując na różne wektory dostarczania – od phishingu po „sprytne” kampanie typu fake CAPTCHA).
Nowością w kampanii CTM360 jest szczególnie świadome wykorzystanie „zaufanej otoczki” Google jako infrastruktury dystrybucyjnej i „warstwy wiarygodności” dla linków.
Analiza techniczna / szczegóły luki
1. Etap 1 – wejście przez Google Groups (socjotechnika)
Atakujący publikują w grupach dyskusyjnych posty stylizowane na realne dyskusje IT. CTM360/BleepingComputer zwraca uwagę na dopasowywanie treści do branży i wplatanie nazw organizacji/keywordów, aby wyglądało to jak „wewnętrzny” problem lub rekomendowane narzędzie.
2. Etap 2 – przekierowania i selekcja systemu operacyjnego
Linki często idą przez:
- skracacze URL,
- przekierowania hostowane w Google (Docs/Drive),
które następnie serwują inny payload w zależności od OS (Windows vs Linux).
3. Windows – „napompowane” archiwum + łańcuch AutoIt → Lumma Stealer
Zaobserwowano mechanizm omijania skanerów: archiwum po rozpakowaniu ma ok. 950 MB, podczas gdy realny złośliwy komponent ma ok. 33 MB, a plik wykonywalny jest dopełniany „pustymi” bajtami (padding null bytes), co utrudnia skanowanie i analizę statyczną.
Dalej łańcuch obejmuje m.in. rekonstrukcję segmentów binarnych, uruchomienie komponentu kompilowanego w AutoIt i odszyfrowanie/wykonanie payloadu w pamięci. To jest spójne z obserwowanymi technikami Lumma opisywanymi także w ATT&CK.
Efekty działania (przykłady z obserwacji CTM360/BleepingComputer):
- eksfiltracja haseł z przeglądarek,
- kradzież cookies/sesji,
- komendy powłoki,
- POST-y HTTP do infrastruktury C2.
4. Linux – trojanizowany „Ninja Browser” (Chromium) + rozszerzenia + trwałość
„Ninja Browser” udaje przeglądarkę „privacy/anonymity”, ale:
- instaluje złośliwe rozszerzenia bez zgody,
- wdraża ukryte mechanizmy persistence.
Rozszerzenie NinjaBrowserMonetisation miało m.in. śledzić użytkownika, wstrzykiwać skrypty do sesji, manipulować kartami i cookies oraz ładować zdalną zawartość; kod JS był silnie obfuskowany (m.in. XOR / Base56-like).
Trwałość: wskazano na harmonogramowane zadania odpytywania serwerów atakującego, ciche aktualizacje i utrzymanie długoterminowego dostępu.
Praktyczne konsekwencje / ryzyko
Dla Windows (Lumma Stealer):
- kradzież poświadczeń i tokenów sesyjnych → Account Takeover,
- fraud finansowy,
- wykorzystanie skradzionych danych jako „paliwa” dla IAB (Initial Access Brokers) i dalszych etapów (np. ransomware).
Dla Linux (Ninja Browser):
- cicha kompromitacja przeglądarki i sesji webowych,
- backdoor-like persistence oraz możliwość dogrywania funkcji/payloadów poprzez aktualizacje,
- ryzyko przejęcia kont (SSO, panele admina, chmura) przez kradzież cookies i danych uwierzytelniających.
Dla organizacji jako całości:
- „zaufana” infrastruktura SaaS zwiększa skuteczność socjotechniki i omijanie filtrów URL,
- większe prawdopodobieństwo, że incydent zacznie się od „niewinnego” kliknięcia w wątek dyskusyjny.
Rekomendacje operacyjne / co zrobić teraz
Szybkie działania (24–72h):
- Monitoring i blokady IoC (EDR/NDR/Firewall/Proxy) wg list CTM360: domeny, IP, hashe powiązane z kampanią.
- Wprowadź detekcje na:
- nietypowe łańcuchy przekierowań z Docs/Drive,
- pobrania dużych archiwów „software” z wątków publicznych,
- tworzenie scheduled tasks na stacjach roboczych (Linux i Windows), zwłaszcza z podejrzanymi ścieżkami/argumentami.
- Przegląd przeglądarek i rozszerzeń: audyt instalacji, wymuszanie allowlisty rozszerzeń (gdzie możliwe), detekcja nieautoryzowanych profili/przeglądarek.
Średni termin (1–4 tygodnie):
- Polityka „download hygiene”: zakaz instalacji narzędzi z forów/publicznych dyskusji bez weryfikacji, plus proces zatwierdzania.
- Wzmocnij ochronę tożsamości:
- reautoryzacja sesji, skrócenie TTL dla sesji administracyjnych,
- wymuszenie phishing-resistant MFA (FIDO2) tam, gdzie to realne. (To rekomendacja praktyczna; nie wynika wprost ze źródeł, ale adresuje ryzyko kradzieży cookies/sesji.)
- Rozważ reguły DLP/UEBA pod kątem masowej eksfiltracji danych uwierzytelniających z przeglądarek oraz nietypowych POST-ów HTTP do świeżo rejestrowanych domen.
Różnice / porównania z innymi przypadkami
- Klasyczne kampanie Lumma często bazują na fake CAPTCHA / ClickFix i nakłanianiu do wykonania komend (np. Win+R) – taki trend opisywały m.in. Netskope i ESET.
- Kampania CTM360 wyróżnia się tym, że mocno stawia na weaponizację ekosystemu Google (Groups/Docs/Drive) oraz na dwutorowość OS (Windows: infostealer, Linux: trojanizowana przeglądarka z trwałością).
Podsumowanie / kluczowe wnioski
- To nie jest „kolejny stealer” – to kampania dystrybucyjna na masową skalę, wykorzystująca reputację usług Google, co podbija skuteczność i utrudnia blokady.
- Windows jest celem dla Lumma Stealer, a Linux dla Ninja Browser z rozszerzeniami i mechanizmami persistence – w praktyce organizacja musi bronić obu ścieżek.
- Największą przewagą obrońców jest szybkie wdrożenie detekcji na redirect chain, audyt rozszerzeń oraz monitoring scheduled tasks + blokady IoC.
Źródła / bibliografia
- CTM360 – “Ninja Browser & Lumma Infostealer (Delivered via Weaponized Google Services)” (ctm360.com)
- BleepingComputer – “CTM360: Lumma Stealer and Ninja Browser malware campaign abusing Google Groups” (15 lutego 2026) (BleepingComputer)
- MITRE ATT&CK – “Lumma Stealer (S1213)” (attack.mitre.org)
- ESET – “Lumma Stealer: A fast-growing infostealer threat” (31 stycznia 2025) (ESET)
- Netskope – “Lumma Stealer: Fake CAPTCHAs & New Techniques to Evade Detection” (23 stycznia 2025) (Netskope)