Archiwa: Malware - Strona 87 z 126 - Security Bez Tabu

Tag: Malware

Infostealer po raz pierwszy kradnie „sekrety” OpenClaw: nowy wektor ryzyka dla lokalnych agentów AI

Wprowadzenie do problemu / definicja luki

Klasyczne infostealery kojarzą się z kradzieżą haseł z przeglądarek, ciasteczek sesyjnych, danych portfeli krypto i plików konfiguracyjnych popularnych aplikacji. Teraz obserwujemy przesunięcie ciężaru: ten sam „hurtowy” mechanizm wykradania plików zaczyna zbierać także sekrety agentów AI uruchamianych lokalnie – na przykład OpenClaw, który przechowuje tokeny, klucze i trwałą pamięć kontekstu na stacji roboczej użytkownika.

To nie jest „exploit w OpenClaw” w rozumieniu CVE. To raczej zmiana wartości kradzionych danych: agent AI staje się koncentratorem dostępu do usług (poczta, komunikatory, kalendarze, API), więc jego konfiguracja jest dla atakujących wyjątkowo opłacalna.

W skrócie

  • Odnotowano pierwszy przypadek „in-the-wild”, gdzie infostealer wykradł środowisko konfiguracyjne OpenClaw i pliki zawierające tokeny/klucze/pamięć agenta.
  • Według relacji badaczy, próbka wyglądała na wariant Vidar; kradzież nastąpiła 13 lutego 2026 (data infekcji/eksfiltracji wskazana w opisie incydentu).
  • Nie był to jeszcze „dedykowany moduł pod OpenClaw” – raczej szerokie file-grabbing po słowach kluczowych typu „token”, „private key”, które „zahaczyło” o katalog konfiguracyjny OpenClaw.

Kontekst / historia / powiązania

OpenClaw to agent AI uruchamiany lokalnie, utrzymujący trwałą konfigurację i pamięć na urządzeniu użytkownika oraz integrujący się z usługami online (co oznacza realne tokeny, klucze API i dane sesyjne).

Równolegle rośnie drugi front ryzyka: ekosystem rozszerzeń/„skills”. 1Password opisywał przypadki, w których popularne „skills” pełniły rolę nośnika malware (instrukcje instalacji, socjotechnika, skrypty etapowe), a autorzy podkreślali, że przenośny format „skills” może stać się problemem między różnymi platformami agentów.

Na to nakłada się szerszy trend: infostealery coraz częściej wychodzą poza klasyczne scenariusze Windows i intensywnie uderzają też w macOS, wykorzystując socjotechnikę, malvertising i „ClickFix” (nakłanianie do wklejania komend w Terminalu), aby kraść hasła, tokeny, dane przeglądarek, keychain i „developer secrets”.

Analiza techniczna / szczegóły luki

Co zostało skradzione?

W opisywanym incydencie skradzione miały zostać m.in. pliki:

  • openclaw.json – zawierał m.in. (zredagowany) e-mail, ścieżki workspace oraz token uwierzytelniający bramę (gateway token) o wysokiej entropii. Taki token może umożliwić podszycie się w zapytaniach uwierzytelnionych, a w pewnych warunkach także zdalne połączenie do lokalnej instancji (jeśli jest wystawiona/osiągalna z sieci).
  • device.json – zawierał parę kluczy (public/private) do parowania i podpisywania. Prywatny klucz może potencjalnie umożliwić podpisywanie komunikatów jak „zaufane urządzenie” i obejście niektórych kontroli opartych o tożsamość urządzenia.
  • soul.md oraz pliki pamięci (np. AGENTS.md, MEMORY.md) – opis zachowania agenta i trwały kontekst: logi aktywności, wiadomości prywatne, zdarzenia z kalendarza itp.

Jak to zostało zebrane?

Wg opisu, stealer nie „polował” na OpenClaw z precyzją modułu, tylko realizował masowe przeszukiwanie i eksfiltrację plików na podstawie rozszerzeń, ścieżek i słów kluczowych typu „token” / „private key”. Katalog konfiguracyjny OpenClaw po prostu pasował do heurystyki.

Dlaczego to ważne dla obrońców?

To sygnał, że agent AI staje się dla przestępców tym, czym kiedyś stała się przeglądarka: „portfelem” sesji, tokenów i tożsamości. Hudson Rock (cytowany w mediach) przewiduje, że kolejnym krokiem będą dedykowane moduły rozumiejące strukturę plików agentów, analogicznie do modułów pod Chrome/Telegram.

Praktyczne konsekwencje / ryzyko

  1. Przejęcie usług spiętych z agentem
    Tokeny i klucze API mogą otworzyć dostęp do poczty, kalendarzy, komunikatorów czy integracji automatyzacji – zależnie od tego, co użytkownik podpiął do agenta.
  2. „Kradzież tożsamości” agenta i kontekstu
    Wykradzenie pamięci (logów, wiadomości, zdarzeń) to nie tylko prywatność. To także materiał do: BEC, spear phishingu, oszustw „na kontekst”, szantażu, a w firmach – do dalszej eskalacji (np. poprzez znajomość procesów i narzędzi).
  3. Łatwiejsze ataki następcze
    Infostealery bywają „etapem 0” przed ransomware lub włamaniami domenowymi: kradną dostęp, który potem jest monetyzowany przez inne grupy. Trend skali i zasięgu infostealerów (w tym na macOS) wzmacnia prawdopodobieństwo, że takie incydenty będą częstsze.

Rekomendacje operacyjne / co zrobić teraz

Jeśli używasz OpenClaw (indywidualnie lub w firmie)

  • Rotuj i unieważnij sekrety: klucze API, tokeny dostępu, tokeny bramy/gateway, sesje wpiętych usług. Zacznij od tych o najszerszych uprawnieniach.
  • Sprawdź ekspozycję instancji: upewnij się, że lokalna instancja nie jest przypadkiem wystawiona na świat (port-forward, publiczny adres, błędna konfiguracja). Zasada: agent lokalny ≠ usługa publiczna.
  • Ogranicz dostęp do plików konfiguracyjnych: uruchamiaj agenta na osobnym koncie systemowym, minimalne uprawnienia do katalogów, wrażliwe pliki tylko dla właściciela (chmod/ACL).
  • Przenieś sekrety do menedżera sekretów (tam gdzie to możliwe): ogranicz przechowywanie długowiecznych tokenów w plaintext w katalogach użytkownika.
  • Podejście „zero-trust dla integracji”: przyznawaj agentowi najmniejsze możliwe scope’y, osobne konta techniczne, krótkie TTL tokenów, regularny przegląd integracji.

Jeśli bronisz organizacji (SOC/IR)

  • Telemetria i detekcje na eksfiltrację: poluj na nietypowe archiwizowanie i wysyłkę katalogów konfiguracyjnych, zwłaszcza w katalogach użytkownika (tworzenie ZIP w /tmp itp.) oraz na podejrzane POST-y do świeżych domen. Microsoft opisuje te wzorce jako typowe w kampaniach stealerów.
  • Zabezpieczenia przed socjotechniką: bloki na „ClickFix”, malvertising, fałszywe instalatory (DMG/PKG), polityki uruchamiania, App Control – bo to dziś jeden z głównych kanałów dostarczania stealerów również na macOS.
  • Kontrola łańcucha dostaw „skills”: traktuj rozszerzenia agenta jak kod wykonywalny. Weryfikuj źródła, podpisy, review, skanuj repozytoria, izoluj środowisko uruchomieniowe. Case’y opisane w analizach „skills” pokazują, że sama „bramka narzędziowa” (policy gating) nie wystarczy, jeśli skill skłoni użytkownika/agenta do uruchomienia komend.

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

  • Tu nie ma (jeszcze) „modułu pod OpenClaw” – to istotna różnica. Incydent pokazuje, że nawet prymitywne heurystyki kradzieży plików już trafiają w agentów AI, bo ich foldery zawierają klasyczne „sekretne” słowa/artefakty.
  • „Skills” jako wektor dostarczenia vs. stealer jako etap kradzieży
    Kampanie złośliwych „skills” dotyczą częściej dostarczenia malware i przejęcia hosta przez social engineering/uruchamianie skryptów. Opisywany przypadek to etap po infekcji – stealer zbiera wartościowe dane, które teraz obejmują także „duszę” agenta (kontekst + sekrety).
  • Szerszy trend: infostealery idą wieloplatformowo
    Microsoft wskazuje eskalację kampanii na macOS i użycie cross-platform (np. Python) oraz nadużywanie zaufanych kanałów dystrybucji. To zwiększa szansę, że „sekrety agentów” będą kradzione niezależnie od systemu, jeśli pliki leżą lokalnie.

Podsumowanie / kluczowe wnioski

  • Agent AI uruchamiany lokalnie to magnes na infostealery, bo kumuluje dostęp do wielu usług i przechowuje długowieczne sekrety.
  • Pierwsze obserwacje pokazują „zwykłe” file-grabbing, ale logika rynku cyberprzestępczego sugeruje szybkie pojawienie się dedykowanych modułów do parsowania/odszyfrowywania danych agentów.
  • Obrona powinna łączyć: rotację sekretów, ograniczenie ekspozycji instancji, twarde uprawnienia plików, kontrolę integracji oraz detekcje eksfiltracji, a także rygor dla „skills” jako kodu wykonywalnego.

Źródła / bibliografia

  1. BleepingComputer – opis incydentu i lista wykradzionych plików OpenClaw (16 lutego 2026). (BleepingComputer)
  2. The Hacker News – dodatkowy kontekst techniczny (gateway token, device keys, perspektywa rozwoju stealerów) (16 lutego 2026). (The Hacker News)
  3. Microsoft Security Blog – „Infostealers without borders…” (kampanie na macOS, ClickFix, kradzież keychain/developer secrets, rekomendacje obrony) (2 lutego 2026). (Microsoft)
  4. 1Password – analiza ryzyka „skills” jako powierzchni ataku i mechanizmów dostarczania malware (luty 2026). (1password.com)
  5. Infostealers.com – tło dot. Vidar (charakterystyka kradzieży danych/telemetria infrastruktury) (31 grudnia 2023). (InfoStealers)

500 tys. kont VKontakte przejętych przez złośliwe rozszerzenia Chrome: jak działa kampania „VK Styles” i jak się bronić

Wprowadzenie do problemu / definicja luki

Przeglądarkowe rozszerzenia to dziś jeden z najbardziej niedoszacowanych wektorów ataku. Mają uprzywilejowany dostęp do treści stron (content scripts), sesji użytkownika i często szerokich uprawnień „host permissions”. Jeśli takie rozszerzenie okaże się złośliwe (lub zostanie przejęte), atakujący może działać „w środku” przeglądarki – tam, gdzie użytkownik jest już zalogowany, a mechanizmy ochronne serwisów (CSRF, restrykcje UI) bywają łatwiejsze do obejścia.

Właśnie ten scenariusz zmaterializował się w kampanii wymierzonej w VKontakte (VK): według ustaleń Koi Security i opisu incydentu w Recorded Future News / The Record, sieć pięciu powiązanych rozszerzeń Chrome doprowadziła do przejęcia ponad 500 tys. kont.

W skrócie

  • Skala: ~502 tys. potwierdzonych ofiar (łączna liczba instalacji/poszkodowanych w badaniu).
  • Wektor: 5 rozszerzeń Chrome udających narzędzia do „stylów”, motywów i ulepszania VK.
  • Efekt: aktywna manipulacja kontem (m.in. wymuszane subskrypcje grup, cykliczne resety ustawień), a nie tylko „śledzenie” czy adware.
  • Trwałość: mechanizmy utrzymania kontroli i wieloetapowe doładowywanie kodu z zewnętrznych źródeł.

Kontekst / historia / powiązania

Badacze Koi opisują kampanię jako działającą co najmniej od połowy 2025 r., z ciągłymi aktualizacjami do początku 2026 r. (czyli miesiące „cichej” obecności).
Co istotne, co najmniej jedno z rozszerzeń miało być wcześniej usunięte przez Google (już w 2024 r.) za naruszenia zasad – ale operator szybko „przesiadł się” na nowe identyfikatory rozszerzeń i kontynuował operację. To klasyczny wzorzec „whack-a-mole” w ekosystemie dodatków.

MITRE ATT&CK od lat opisuje nadużycia rozszerzeń przeglądarkowych jako technikę utrzymania dostępu i realizacji działań na stacji roboczej użytkownika – w praktyce to wygodny kanał persystencji i manipulacji ruchem/treścią stron.

Analiza techniczna / szczegóły luki

1) „Legalnie wyglądające” rozszerzenia + zaufanie użytkownika

„VK Styles” i powiązane dodatki były promowane jako kosmetyczne ulepszenia VK (motywy, poprawa UX). W opisie Koi kluczowe jest to, że na poziomie listingu i recenzji nic nie musiało wyglądać podejrzanie – a użytkownicy często akceptują szerokie uprawnienia, bo „inaczej nie zadziała”.

2) Uprawnienia i uruchamianie kodu na vk.com

Mechanika ataku opiera się o typowe możliwości rozszerzeń: host permissions oraz content scripts, które pozwalają wykonywać kod w kontekście odwiedzanych stron (np. vk.com) i reagować na zdarzenia sesji użytkownika.

3) Wieloetapowy ładunek i „C2” w serwisie społecznościowym

Najciekawszy element badania Koi: złośliwy kod miał być doładowywany dynamicznie z metadanych profilu VK (w tekście pada przykład profilu pełniącego rolę infrastruktury C2). Dzięki temu operator mógł zmieniać zachowanie kampanii bez klasycznych aktualizacji binarki rozszerzenia.

4) Manipulacja ochronami aplikacji webowej (CSRF) i wymuszone akcje

Według Koi, malware wykonywał manipulacje tokenami CSRF i automatyzował działania na koncie, m.in. dopisywanie do grup z wysokim prawdopodobieństwem przy sesji, a także cykliczne „odkręcanie” ustawień co ~30 dni, aby ofiara nie odzyskała kontroli na stałe.

5) Wskaźniki kompromitacji (IOC) – identyfikatory rozszerzeń

Koi publikuje listę ID pięciu rozszerzeń i ich przybliżoną popularność (największe miało ok. 400 tys. instalacji). To praktyczny punkt zaczepienia dla SOC/IR (telemetria przeglądarek, EDR, polityki przeglądarkowe).

Praktyczne konsekwencje / ryzyko

  1. Przejęcie konta „bez hasła” – jeśli rozszerzenie działa w przeglądarce zalogowanego użytkownika, może wykonywać akcje w jego imieniu (session riding), nawet gdy MFA jest włączone.
  2. Rozprzestrzenianie i monetyzacja – wymuszane dołączanie do grup i manipulacja ustawieniami może budować „zasięg” operatora, generować ruch, a nawet wspierać kampanie dezinformacyjne czy scam.
  3. Ryzyko dla firm – jeśli pracownik używa przeglądarki do pracy i prywatnie, rozszerzenie z szerokimi uprawnieniami jest realnym zagrożeniem dla danych firmowych (wgląd w treści stron, formularze, sesje).

W tle jest też problem systemowy: mimo procesu weryfikacji i zasad Web Store, złośliwe dodatki wciąż przenikają do marketplace’u (a potem wracają pod nowymi identyfikatorami).

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników indywidualnych (VK / Chrome)

  • Odinstaluj podejrzane rozszerzenia i sprawdź listę dodatków po ID (IOCs z raportu Koi).
  • Zmień hasło do VK i wyloguj wszystkie sesje (jeśli VK oferuje „log out of all devices/sessions”).
  • Zweryfikuj ustawienia konta: prywatność, powiązane aplikacje, nieznane grupy/subskrypcje, przekierowania, e-mail/telefon odzyskiwania.
  • Jeśli używałeś podobnych dodatków w innych serwisach: rotacja haseł i przegląd logów bezpieczeństwa.

Dla organizacji (IT/SOC)

  • Wymuś allow-listę rozszerzeń (polityki przeglądarkowe/MDM) i zablokuj instalację „z wolnej ręki”.
  • Monitoruj instalacje po extension ID (telemetria endpointów) oraz wykrywaj anomalia: nowe rozszerzenia z szerokimi host permissions, nietypowe aktualizacje, komunikacja z nietypowymi domenami.
  • Zredukuj uprawnienia: promuj dodatki korzystające z minimalnych/„optional permissions”, bo to ogranicza blast radius.
  • Edukacja użytkowników: „motywy”, „ulepszacze” i „darmowe funkcje premium” to częsty pretekst do wyłudzania uprawnień.

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

W porównaniu do „klasycznych” złośliwych rozszerzeń kradnących dane (np. hasła, treści stron), ta kampania wyróżnia się aktywną manipulacją kontem w serwisie społecznościowym oraz pomysłowym wykorzystaniem platformy (VK) jako elementu infrastruktury sterującej. To nie tylko eksfiltracja – to operacja wpływu na zachowanie kont i budowanie trwałego kanału dystrybucji.
Z perspektywy ATT&CK to dobrze wpisuje się w nadużycia rozszerzeń przeglądarkowych jako techniki zapewniającej persystencję i wykonywanie akcji po stronie klienta.

Podsumowanie / kluczowe wnioski

  • Rozszerzenia przeglądarki to pełnoprawny wektor przejęcia kont – szczególnie gdy działają na stronach, gdzie użytkownik jest stale zalogowany.
  • Kampania „VK Styles” pokazuje, że atakujący potrafią łączyć socjotechnikę (motywy/ulepszenia) z dynamicznym doładowywaniem kodu i automatyzacją akcji na koncie na masową skalę.
  • Najskuteczniejsze środki obrony to: redukcja liczby dodatków, minimalizacja uprawnień, allow-lista w firmach oraz szybka reakcja (odinstalowanie + reset sesji/hasła).

Źródła / bibliografia

  1. The Record (Recorded Future News) – opis incydentu i odniesienie do raportu Koi Security. (The Record from Recorded Future)
  2. Koi Security (Koi Research) – raport techniczny „VK Styles: 500K Users Infected…”, IOC i szczegóły kampanii. (koi.ai)
  3. Chrome for Developers – model uprawnień (host permissions, content scripts, optional permissions). (Chrome for Developers)
  4. Chrome Web Store – zasady programu i proces weryfikacji (malware/spyware zakazane, ochrona użytkowników). (Chrome for Developers)
  5. MITRE ATT&CK – technika nadużyć rozszerzeń przeglądarkowych (Browser Extensions). (MITRE ATT&CK)

Ninja Browser i Lumma Stealer: kampania malware nadużywająca Google Groups, Docs i Drive (luty 2026)

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):

  1. Monitoring i blokady IoC (EDR/NDR/Firewall/Proxy) wg list CTM360: domeny, IP, hashe powiązane z kampanią.
  2. 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.
  3. 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

  1. CTM360 – “Ninja Browser & Lumma Infostealer (Delivered via Weaponized Google Services)” (ctm360.com)
  2. BleepingComputer – “CTM360: Lumma Stealer and Ninja Browser malware campaign abusing Google Groups” (15 lutego 2026) (BleepingComputer)
  3. MITRE ATT&CK – “Lumma Stealer (S1213)” (attack.mitre.org)
  4. ESET – “Lumma Stealer: A fast-growing infostealer threat” (31 stycznia 2025) (ESET)
  5. Netskope – “Lumma Stealer: Fake CAPTCHAs & New Techniques to Evade Detection” (23 stycznia 2025) (Netskope)

Pastebin jako wektor oszustwa: komentarze promują atak ClickFix z JavaScriptem, który przechwytuje swapy krypto

Wprowadzenie do problemu / definicja luki

W połowie lutego 2026 zaobserwowano kampanię, w której napastnicy wykorzystują komentarze pod wpisami na Pastebin jako kanał dystrybucji instrukcji prowadzących do kradzieży kryptowalut. Mechanizm jest podstępny: ofiara dostaje „poradnik arbitrażowy”, który rzekomo pozwala zarobić na błędzie w wycenie swapów, a w praktyce nakłania do samodzielnego uruchomienia złośliwego JavaScriptu w przeglądarce. To wariant techniki ClickFix – czyli socjotechniki, gdzie atakujący „wkłada ofierze w ręce” krok po kroku działania, które same realizują kompromitację.

W tym przypadku nie mówimy o klasycznym pobraniu malware na system, tylko o przejęciu logiki działania strony swapowej w kontekście bieżącej sesji, tak aby podmienić adres depozytowy i przekierować środki do portfeli atakującego.

W skrócie

  • Atak jest promowany masowo w komentarzach na Pastebin i kieruje na „dokumentację wycieku”/„metodę zysku”.
  • Ofiara trafia m.in. na dokument (Google Docs) opisujący rzekomy „profit method” dla Swapzone/ChangeNOW.
  • Instrukcja nakazuje wkleić do paska adresu kod uruchamiany przez schemat javascript:.
  • Wstrzyknięty, mocno zaciemniony skrypt ma nadpisywać elementy aplikacji webowej i podmieniać adresy BTC (oraz manipulować wartościami/ofertami), by wyglądało to jak działający „arbitraż”.
  • To rzadki (i ważny) zwrot: ClickFix użyty do modyfikacji działania strony w przeglądarce, a nie do uruchamiania poleceń systemowych.

Kontekst / historia / powiązania

ClickFix jest obserwowany co najmniej od 2024 roku jako rosnąca rodzina „ataków z instrukcją naprawy”, gdzie przestępcy podszywają się pod pomoc techniczną, weryfikację bezpieczeństwa, „fix” błędu w przeglądarce itp., a następnie każą ofierze wykonać komendy (np. PowerShell) lub kliknięcia, które same omijają część zabezpieczeń. Microsoft opisywał tę technikę jako świadome dołożenie interakcji użytkownika, aby wyślizgnąć się spod automatycznych detekcji.

Z kolei sektorowe ostrzeżenia (np. HC3) zwracały uwagę, że ClickFix bazuje na wiarygodnie wyglądających komunikatach i presji, by „szybko naprawić problem”, a skutkiem bywa uruchomienie szkodliwych skryptów/poleceń.

Nowość w kampanii z lutego 2026 polega na tym, że „fix” nie instaluje (bezpośrednio) złośliwego programu w systemie, tylko przestawia transakcję w webowym interfejsie w momencie wykonywania swapu.

Analiza techniczna / szczegóły luki

1) Wejście: komentarze Pastebin → link pośredni → dokument „instrukcja zysku”

Atakujący przeglądają wpisy na Pastebin i zostawiają komentarze promujące „wyciek” oraz obiecujące wysokie zyski (np. kilka/kilkanaście tysięcy USD w parę dni). Link prowadzi do hostingu z przekierowaniem, a dalej do dokumentu typu Google Docs podszywającego się pod poradnik wykorzystania rzekomego błędu w przepływie kursów między usługami (Swapzone/ChangeNOW).

2) Kluczowy trik: uruchomienie kodu przez javascript: w pasku adresu

„Poradnik” każe ofierze wkleić fragment kodu tak, aby został wykonany w kontekście aktualnie otwartej strony swapowej. Technicznie wykorzystuje to schemat javascript:, czyli mechanizm URIs, w którym „nawigacja” skutkuje wykonaniem kodu JavaScript. MDN wprost ostrzega, że używanie javascript: jest odradzane, bo może prowadzić do wykonania arbitralnego kodu.

3) Łańcuch ładunków: loader → obfuskowany payload → web-inject

Z obserwacji wynika, że pierwszy skrypt doładowuje kolejny etap (payload) i wstrzykuje go w stronę, „podmieniając” elementy odpowiedzialne za proces swapu (opisano m.in. nadpisanie legalnego komponentu aplikacji webowej). Następnie atak:

  • podmienia adres depozytowy BTC na jeden z adresów kontrolowanych przez napastnika (losowany z listy),
  • oraz modyfikuje wyświetlane wartości/oferty, by ofiara miała wrażenie, że „metoda” faktycznie daje przewagę kursową.

To ważny aspekt psychologiczny: nie tylko kradzież, ale też „scenografia” potwierdzająca skuteczność rzekomego arbitrażu.

4) Dlaczego to działa?

Bo użytkownik sam wykonuje kod w kontekście zaufanej domeny, w trakcie realnej sesji. W efekcie:

  • UI wygląda znajomo,
  • ofiara „widzi” swój swap,
  • a krytyczny element (adres depozytowy) jest już podmieniony.

Praktyczne konsekwencje / ryzyko

  • Nieodwracalność: transakcje BTC (i wielu innych kryptowalut) są w praktyce nieodwracalne – po wysłaniu środków na zły adres odzyskanie ich jest skrajnie trudne lub niemożliwe.
  • Ryzyko dla użytkowników i helpdesków: ofiara często zgłasza „bug w swapie” dopiero po fakcie – a problem nie leży po stronie giełdy, tylko w lokalnym web-inject’cie uruchomionym w przeglądarce.
  • Ryzyko dla firm: pracownicy wykonujący swapy z urządzeń służbowych (lub w środowiskach z danymi firmowymi) mogą dodatkowo narazić organizację na wtórne skutki (np. ekspozycję danych sesyjnych/przeglądarkowych, jeśli kampania ewoluuje).
  • Skalowalność: dystrybucja przez komentarze i dokumenty „poradnikowe” jest tania i masowa – a obietnica szybkiego zysku znacząco zwiększa konwersję.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników (SOC/IT może to komunikować jako „security advisory”)

  1. Nigdy nie uruchamiaj kodu w pasku adresu (ani javascript:, ani poleceń „do wklejenia”), nawet jeśli pochodzi z dokumentu „instruktażowego”.
  2. Jeśli korzystasz z agregatorów swapów: weryfikuj adres depozytowy „out-of-band” (np. porównanie z adresem w aplikacji portfela, skan QR z zaufanego źródła, whitelisty adresów).
  3. Traktuj jako czerwone flagi: „leak”, „exploit doc”, „profit method”, „arbitrage bug”, „13k w 2 dni”, „stary node/backend”.

Dla organizacji (polityki i detekcje)

  1. Edukacja pod ClickFix: krótkie szkolenia i komunikaty o schematach „naprawczych”, gdzie użytkownik jest proszony o wykonanie kroków/komend.
  2. Kontrola przeglądarek (MDM/Enterprise): rozważ hardening, rozszerzenia blokujące ryzykowne zachowania, monitorowanie nietypowych wzorców (np. anomalie w ruchu do hostów z surowym tekstem / krótkich redirectów w kontekście finansów).
  3. Procedura IR dla „crypto incidents”: gdy ktoś zgłosi błędny adres lub podejrzane zachowanie swapu – zbieraj artefakty (historia, rozszerzenia, logi przeglądarki, nagranie kroków), bo to może być web-inject uruchomiony lokalnie, a nie incydent po stronie dostawcy.

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

Klasyczne kampanie ClickFix zwykle kończą się uruchomieniem komend systemowych (PowerShell, skrypty), instalacją stealerów/RAT-ów itp. (to trend opisywany m.in. przez Microsoft oraz Unit 42).
W opisywanym incydencie punkt ciężkości przesunął się w stronę „webowego przejęcia transakcji”: zamiast infekować system, atakujący „podmienia” krytyczne dane w przeglądarce podczas operacji finansowej.

To istotna ewolucja: detekcje endpointowe mogą nie zobaczyć klasycznego droppera, a mimo to dochodzi do straty środków.

Podsumowanie / kluczowe wnioski

  • Kampania z 15 lutego 2026 pokazuje, że komentarze na platformach typu Pastebin mogą pełnić rolę skutecznego kanału dystrybucji socjotechniki.
  • ClickFix dojrzewa: coraz częściej nie „łamie” technologii, tylko łamie proces decyzyjny użytkownika.
  • Wariant z javascript: jest szczególnie groźny dla krypto, bo umożliwia manipulację w ramach zaufanej sesji i podmianę adresów depozytowych bez „klasycznej infekcji”.
  • Najskuteczniejsze zabezpieczenie to połączenie: twardych zasad (nie uruchamiamy kodu z poradników) + weryfikacji adresu przed wysyłką + świadomości ClickFix.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii „Pastebin comments push ClickFix JavaScript attack to hijack crypto swaps” (15.02.2026). (BleepingComputer)
  2. Microsoft Security Blog – analiza techniki ClickFix (21.08.2025). (microsoft.com)
  3. HHS HC3 – „ClickFix Attacks” (Sector Alert, 29.10.2024). (HHS.gov)
  4. Palo Alto Networks Unit 42 – materiał o rosnących kampaniach ClickFix (10.07.2025). (Unit 42)
  5. MDN (Mozilla) – dokumentacja schematu javascript: i ryzyk bezpieczeństwa (01.07.2025). (developer.mozilla.org)

Nowy wariant ClickFix: nslookup i DNS jako kanał dostarczania ładunku PowerShell (ModeloRAT)

Wprowadzenie do problemu / definicja luki

ClickFix to technika socjotechniczna, w której ofiara — „naprawiając problem” (fałszywy błąd, weryfikację CAPTCHA, rzekomą aktualizację) — sama uruchamia polecenia prowadzące do infekcji. Nowość w opisywanej kampanii polega na tym, że kolejne etapy nie są pobierane klasycznym HTTP/HTTPS, lecz… przez DNS, z użyciem wbudowanego narzędzia nslookup.

W skrócie

  • Atakujący nakłaniają użytkownika do uruchomienia komendy w oknie Windows Run.
  • Komenda wykonuje niestandardowe zapytanie DNS do kontrolowanego przez napastnika serwera DNS i parsuje pole „Name:” z odpowiedzi, by uzyskać kolejny ładunek (PowerShell), który jest następnie wykonywany.
  • Łańcuch infekcji prowadzi finalnie do instalacji ModeloRAT (RAT napisany w Pythonie), z mechanizmami rozpoznania i utrzymania się w systemie.

Kontekst / historia / powiązania

ClickFix nie jest „jedną rodziną malware”, tylko powtarzalnym wzorcem nadużycia interakcji użytkownika: ofiara uruchamia polecenie, bo wierzy, że to element weryfikacji lub naprawy. Microsoft i inni dostawcy opisywali już wcześniej ClickFix jako łańcuch, który często kończy się infostealerami, RAT-ami lub loaderami i chętnie korzysta z LOLBins (np. PowerShell) w modelu „fileless”.

Proofpoint pokazywał, że ClickFix szybko rozlał się po ekosystemie zagrożeń (różni aktorzy, różne przynęty, wspólny mechanizm „skopiuj-wklej-uruchom”), a kampanie kończyły się m.in. AsyncRAT, DarkGate, Lumma Stealer czy NetSupport.

Analiza techniczna / szczegóły luki

1) „Dostarczenie” polecenia i uruchomienie nslookup

W opisywanym wariancie użytkownik dostaje instrukcję uruchomienia polecenia w Windows Run. Polecenie uruchamia nslookup tak, aby zapytać konkretny, zewnętrzny serwer DNS (zamiast systemowego resolvera). W materiale wskazano przykład infrastruktury DNS napastnika (adres IP serwera DNS) oraz mechanikę: odpowiedź DNS jest „spreparowana” tak, by zawierała kolejny etap w polu NAME:.

2) DNS jako „lekki staging”

Kluczowe jest to, że DNS służy tu jako kanał etapowania: ofiara najpierw wykonuje zapytanie DNS, a dopiero potem system uruchamia PowerShell pozyskany z odpowiedzi. To utrudnia pracę obronie opartej wyłącznie o filtrowanie web/URL i proxy HTTP.

3) Kolejne etapy: ZIP → Python → VBS → ModeloRAT

W dalszej części łańcucha (wg opisu bazującego na obserwacjach Microsoft) następuje pobranie archiwum ZIP z zewnętrznej infrastruktury, uruchomienie skryptu w Pythonie (rekonesans, discovery), a następnie zrzut/uruchomienie VBScript i finalnie ModeloRAT zapewniający zdalną kontrolę.

4) Co tu jest sprytne z perspektywy detekcji?

DNS zwykle jest dozwolony w egress, a nslookup.exe to narzędzie administracyjne. To tworzy „szarą strefę” — aktywność może wyglądać jak troubleshooting, dopóki nie spojrzymy na kontekst procesu (np. cmd.exe/Run → nslookup.exe → uruchomienie poleceń/PowerShell) i cechy zapytań (nietypowy serwer, nietypowe typy odpowiedzi, podejrzane payloady w danych odpowiedzi).

Praktyczne konsekwencje / ryzyko

  • Zwiększona szansa obejścia kontroli webowych: jeśli organizacja mocno filtruje HTTP/HTTPS, a DNS traktuje „po macoszemu”, kanał DNS może stać się skutecznym stagingiem.
  • RAT w sieci = ryzyko pełnej kompromitacji: ModeloRAT jako narzędzie zdalnego dostępu może posłużyć do kradzieży danych, rozpoznania, ruchu bocznego i dalszego dropowania ładunków.
  • Trudniejsze dochodzenie: część „pobrania” dzieje się w DNS, więc bez logów DNS (i korelacji z endpointem) analiza incydentu jest istotnie utrudniona.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (0–72h)

  1. Wymuś DNS tylko przez zaufane resolvery
    • Blokuj bezpośredni DNS (UDP/TCP 53) do Internetu z sieci użytkowników, jeśli możesz; pozwól tylko na DNS do twoich resolverów / zabezpieczonego forwardera.
  2. Wykrywanie nslookup z parametrem serwera / nietypowym wzorcem użycia
    • Alarmuj na nslookup.exe wywołany przez cmd.exe/explorer.exe w kontekście Run + szybkie następstwo uruchomienia PowerShell.
    • Skorzystaj z gotowych reguł detekcji pod nadużycia DNS/nslookup (np. podejrzanie częste wywołania).
  3. Zbieraj i koreluj logi DNS + EDR
    • Bez telemetrii DNS możesz nie zobaczyć kluczowego elementu stagingu.

Wzmocnienie średnioterminowe (1–4 tygodnie)

  1. Ogranicz PowerShell tam, gdzie się da
    • Constrained Language Mode / polityki aplikacyjne (AppLocker/WDAC), ASR rules, wzmacnianie AMSI/Defender w środowiskach Windows — ClickFix często kończy się PowerShellem.
  2. Szkolenia i „bezpieczniki” UX
    • W ClickFix „security boundary” jest użytkownik. Ucz: „nie uruchamiam poleceń z okienek ‘naprawczych’, CAPTCHA i pseudo-aktualizacji”.

Różnice / porównania z innymi przypadkami

  • Klasyczne ClickFix: często kończy się poleceniem PowerShell, które pobiera payload po HTTP/HTTPS.
  • Ten wariant: DNS jest użyty jako kanał etapowania/„sygnalizacji” — a nslookup staje się narzędziem do pobrania kolejnego polecenia z odpowiedzi DNS. To zmienia priorytety obrony: same kontrole webowe nie wystarczą, jeśli DNS nie jest monitorowany i ograniczany.

Podsumowanie / kluczowe wnioski

  • ClickFix dalej ewoluuje: teraz nie tylko „uruchom PowerShell”, ale też „uruchom nslookup na zewnętrzny DNS i wykonaj to, co wróci”.
  • DNS jako staging jest groźny, bo zwykle jest dozwolony i słabiej inspekcjonowany.
  • Obrona wymaga połączenia: kontrola egress DNS + telemetria DNS + EDR na endpointach + edukacja użytkowników.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii DNS/nslookup i mechaniki „Name:” → PowerShell (BleepingComputer)
  2. Malwarebytes – omówienie łańcucha ZIP → Python → VBS → ModeloRAT (Malwarebytes)
  3. Microsoft Security Blog – tło i typowy łańcuch ClickFix (microsoft.com)
  4. Proofpoint – szerszy kontekst rozprzestrzenienia ClickFix i typowe przynęty/payloady (Proofpoint)
  5. Elastic – referencje i podejście detekcyjne dla nadużyć DNS/nslookup (Elastic)

Jeden aktor odpowiada za 83% aktywnych ataków RCE na Ivanti EPMM (CVE-2026-1281, CVE-2026-1340)

Wprowadzenie do problemu / definicja luki

Na przełomie końca stycznia i pierwszej połowy lutego 2026 r. obserwujemy szybkie „uzbrojenie” (weaponization) dwóch krytycznych podatności pre-auth w Ivanti Endpoint Manager Mobile (EPMM) — CVE-2026-1281 i CVE-2026-1340. Obie umożliwiają nieautoryzowane zdalne wykonanie kodu (RCE), czyli przejęcie serwera MDM/UEM bez loginu i hasła.

Najbardziej niepokojący jest jednak wątek operacyjny: telemetria GreyNoise wskazuje, że dominująca część prób eksploatacji (83%) pochodzi z jednego adresu IP ulokowanego na infrastrukturze określanej jako bulletproof hosting.

W skrócie

  • Podatności: CVE-2026-1281 oraz CVE-2026-1340 (obie oceniane jako krytyczne; CVSS 9.8).
  • Skala i koncentracja źródła ataków: 417 sesji eksploatacyjnych w dniach 1–9 lutego 2026, z czego 83% z jednego IP 193.24.123[.]42 (PROSPERO OOO / AS200593).
  • Sygnał „brokerów dostępu” (IAB): 85% sesji używało OAST/DNS callback do weryfikacji RCE bez natychmiastowego wdrażania malware — typowe „sprawdzam i kataloguję cele”.
  • Ryzyko biznesowe: kompromitacja EPMM = dostęp do danych administracyjnych, informacji o urządzeniach mobilnych oraz potencjalna możliwość zmian konfiguracyjnych, co przekłada się na ryzyko przejęcia floty urządzeń.

Kontekst / historia / powiązania

Ivanti EPMM to centralny komponent zarządzania urządzeniami mobilnymi (MDM/UEM). Jeśli stoi publicznie w Internecie, jest to cel „wysokiej dźwigni”: jeden udany pre-auth RCE może otworzyć drogę do dalszych działań w organizacji.

W analizowanym przypadku istotne są dwie obserwacje:

  1. Tempo eskalacji po ujawnieniu: GreyNoise wskazuje, że pierwsze próby eksploatacji widziało już 1 lutego 2026, czyli kilka dni po publikacji informacji o luce, a 8 lutego nastąpił wyraźny pik aktywności (269 sesji jednego dnia).
  2. Konsolidacja infrastruktury ofensywnej: pojedynczy host nie tylko atakował Ivanti, ale równolegle „mielił” wiele CVE w różnych produktach, co jest charakterystyczne dla automatyzacji (skan + exploit + walidacja).

Analiza techniczna / szczegóły luki

Co wiemy o CVE-2026-1281 (i relacji do CVE-2026-1340)

  • NVD opisuje CVE-2026-1281 jako code injection prowadzące do nieautoryzowanego RCE.
  • CERT-EU potwierdza, że obie podatności dotyczą Ivanti EPMM i pozwalają na pre-auth RCE, a trwała poprawka ma trafić do EPMM 12.8.0.0 (Q1 2026).

Mechanika exploita i „dlaczego Bash ma tu znaczenie”

watchTowr (analiza techniczna) wskazuje na ciekawy trop: dostarczone przez Ivanti tymczasowe hotfixy (RPM) podmieniają logikę mapowania URL-i w Apache RewriteMap — z powłokowych skryptów Bash na klasy Java. To silnie sugeruje, że krytyczny błąd siedział w ścieżce, gdzie atakujący mógł przekazać kontrolowane dane do Basha przez HTTP.

W praktyce exploitowalne żądania dotyczą specyficznych endpointów pod /mifs/… (np. związanych z dystrybucją aplikacji „in-house”), gdzie parametry z URL/Host trafiają do mechanizmu mapowania. watchTowr opisuje, że finalny wektor wykorzystuje Bash arithmetic expansion (wstrzyknięcie prowadzące do wykonania poleceń).

Telemetria ataków: jeden adres dominuje, a „poc” to nie koniec historii

GreyNoise policzył w dniach 1–9 lutego 2026 417 sesji eksploatacyjnych z 8 IP, ale 346 sesji (83%) pochodziło z 193.24.123[.]42 (PROSPERO OOO / AS200593).
Co ważne, 85% sesji kończyło się DNS callback (OAST) — potwierdzeniem, że payload wykonał się po stronie ofiary, bez natychmiastowej instalacji malware. To często oznacza etap „selekcji i przygotowania dostępu”.

BleepingComputer podkreśla dodatkowo, że część obrony oparta wyłącznie o „opublikowane IOC” może nie wystarczyć, bo dominujący adres nie musiał znaleźć się na popularnych listach.

Praktyczne konsekwencje / ryzyko

Skuteczna kompromitacja EPMM może mieć konsekwencje wykraczające poza sam serwer:

  • Dostęp do danych: konta administratorów/użytkowników, e-maile, atrybuty urządzeń (numery, IP, zainstalowane aplikacje, identyfikatory typu IMEI/MAC).
  • Ryzyko nadużyć operacyjnych: możliwość zmian w konfiguracji zarządzanych urządzeń (w tym ustawień uwierzytelniania), co sprzyja trwałemu przejęciu środowiska mobilnego.
  • Cichy etap „stagingu”: OAST/DNS callback i wzmianki o „sleeper shell” w ścieżce /mifs/403.jsp sugerują scenariusz, w którym system wygląda na „spokojny”, a jednak jest już przygotowany do kolejnego kroku.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast zastosuj hotfix (RPM) zgodnie z wytycznymi producenta / CERT-EU
    CERT-EU wprost rekomenduje wdrożenie hotfixów RPM 12.x.0 lub 12.x.1 dla podatnych wersji oraz pamiętanie, że hotfix nie przetrwa upgrade’u i trzeba go ponownie zastosować.
  2. Potraktuj każde publicznie wystawione EPMM jako potencjalnie naruszone (jeśli było niezałatane po 29 stycznia 2026)
    GreyNoise pokazał, że exploity „ruszyły” błyskawicznie po ujawnieniu, z istotnym pikiem 8 lutego.
  3. Polowanie na ślady eksploatacji w logach HTTP i endpointach /mifs/…
    Ivanti (cytowane przez BleepingComputer) wskazywało, że próby mogą pojawiać się w Apache access log (m.in. /var/log/httpd/https-access_log) i dotyczyć ścieżek związanych z dystrybucją aplikacji.
  4. Przegląd DNS pod kątem OAST (wysoko-entropijne subdomeny / nietypowe callbacki)
    Skoro 85% obserwacji to DNS callback w celu weryfikacji RCE, logi DNS/proxy mogą być jednym z najlepszych „czujników” potwierdzających wykonanie payloadu.
  5. Zablokuj/ogranicz infrastrukturę źródłową tam, gdzie ma to sens (AS-level)
    GreyNoise rekomenduje blokowanie AS200593 (PROSPERO OOO) na brzegu sieci, bo to tam koncentrowała się dominująca aktyność.
  6. Przygotuj plan trwałej aktualizacji do EPMM 12.8.0.0 oraz ewentualnej odbudowy instancji
    Zarówno CERT-EU, jak i BleepingComputer podkreślają, że trwała naprawa ma być dopiero w 12.8.0.0 (Q1 2026), a podejście „najbardziej konserwatywne” może oznaczać rebuild i migrację.

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

To zdarzenie wyróżniają trzy elementy, które nie zawsze występują jednocześnie:

  • Silna koncentracja źródła (83% z jednego IP) zamiast „rozproszonego botnetu”.
  • Weryfikacja exploita przez OAST/DNS (często „IAB-style”), czyli najpierw potwierdzenie podatności i możliwość powrotu później.
  • Hotfix jako zmiana architektury ścieżki wykonania (Bash → Java w RewriteMap), co sugeruje, że luka była „głęboko” w przepływie requestów HTP.

Podsumowanie / kluczowe wnioski

  • CVE-2026-1281 i CVE-2026-1340 to krytyczne, pre-auth podatności RCE w Ivanti EPMM, a exploitacja w realu była potwierdzana jako co najmniej „limitowana” u ofiar.
  • W telemetrii GreyNoise 83% aktywności przypisano do jednego IP na infrastrukturze bulletproof (PROSPERO/AS200593), a dominującą taktyką była walidacja przez DNS callback (OAST).
  • Operacyjnie: łatka + dochodzenie (logi HTTP/DNS, ślady /mifs/…, poszukiwanie „sleeper shell”) powinny iść równolegle — szczególnie jeśli EPMM był wystawiony do Internetu.

Źródła / bibliografia

  1. BleepingComputer — „One threat actor responsible for 83% of recent Ivanti RCE attacks” (14.02.2026). (BleepingComputer)
  2. GreyNoise — „Active Ivanti Exploitation Traced to Single Bulletproof IP…” (luty 2026). (GreyNoise)
  3. watchTowr Labs — analiza techniczna CVE-2026-1281/CVE-2026-1340 (30.01.2026). (watchTowr Labs)
  4. CERT-EU — „Security Advisory 2026-001: Critical vulnerabilities in Ivanti EPMM” (30.01.2026). (cow-prod-www-v3.azurewebsites.net)
  5. NVD (NIST) — karta CVE-2026-1281 (publikacja 29.01.2026, KEV/due date 01.02.2026 widoczne w wpisie). (nvd.nist.gov)

Listy z „działu bezpieczeństwa” w skrzynce? Nowa fala phishingu pocztą tradycyjną uderza w użytkowników Trezor i Ledger

Wprowadzenie do problemu / definicja luki

To nie jest „luka” w sprzętowych portfelach, tylko klasyczna kradzież poprzez socjotechnikę – w tym przypadku w nietypowym kanale: pocztą tradycyjną (snail mail). Atakujący wysyłają fizyczne listy podszywające się pod komunikaty działów „security/compliance” Trezor i Ledger. W liście znajduje się QR kod prowadzący do strony phishingowej, która finalnie prosi o seed phrase / recovery phrase (12/24 słowa). Kto ją pozna – przejmuje środki.

W skrócie

  • List sugeruje pilne działanie (np. „Authentication Check” lub „Transaction Check”), grożąc ograniczeniem działania aplikacji/urządzenia, jeśli użytkownik nie wykona kroku do wskazanego terminu.
  • QR prowadzi na domeny podszywające się pod konfigurator Trezor/Ledger; przynajmniej jedna kampania zbierała frazy odzyskiwania i wysyłała je do backendowego endpointu API.
  • Trezor i Ledger wprost podkreślają, że nie proszą o seed phrase, nie „dezaktywują” urządzeń, a kontakt inicjowany przez „list/telefon/komunikator” należy traktować jako phishing.

Kontekst / historia / powiązania

Ten typ ataku żeruje na dwóch zjawiskach:

  1. Dane adresowe w obiegu – branża krypto ma historię incydentów, po których dane kontaktowe klientów krążyły w sieci. BleepingComputer zwraca uwagę, że zarówno Trezor, jak i Ledger w przeszłości doświadczyły naruszeń, które mogły ujawnić informacje kontaktowe.
  2. Ewolucja phishingu „na seed phrase” – nie chodzi już tylko o link w mailu. Kampanie potrafią:
  • wykorzystywać masową dystrybucję przez przejęte konta w narzędziach marketingowych/CRM,
  • podsuwać ofierze „gotową” frazę (tzw. PoisonSeed), aby przejąć środki po utworzeniu portfela z użyciem tej frazy.

Snail mail to kolejny krok: mniej filtrów antyspamowych, większe „wrażenie oficjalności” i element zaskoczenia.

Analiza techniczna / szczegóły luki

1) Łańcuch ataku (kill chain)

  1. Dostarczenie: fizyczny list na papierze firmowym udającym Trezor/Ledger.
  2. Uwiarygodnienie i presja czasu: komunikat o obowiązkowym mechanizmie („Authentication Check”, „Transaction Check”) i terminie granicznym (np. Trezor: 15 lutego 2026).
  3. Przekierowanie kanału: QR kod → strona podszywająca się pod proces konfiguracji.
  4. Eksfiltracja sekretu: formularz do wpisania 12/20/24 słów; w opisywanym przypadku fraza była wysyłana do endpointu API na serwerze atakującego.
  5. Monetyzacja: import portfela przez atakującego i transfer środków (sam seed phrase jest „kluczem głównym”).

2) Dlaczego to działa (nawet na bardziej świadomych użytkowników)

  • Kanał „offline” obniża czujność: użytkownicy kojarzą phishing głównie z e-mailem/SMS.
  • Narracja o „weryfikacji” pasuje do trendu KYC/AML i compliance – brzmi wiarygodnie.
  • Wymuszenie terminu redukuje czas na weryfikację domeny i źródła.

3) Najważniejsza obserwacja operacyjna

To nie jest „update firmware” ani „synchronizacja urządzenia” – żadna legalna procedura nie wymaga podania seed phrase na stronie. Ledger wręcz opisuje scenariusze, w których oszuści proszą o wpisanie 24 słów (także w kontekście fizycznych listów).

Praktyczne konsekwencje / ryzyko

  • Ryzyko krytyczne (C): ujawnienie seed phrase = natychmiastowa utrata kontroli nad środkami; w praktyce często nieodwracalna (transakcje w blockchainie są finalne).
  • Ryzyko dla firm: pracownicy z ekspozycją na krypto (inwestycje, treasury, eksperymenty Web3) mogą wprowadzić frazę na służbowym urządzeniu → kompromitacja środowiska (dodatkowe malware/infostealer w innych kampaniach). Jako kontekst: opisywano także fałszywe aplikacje podszywające się pod Ledger Live, które wymuszają wpisanie seed phrase.
  • Ryzyko wtórne: jeśli atakujący ma adres domowy i wie, że ofiara korzysta z hardware walleta, rośnie ryzyko dalszego ukierunkowania (kolejne listy, telefony, „support”).

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników (checklista)

  1. Nigdy nie podawaj seed phrase: nie wpisuj jej na stronie, nie wysyłaj, nie skanuj, nie fotografuj. Trezor i Ledger mówią wprost: firma nie będzie o to prosić.
  2. Traktuj list jako phishing (nawet jeśli wygląda „idealnie”): Trezor zaleca uznawać kontakt z „poczty tradycyjnej” jako podejrzany, jeśli jest inicjowany do Ciebie.
  3. Nie skanuj QR kodu z listu. Jeśli chcesz coś sprawdzić – wpisz ręcznie znany, zapisany (bookmark) adres (np. oficjalne strony producenta) lub użyj aplikacji, której źródło instalacji jest pewne.
  4. Jeśli już wpisałeś seed phrase: traktuj portfel jako przechwycony – przenieś środki na nowy portfel z nową frazą (generowaną na urządzeniu), a stary uznaj za spalony. (Czas ma znaczenie).

Dla zespołów bezpieczeństwa (SOC / SecOps)

  • Dodaj playbook „crypto-seed-phishing” do obsługi zgłoszeń użytkowników (także w kanale fizycznym).
  • Edukuj: „Ledger/Trezor nie dezaktywuje urządzeń”, „seed phrase tylko w urządzeniu”, „QR z listu = wysokie ryzyko”.
  • Monitoruj domeny podobne (typosquatting) i zgłoszenia brand abuse; Ledger podaje przykłady „podobnych domen” i zasad weryfikacji kanałów.

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

  • Snail mail vs e-mail: e-mail częściej wpada w filtry i jest łatwiejszy do zablokowania na bramie; list fizyczny omija zabezpieczenia techniczne i uderza w procesy/świadomość użytkownika.
  • Phishing „podaj swoją frazę” vs PoisonSeed: w klasycznym scenariuszu ofiara wpisuje własną frazę na fałszywej stronie (przejęcie natychmiast). W PoisonSeed ofiara dostaje frazę od atakującego i używa jej do utworzenia portfela – efekt końcowy podobny: atakujący zna klucz.
  • Fałszywe strony vs fałszywe aplikacje: część kampanii idzie w malware i podstawianie aplikacji (np. fałszywy Ledger Live), ale mechanika końcowa nadal kręci się wokół wymuszenia seed phrase.

Podsumowanie / kluczowe wnioski

  • To nie awaria Trezor/Ledger, tylko atak na użytkownika, który ma doprowadzić do ujawnienia recovery phrase.
  • „Papierowy list” staje się kolejnym kanałem phishingu – mniej spodziewanym, przez co skuteczniejszym.
  • Jedna zasada chroni przed większością tych scenariuszy: seed phrase nigdy nie opuszcza Twojej kontroli i nigdy nie trafia na stronę/aplikację „na żądanie” – niezależnie od tego, jak pilnie brzmi komunikat.

Źródła / bibliografia

  1. BleepingComputer – „Snail mail letters target Trezor and Ledger users in crypto-theft attacks” (BleepingComputer)
  2. Trezor – „Common scams and phishing affecting Trezor users” (trezor.io)
  3. Ledger – „Ongoing phishing campaigns” (w tym sekcja o listach fizycznych i zasadach weryfikacji) (Ledger)
  4. SecurityWeek – „CRM, Bulk Email Providers Targeted in Crypto Phishing Campaign” (PoisonSeed) (SecurityWeek)
  5. TechRadar – „Mac users beware – fake Ledger apps…” (fałszywe aplikacje wymuszające seed phrase) (TechRadar)