Archiwa: Windows - Strona 25 z 68 - Security Bez Tabu

Tag: Windows

Masowa kampania malware na GitHubie rozprzestrzenia BoryptGrab Stealer

Cybersecurity news

Wprowadzenie do problemu

BoryptGrab to nowo zidentyfikowany stealer dla systemów Windows, wykorzystywany w szeroko zakrojonej kampanii dystrybucyjnej opartej na publicznych repozytoriach GitHub. Zagrożenie podszywa się pod darmowe narzędzia, cheaty do gier i popularne utility, a jego celem jest kradzież danych z przeglądarek, portfeli kryptowalutowych, komunikatorów oraz plików użytkownika.

Kampania pokazuje, że zaufanie do rozpoznawalnych platform developerskich coraz częściej staje się elementem łańcucha infekcji. Sama obecność projektu w publicznym repozytorium nie oznacza już, że pobierane pliki są bezpieczne.

W skrócie

  • Badacze wykryli ponad 100 repozytoriów GitHub używanych do dystrybucji BoryptGrab.
  • Atakujący stosowali techniki SEO, aby złośliwe projekty pojawiały się wysoko w wynikach wyszukiwania.
  • Ofiary były kierowane do fałszywych stron pobierania, z których pobierały archiwa ZIP z loaderem i kolejnymi komponentami malware.
  • BoryptGrab wykrada hasła, dane przeglądarek, informacje o systemie, dane z portfeli kryptowalutowych, pliki Telegrama oraz tokeny Discorda.
  • W części przypadków infekcja była rozszerzana o backdoora TunnesshClient, umożliwiającego zdalny dostęp i tunelowanie ruchu.

Kontekst i historia

Opisana kampania nie przypomina klasycznego phishingu opartego wyłącznie na wiadomościach e-mail. Zamiast tego operatorzy nadużywali ekosystemu open source oraz mechanizmów wyszukiwania, tworząc repozytoria udające legalne projekty oferujące darmowe wersje znanych aplikacji lub narzędzi.

W plikach README umieszczano frazy związane z popularnymi wyszukiwaniami, aby zwiększyć widoczność w wynikach i przechwytywać ruch użytkowników szukających cracks, cheatów, modów czy „premium tools”. To połączenie socjotechniki i manipulacji wyszukiwarkami znacząco zwiększało skuteczność kampanii.

Istotnym elementem operacji była także infrastruktura pośrednia. Ofiara po wejściu na stronę projektu trafiała na fałszywą stronę pobierania przypominającą standardową zawartość hostowaną w GitHub Pages, a następnie pobierała archiwum ZIP o nazwie sugerującej legalne oprogramowanie.

Analiza techniczna

Łańcuch infekcji rozpoczynał się od pobrania archiwum ZIP. W jednej z głównych ścieżek wykonania użytkownik uruchamiał plik wykonywalny wykorzystujący technikę DLL side-loading. Legalnie wyglądający program ładował złośliwą bibliotekę libcurl.dll, która odszyfrowywała ukryty payload launchera z sekcji zasobów.

Do ochrony komponentów stosowano między innymi XOR oraz AES w trybie CBC, co utrudniało statyczną analizę próbek. Launcher pobierał następnie właściwy moduł BoryptGrab oraz dodatkowe komponenty zależnie od wariantu kampanii.

Wśród obserwowanych ładunków znajdowały się również warianty Vidar, downloader HeaconLoad oraz backdoor TunnesshClient. Poszczególne buildy używały nazw takich jak Shrek, Leon, CryptoByte czy Sonic, co mogło służyć operatorom do śledzenia źródeł ruchu lub wersji kampanii.

Alternatywna ścieżka infekcji opierała się na skryptach VBS ukrywających polecenia w tablicach liczb całkowitych. Po dekodowaniu uruchamiany był PowerShell odpowiedzialny za pobranie kolejnego etapu z serwera atakującego. W części przypadków skrypty próbowały także dodawać wyjątki do Microsoft Defender.

Sam BoryptGrab zawierał mechanizmy anti-analysis. Malware sprawdzał obecność środowisk wirtualnych, analizował aktywne procesy i podejmował próbę uruchomienia z podwyższonymi uprawnieniami, aby utrudnić wykrycie przez sandboxy i zespoły analityczne.

Zakres kradzionych danych był szeroki. BoryptGrab zbierał dane z wielu przeglądarek, w tym Chrome, Edge, Firefox, Opera, Brave, Vivaldi i Yandex Browser. Szczególnie istotne było wykorzystanie technik obchodzenia ochrony Chrome App-Bound Encryption oraz dodatkowego komponentu do ekstrakcji danych z przeglądarek opartych na Chromium.

Poza danymi przeglądarek zagrożenie celowało w portfele kryptowalutowe, takie jak Exodus, Electrum, Ledger Live, Atomic, Binance, Wasabi czy Trezor. Malware wykonywał również zrzuty ekranu, zbierał informacje systemowe, katalogował zainstalowane aplikacje i uruchamiał moduł file grabber do wykradania plików o określonych rozszerzeniach z popularnych lokalizacji użytkownika.

W nowszych wariantach obserwowano także kradzież danych z Telegrama i tokenów Discorda. Zebrane informacje były kompresowane i wysyłane do serwera C2. Dodatkowy komponent TunnesshClient znacząco zwiększał możliwości atakującego po infekcji, umożliwiając tunel SSH, działanie jako proxy SOCKS5 oraz zdalne wykonywanie poleceń.

Konsekwencje i ryzyko

Najbardziej oczywistym skutkiem infekcji jest kradzież danych uwierzytelniających i przejęcie kont użytkownika. Dotyczy to nie tylko kont webowych zapisanych w przeglądarkach, ale również portfeli kryptowalutowych, komunikatorów i usług społecznościowych.

W środowiskach firmowych ryzyko obejmuje przejęcie sesji, wtórną eskalację uprawnień oraz dostęp do skrzynek pocztowych, narzędzi SaaS i paneli administracyjnych. Jeśli na stacji uruchomiony zostanie również TunnesshClient lub inny dodatkowy komponent, incydent może szybko przerodzić się z kradzieży danych w pełną kompromitację hosta.

Kampania ma również szersze znaczenie dla bezpieczeństwa łańcucha dostaw i higieny korzystania z repozytoriów publicznych. Pokazuje bowiem, że zaufanie do platformy hostującej projekt nie może zastępować weryfikacji bezpieczeństwa samego oprogramowania.

Rekomendacje

Organizacje powinny ograniczyć możliwość pobierania i uruchamiania niezweryfikowanych narzędzi z publicznych repozytoriów, szczególnie z kategorii cheatów, cracks i „premium unlockers”. W praktyce warto stosować kontrolę aplikacji, filtrowanie pobrań, blokowanie wykonywania plików z katalogów tymczasowych oraz zasady allowlistingu.

Z perspektywy detekcji należy monitorować następujące symptomy:

  • nietypowe pobrania archiwów ZIP z projektów podszywających się pod popularne narzędzia,
  • uruchamianie procesów z techniką DLL side-loading,
  • tworzenie zadań harmonogramu i wpisów autostartu bez uzasadnienia biznesowego,
  • użycie PowerShell i VBS do pobierania kolejnych payloadów,
  • nietypowe połączenia HTTP/HTTPS do infrastruktury pobierającej dodatkowe moduły,
  • aktywność wskazującą na ekstrakcję danych z przeglądarek i portfeli kryptowalutowych,
  • próby tworzenia tuneli SSH lub ruch proxy z hostów użytkowników.

Zespoły SOC powinny uzupełnić reguły o detekcję procesów potomnych uruchamianych przez rzekome instalatory narzędzi użytkowych, anomalii w pracy przeglądarek oraz działań związanych z odczytem baz haseł i tokenów. Warto także korelować zdarzenia związane z modyfikacją ustawień Microsoft Defender.

Po stronie użytkownika końcowego kluczowe jest unikanie pobierania „darmowych” wersji płatnych aplikacji, weryfikacja historii repozytorium, commitów i autorów oraz ostrożność wobec stron pobierania generowanych poza oficjalnym kanałem producenta. W przypadku podejrzenia infekcji należy natychmiast odizolować host, zresetować hasła, unieważnić aktywne sesje i przeprowadzić pełne dochodzenie powłamaniowe.

Podsumowanie

BoryptGrab to przykład nowoczesnej kampanii malware, która łączy skuteczną socjotechnikę, nadużycie zaufanej platformy, wieloetapowy łańcuch infekcji i rozbudowane możliwości kradzieży danych. Skala operacji oraz wykorzystanie dodatkowych komponentów, takich jak TunnesshClient, wskazują na aktywne i dobrze zorganizowane zagrożenie.

Dla obrońców najważniejszy wniosek jest prosty: rozpoznawalna platforma hostująca kod nie jest gwarancją bezpieczeństwa. Każde pobierane narzędzie powinno być traktowane jak potencjalny wektor ataku i podlegać weryfikacji przed uruchomieniem.

Źródła

  1. Security Affairs — https://securityaffairs.com/189110/malware/massive-github-malware-operation-spreads-boryptgrab-stealer.html
  2. Trend Micro Research — New BoryptGrab Stealer Targets Windows Users via Deceptive GitHub Pages — https://www.trendmicro.com/en_us/research/26/c/boryptgrab-stealer-targets-users-via-deceptive-github-pages.html

Ponad 100 repozytoriów na GitHubie rozprowadza BoryptGrab – stealer z modułem reverse SSH (TunnesshClient)

Wprowadzenie do problemu / definicja luki

Kampania opisana przez Trend Micro pokazuje, jak łatwo przestępcy potrafią „zmonetyzować zaufanie” do popularnych platform deweloperskich: tworzą dziesiątki (a tu: ponad 100) publicznych repozytoriów na GitHubie, pozycjonują je pod frazy „darmowych narzędzi”, a następnie podsuwają ofierze trojanizowane archiwa ZIP. Efektem jest infekcja systemu Windows stealerem BoryptGrab, który kradnie dane z przeglądarek i portfeli kryptowalutowych, a w części wariantów dołącza backdoora TunnesshClient zestawiającego reverse SSH tunnel.

To nie jest „luka” w GitHubie jako podatność – to nadużycie ekosystemu (open-source/hosting kodu) + SEO poisoning + socjotechnika.

W skrócie

  • Wektor wejścia: fałszywe repozytoria i strony pobrań, podszywające się pod legalne narzędzia; pobranie ZIP rozpoczyna łańcuch infekcji.
  • Cel: kradzież danych z przeglądarek (m.in. hasła), tokenów (np. Discord), plików, danych portfeli krypto oraz informacji systemowych.
  • Technika: wiele wariantów i ścieżek uruchomienia (m.in. DLL sideloading, VBS, komponenty .NET, downloader w Go).
  • Backdoor: TunnesshClient (PyInstaller) używa reverse SSH i potrafi działać jak SOCKS5 proxy oraz wykonywać polecenia/transfer plików.

Kontekst / historia / powiązania

Trend Micro wskazuje, że część próbek/etapów łańcucha ma rosyjskojęzyczne komentarze i logi, a niektóre powiązane adresy IP są zlokalizowane w Rosji, co może sugerować pochodzenie operatorów (ostrożnie: to poszlaki, nie dowód).
Dodatkowo w kampanii obserwowano dostarczanie wariantów znanego stealera Vidar (z obfuskacją), co sugeruje podejście „modułowe”: jeden ekosystem dystrybucji, wiele możliwych ładunków.

Analiza techniczna / szczegóły luki

1) Dystrybucja: „SEO-boosted GitHub”

Repozytoria wyglądają wiarygodnie (README z frazami SEO), by wyświetlać się wysoko w wyszukiwarce obok legalnych wyników. Ofiara trafia na stronę pobrania i ściąga ZIP inicjujący infekcję.

2) Różne ścieżki wykonania (multi-variant)

SecurityWeek streszcza ustalenia Trend Micro: w zależności od paczki widziano m.in.:

  • DLL sideloading (wykorzystanie legalnie wyglądającego EXE z archiwum),
  • skrypty VBS pobierające launcher,
  • wykonanie przez .NET,
  • downloader w Golang (HeaconLoad),
  • oraz inne warianty łańcucha.

3) HeaconLoad (Golang): persystencja i „beaconing”

HeaconLoad potrafi uzyskać trwałość przez wpis w kluczu Run oraz zadanie Harmonogramu Zadań. Następnie wysyła „beacon” HTTP POST (m.in. na ścieżkę typu ...:8088/healthcheck) wraz z informacjami systemowymi i „build tagiem” (Trend Micro wymienia przykłady tagów jak sonic, shrek, yaropolk itd.).

4) BoryptGrab: kradzież danych z przeglądarek i portfeli

BoryptGrab to stealer (C/C++) z mechanizmami anti-analysis (m.in. anty-VM) i próbą uruchomienia z podniesionymi uprawnieniami. Kradnie dane z wielu przeglądarek (lista obejmuje m.in. Chrome, Edge, Brave, Firefox, Opera, Vivaldi, Yandex).

Istotny detal: malware wykorzystuje techniki związane z Chrome App-Bound Encryption i (wg Trend Micro) zawiera kod inspirowany publicznymi repozytoriami służącymi do obejścia/odszyfrowania tych mechanizmów.
Dodatkowo potrafi pobrać pomocniczy komponent („Chromium helper”) do zbierania danych z przeglądarek.

5) TunnesshClient: reverse SSH jako kanał C2 i proxy

TunnesshClient (PyInstaller) realizuje reverse SSH tunnel. Najpierw pobiera dane dostępowe przez HTTP POST do endpointów typu /api/get_challenge i /api/get_credentials, rozwiązuje challenge (SHA-256), odszyfrowuje odpowiedź i dopiero wtedy zestawia tunel.
Wśród funkcji: SOCKS5 proxy, wykonywanie poleceń shell, listowanie/wyszukiwanie plików, upload/download oraz wysyłka całych folderów w ZIP (base64).

Praktyczne konsekwencje / ryzyko

  • Przejęcie kont: kradzież haseł/cookies/tokenów z przeglądarek i komunikatorów (w tym wzmiankowane tokeny Discord) realnie skraca drogę do ataków typu account takeover.
  • Straty finansowe: kampania celuje w portfele kryptowalutowe (aplikacje desktop i rozszerzenia przeglądarkowe).
  • Ryzyko dalszej kompromitacji: TunnesshClient zapewnia kanał zdalnego sterowania i może działać jako proxy (pivot), co podnosi ryzyko ruchu lateralnego w sieci.
  • Trudniejsze wykrywanie: duża liczba repozytoriów, zmienne warianty, różne ścieżki uruchomienia i etapowanie payloadów utrudniają proste blokady oparte wyłącznie o hash.

Rekomendacje operacyjne / co zrobić teraz

  1. Ogranicz „shadow IT” instalacyjne
  • W środowiskach firmowych rozważ allowlisting (np. AppLocker/WDAC) i blokadę uruchamiania binariów z katalogów typu %TEMP% oraz pobranych archiwów (mark-of-the-web). To często łamie łańcuch na wczesnym etapie.
  1. EDR + detekcje na zachowania
  • Szukaj sekwencji: pobranie ZIP → uruchomienie nietypowego loadera/skryptu → zrzut danych przeglądarki/portfeli → archiwizacja → exfiltracja.
  • Monitoruj tworzenie zadań Harmonogramu i wpisów Run (w kontekście HeaconLoad).
  1. Kontrola ruchu sieciowego i anomalii
  • Alertuj na nietypowe POST-y do ścieżek „healthcheck”/API oraz długotrwałe połączenia tunelowe wskazujące na reverse SSH i ruch proxy (SOCKS5).
  1. Bezpieczne pobieranie narzędzi
  • Polityka: narzędzia tylko z oficjalnych stron producenta / zweryfikowanych release’ów, weryfikacja podpisów, sum kontrolnych, a w przypadku open-source – preferowanie oficjalnych organizacji GitHub + weryfikacja autora i historii repo.
  1. Higiena kont i odzyskiwanie po incydencie
  • Jeśli podejrzewasz infekcję: rotacja haseł, unieważnienie sesji, regeneracja tokenów, przegląd 2FA, kontrola portfeli krypto i ewentualna migracja środków na nowe seedy (w zależności od ekspozycji).

Różnice / porównania z innymi przypadkami

  • BoryptGrab vs klasyczne stealery: funkcjonalnie przypomina rodzinę infostealerów (przeglądarki, portfele, screenshoty), ale wyróżnia się „pakietowaniem” kampanii – obok kradzieży danych może dowozić dodatkowe payloady, w tym backdoora reverse SSH.
  • Powiązania z Vidar: Trend Micro opisuje pobieranie „custom build exe” będących wariantami Vidar z obfuskacją, co wskazuje na elastyczny model: jeden kanał dystrybucji, kilka rodzin malware w rotacji.
  • Nadużycie zaufania do GitHuba: to trend rosnący – aktorzy nie muszą hostować malware na podejrzanych domenach, bo korzystają z reputacji platformy i „podpinają” ruch ofiar pod legalnie wyglądające zasoby.

Podsumowanie / kluczowe wnioski

BoryptGrab to przykład dojrzałej, skalowanej kampanii, w której SEO poisoning + masowe repozytoria GitHub służą jako „fabryka” infekcji. Stealer kradnie szeroki zestaw danych (przeglądarki, portfele, pliki), a część wariantów dodaje TunnesshClient zapewniający zdalny dostęp przez reverse SSH i funkcje proxy. Obrona wymaga połączenia: polityk pobierania oprogramowania, twardej kontroli uruchamiania, detekcji behawioralnych i monitoringu ruchu tunelowego.

Źródła / bibliografia

  • Trend Micro – analiza kampanii BoryptGrab i TunnesshClient (Mar 5, 2026). (www.trendmicro.com)
  • SecurityWeek – podsumowanie ustaleń Trend Micro (Mar 7, 2026). (SecurityWeek)
  • SC Media / SC World – brief o kampanii i celowaniu w portfele krypto (Mar 6, 2026). (SC Media)

Termite ransomware i „Velvet Tempest”: jak ClickFix + CastleRAT łączą się z włamaniami i przygotowaniem pod ransomware

Wprowadzenie do problemu / definicja luki

ClickFix to technika socjotechniczna, która udaje „naprawę” problemu (np. CAPTCHA, błąd przeglądarki, weryfikacja człowieka) i instruuje użytkownika, by wkleił polecenie do Windows Run (Win+R) lub uruchomił je w PowerShell/cmd. To nie jest luka w oprogramowaniu, tylko skuteczny wektor initial access oparty o zachowanie użytkownika i „życie z ziemi” (LOLBAS). W 2026 r. ClickFix jest coraz częściej łączony z łańcuchami loader → RAT/stealer → ruch boczny → ransomware, bo daje atakującym szybkie wejście i dobre maskowanie.

W skrócie

Z obserwacji opisanej 7 marca 2026 r. wynika, że operatorzy śledzeni jako Velvet Tempest (DEV-0504) użyli kampanii malvertising prowadzącej do miksu ClickFix + CAPTCHA, aby skłonić ofiary do wklejenia zaciemnionego polecenia w oknie „Uruchom”. Następnie uruchomiony został kaskadowy łańcuch cmd.exe i narzędzi systemowych (w tym finger.exe) do pobrania pierwszych loaderów; jeden z elementów był archiwum podszywającym się pod PDF. W kolejnych etapach widoczna była automatyzacja przez PowerShell, kompilacja komponentów .NET przez csc.exe w katalogach tymczasowych oraz elementy oparte o Pythona dla utrzymania się w systemie (np. w C:\ProgramData). Finalnie miało to doprowadzić do uruchomienia loadera i pobrania CastleRAT.

Kluczowy niuans: w obserwowanym incydencie nie doszło do uruchomienia samego ransomware Termite, ale część infrastruktury/hostingu narzędzi była powiązana z wcześniejszymi intruzjami przypisywanymi do „Termite” (co sugeruje współdzielenie zasobów lub playbooków w ekosystemie afiliantów).

Kontekst / historia / powiązania

BleepingComputer wskazuje, że Velvet Tempest (DEV-0504) to doświadczony aktor, kojarzony z działalnością afilianta w wielu „epokach” ransomware. W praktyce takie grupy często zmieniają brand, przechodzą między programami RaaS i reużywają TTP, a równolegle korzystają z usług wyspecjalizowanych operatorów (np. MaaS/loader).

Istotne jest też tło „Castle*”: analizy branżowe opisują CastleLoader/CastleRAT jako elementy modularnego systemu dystrybucji malware, wykorzystywanego w kampaniach wieloetapowych (loader pobiera kolejne komponenty, a RAT daje trwałą kontrolę i rozpoznanie środowiska).

Analiza techniczna / szczegóły łańcucha

Poniżej typowy obraz techniczny tej klasy ataków (zbieżny z opisem incydentu i szerszymi analizami ClickFix/Castle):

Etap 0 — dystrybucja (malvertising / kompromitowane strony):

  • reklamy lub przejęte witryny kierują na stronę „weryfikacji”, która prezentuje instrukcję wklejenia komendy do Win+R.

Etap 1 — ClickFix (uruchomienie polecenia przez użytkownika):

  • ofiara uruchamia zaciemnioną komendę; w obserwacji pojawiają się zagnieżdżone łańcuchy cmd.exe oraz użycie finger.exe do pobrania pierwszych loaderów (LOLBAS, „życie z ziemi”).

Etap 2 — staging i wykonywanie kolejnych komponentów:

  • PowerShell pobiera dalsze payloady i uruchamia komendy,
  • widoczna jest kompilacja .NET przez csc.exe w katalogach tymczasowych,
  • pojawiają się komponenty Pythona wspierające persistence (np. w C:\ProgramData).

Etap 3 — loader → RAT:

  • BleepingComputer opisuje, że łańcuch finalnie „staged” loader i pobrał CastleRAT, kojarzony z rodziną CastleLoader dystrybuującą różne RAT-y i stealery.
  • Niezależne analizy CastleLoader pokazują, że ten typ loadera bywa budowany tak, by dekodować i uruchamiać payload w pamięci, ograniczając artefakty na dysku, oraz pobierać kolejne etapy z infrastruktury atakujących.

Dlaczego to jest groźne dla ransomware?
Bo po stabilnym osadzeniu RAT-a atakujący mają czas na rozpoznanie AD, kradzież poświadczeń, enumerację hostów i przygotowanie warunków do masowego wdrożenia szyfratora (czasem dopiero po dniach/tygodniach).

Praktyczne konsekwencje / ryzyko

W opisywanej obserwacji po uzyskaniu dostępu widoczne były działania „hands-on keyboard”, w tym rozpoznanie Active Directory, discovery hostów oraz profilowanie środowiska, a także próby pozyskiwania poświadczeń (np. z przeglądarki). To klasyczny schemat pre-ransomware: najpierw kontrola i mapowanie, potem eskalacja i dopiero na końcu decyzja o szyfrowaniu/eksfiltracji.

Dla biznesu przekłada się to na:

  • ryzyko przejęcia kont uprzywilejowanych i kompromitacji domeny,
  • kradzież danych i długotrwałą obecność (persistence),
  • możliwość uruchomienia ransomware w późniejszym terminie (również przez innego operatora, jeśli dostęp zostanie „sprzedany” lub współdzielony).

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz” (priorytety SOC/IR):

  1. Zablokuj ClickFix jako zachowanie, nie jako pojedynczy IOC
  • reguły EDR/SIEM na nietypowe uruchomienia: Win+R → cmd/powershell z długimi, zaciemnionymi parametrami,
  • monitoring „łańcuchów” procesów: explorer.exe → rundll32/cmd/powershell/mshta/regsvr32 (zależnie od wariantu kampanii).
  1. Hunting na LOLBAS i staging
  • korelacje na finger.exe w kontekście pobierania danych (rzadkie w normalnych środowiskach),
  • wykrywanie kompilacji przez csc.exe w %TEMP%/katalogach użytkownika,
  • alerty na podejrzane artefakty i trwałość w C:\ProgramData (zadania, usługi, autorun).
  1. Zabezpieczenia tożsamości
  • natychmiastowa rotacja haseł dla kont podejrzanych + wymuszenie MFA (szczególnie kont admin/serwisowych),
  • przegląd logowań i tokenów sesyjnych (nietypowe lokalizacje/urządzenia),
  • ograniczenie uprawnień lokalnych adminów i segmentacja dostępu do AD.
  1. Containment na endpointach
  • izolacja hostów z anomaliami w drzewie procesów (ClickFix/loader/RAT),
  • pełna triage pamięci i artefaktów (bo część etapów może być in-memory).
  1. Prewencja użytkownika
  • krótkie szkolenie „just-in-time”: „CAPTCHA nigdy nie wymaga Win+R i wklejania komend”,
  • blokady politykami (AppLocker/WDAC) na nieautoryzowane interpretery i nietypowe ścieżki uruchomień.

Różnice / porównania z innymi przypadkami

To, co wyróżnia ClickFix, to przeniesienie „momentu kompromitacji” na użytkownika: nie trzeba eksploitu, bo ofiara sama uruchamia payload. Unit 42 opisuje ClickFix jako rosnący trend i pokazuje, że kampanie potrafią dynamicznie zmieniać implementację (różne rodziny malware, różne łańcuchy), a mimo to rdzeń jest stały: obfuscated PowerShell/command + kolejne etapy.

Z kolei analizy łańcuchów ClickFix w innych kampaniach (np. kończących się stealerami) pokazują podobną logikę: shellcode/loader → wstrzyknięcie do legalnych procesów → eksfiltracja. To ważne, bo organizacje często bagatelizują „tylko stealer”, a w praktyce stealer bywa etapem budowy dostępu pod większą operację.

Podsumowanie / kluczowe wnioski

  • ClickFix to skuteczny, „tani” wektor initial access, który omija potrzebę exploitów i utrudnia obronę, bo opiera się na zachowaniu użytkownika.
  • W opisywanym przypadku widoczny jest klasyczny playbook: malvertising → ClickFix → LOLBAS/PowerShell/.NET → CastleRAT, a następnie działania ręczne w sieci (AD discovery itp.).
  • Nawet jeśli w danej obserwacji ransomware nie zostanie uruchomione, taki dostęp należy traktować jako incydent o wysokim priorytecie, bo to typowy etap „przygotowania pola” pod szyfrowanie i/lub eksfiltrację.
  • Obrona wymaga podejścia behawioralnego: wykrywania łańcuchów procesów, nietypowych LOLBAS (np. finger.exe), kompilacji csc.exe, persistence w ProgramData oraz twardej higieny tożsamości.

Źródła / bibliografia

  1. BleepingComputer — „Termite ransomware breaches linked to ClickFix CastleRAT attacks” (7 marca 2026) (BleepingComputer)
  2. Darktrace — „CastleLoader & CastleRAT: Behind TAG150’s Modular Malware Delivery System” (26 listopada 2025) (Darktrace)
  3. Palo Alto Networks Unit 42 — „Fix the Click: Preventing the ClickFix Attack Vector” (aktualizacja 10 lipca 2025) (Unit 42)
  4. LevelBlue / SpiderLabs — „How ClickFix Opens the Door to Stealthy StealC Information Stealer” (12 lutego 2026) (levelblue.com)
  5. Blackpoint Cyber — „Snakes in the Castle: Inside a Python-Driven CastleLoader Delivery” (9 grudnia 2025) (Blackpoint)

VOID#GEIST: wieloetapowy, „fileless” łańcuch infekcji, który dowozi XWorm, AsyncRAT i XenoRAT

Wprowadzenie do problemu / definicja luki

VOID#GEIST to nazwa kampanii opisanej przez Securonix, w której atakujący odchodzą od typowych plików wykonywalnych PE na rzecz łańcucha opartego o skrypty i uruchamianie ładunków w pamięci. Zamiast „klasycznego EXE”, ofiara widzi (pozornie) zwykłą czynność — np. otwarcie dokumentu — podczas gdy w tle uruchamiane są kolejne etapy infekcji: batch, PowerShell, pobranie legalnego środowiska Python oraz finalne wstrzyknięcie shellcode do procesu explorer.exe.

W skrócie

  • Nośnik/launcher: obfuskowany skrypt BAT (m.in. non.bat), dystrybuowany m.in. w kampaniach phishingowych i pobierany z domen w modelu TryCloudflare.
  • Kamuflaż: wabik w postaci PDF otwieranego w Chrome (socjotechnika i „odwrócenie uwagi”).
  • Persistencja: drugi BAT (np. spol.bat) w Startup folder użytkownika — bez eskalacji uprawnień.
  • Rdzeń: pobranie legalnego Python embedded runtime z python.org, a następnie odszyfrowanie i uruchomienie w pamięci shellcode odpowiadającego trzem rodzinom RAT: XWorm, AsyncRAT, XenoRAT.
  • Technika wykonania: Early Bird APC injection (MITRE ATT&CK: T1055.004) do nowych instancji explorer.exe.

Kontekst / historia / powiązania

Wzorzec „script-first + living-off-the-land + fileless” to trend, który w praktyce daje atakującym kilka przewag:

  1. Mniej artefaktów na dysku → mniejsza szansa na detekcję sygnaturową.
  2. Etapy wyglądają niewinnie w izolacji: cmd.exe, PowerShell, curl, archiwum ZIP, Python — wszystko bywa legalne w środowiskach IT.
  3. Szybka rotacja infrastruktury (np. przez Cloudflare Tunnel/TryCloudflare) utrudnia blokowanie IOC w dłuższym horyzoncie.

VOID#GEIST jest dobrym przykładem dojrzałej „operacyjnej” kampanii: łączy psychologię (wabik PDF), stealth (ukryty relaunch), przenośność (Python embedded) i technikę wstrzyknięcia do zaufanego procesu.

Analiza techniczna / szczegóły łańcucha infekcji

Poniżej najczęściej opisywany przebieg (na podstawie analizy Securonix i streszczenia THN):

Etap A: non.bat jako punkt wejścia

  • Uruchomienie przez cmd.exe /c ...\non.bat rozpoczyna orkiestrację infekcji.
  • Skrypt bywa pobierany z adresów typu TryCloudflare (przykładowo obserwowano hosty w tej domenie).

Etap B: Wabik PDF (odwrócenie uwagi)

  • Securonix opisuje otwieranie Chrome z URL-em do „faktury” (PDF) hostowanej na zaufanie wyglądającej domenie. Klucz: to nie exploit, tylko zasłona dymna, gdy w tle lecą kolejne kroki.

Etap C: Ukryty relaunch przez PowerShell

  • PowerShell startuje non.bat ponownie z ukrytą konsolą (-WindowStyle Hidden) i parametrem sterującym logiką skryptu (np. tryb „h”).
  • To pozwala wykonać staging bez „migających” okien cmd.exe i bez zwracania uwagi użytkownika.

Etap D: Staging narzędzi + Python embedded runtime

  • Kampania pobiera oficjalny pakiet embedded Pythona (w raporcie wskazywany jest wariant Python 3.10 embedded dla Windows) bezpośrednio z python.org.
  • To ważny moment: ruch do legalnej domeny jest często mniej podejrzany, a jednocześnie zapewnia środowisko uruchomieniowe niezależne od tego, czy Python jest zainstalowany na stacji.

Etap E: Shellcode, XOR i wykonanie „fileless”

  • Ładunki RAT są dostarczane jako zaszyfrowane bloby (np. new.bin, pul.bin, xn.bin) i odszyfrowywane w locie z użyciem materiału klucza w plikach JSON (np. a.json, p.json, n.json).
  • Następnie payloady są wstrzykiwane do oddzielnych instancji explorer.exe i wykonywane bez zapisu odszyfrowanego EXE na dysku.

Etap F: Early Bird APC injection do explorer.exe

  • Technika wskazywana wprost to Early Bird APC injection (MITRE: T1055.004 Asynchronous Procedure Call), czyli wstrzyknięcie przed pełnym „rozruchem” procesu i potencjalnymi hookami/telemetrią bezpieczeństwa.

Etap G: Beaconing / potwierdzenie infekcji

  • Łańcuch kończy się lekkim beaconem HTTP (np. sygnał „success”) do infrastruktury kontrolowanej przez atakujących, również hostowanej w TryCloudflare.

Przykładowe IOC z raportu Securonix (wycinek)

  • Domeny C2/infrastruktura:
    • staying-heavily-meaning-blowing.trycloudflare[.]com
    • servers-johnson-rebate-recipes.trycloudflare[.]com
  • Pliki/artefakty: non.bat, spol.bat, runn.py, new.bin, pul.bin, xn.bin, a.json, p.json, n.json

Praktyczne konsekwencje / ryzyko

Jeśli VOID#GEIST z powodzeniem dostarczy RAT (XWorm/AsyncRAT/XenoRAT), organizacja zwykle ryzykuje:

  • Zdalne sterowanie stacją (RAT), kradzież danych i poświadczeń, rekonesans AD, lateral movement.
  • Trudniejszą detekcję, bo payload działa w pamięci, a wykonanie jest „opakowane” w legalne narzędzia.
  • Persistencję na poziomie użytkownika (Startup folder) — szczególnie problematyczną w środowiskach z luźniejszymi politykami uruchamiania skryptów.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (0–24h)

  1. Blokuj i monitoruj ruch do podejrzanych subdomen trycloudflare.com (z naciskiem na IOC z raportu) oraz nietypowe połączenia wychodzące inicjowane przez explorer.exe.
  2. Poluj na artefakty: obecność non.bat, spol.bat, plików *.bin i *.json w katalogach użytkownika / temp / appdata.
  3. Sprawdź Startup folder użytkowników pod kątem świeżych BAT/skrótów i nietypowych wpisów autostartu.

Utwardzenie (1–7 dni)

  • WDAC/AppLocker: ogranicz uruchamianie .bat, .ps1, .js, .vbs z katalogów użytkownika i profili przeglądarek/poczty.
  • Włącz i zbieraj:
    • PowerShell Script Block Logging (często kluczowe w kampaniach z obfuskacją)
    • Sysmon/EDR telemetrię pod kątem tworzenia procesu w stanie CREATE_SUSPENDED, alokacji pamięci w obcym procesie i kolejki APC (typowe sekwencje dla T1055.004).
  • Monitoruj pobrania z python.org w organizacjach, gdzie to nietypowe (np. nagły download embedded runtime na stacjach biurowych).

Hunting (ciągłe)

  • Koreluj: powershell.exe → ukryty start non.bat → curl/pobrania ZIP → uruchomienie python z nietypowymi argumentami → nowe instancje explorer.exe + nietypowy ruch sieciowy.
  • Poluj na zachowanie opisane w MITRE dla APC/Early Bird injection (T1055.004), bo to często wspólny mianownik dla „fileless” loaderów.

Różnice / porównania z innymi przypadkami

VOID#GEIST wyróżnia się tym, że:

  • Stawia na „portable execution environment” przez Python embedded pobrany z legalnego źródła (zmniejsza zależność od konfiguracji hosta).
  • Łączy „human evasion” (PDF-wabik) z „EDR evasion” (wstrzyknięcie Early Bird APC) w jednym, spójnym łańcuchu.
  • Rozdziela wykonanie payloadów do oddzielnych procesów explorer.exe, co zwiększa odporność operacyjną (awaria jednego nie musi kończyć całej operacji).

Podsumowanie / kluczowe wnioski

  • VOID#GEIST to kampania, która dobrze pokazuje, jak współczesne infekcje wygrywają „prostotą w etapach”: każdy krok wygląda legalnie, ale suma daje pełną kompromitację.
  • Najbardziej newralgiczne punkty obrony to: kontrola uruchamiania skryptów, telemetria PowerShell, oraz detekcja in-memory injection (szczególnie APC/Early Bird).
  • Jeśli Twoje środowisko nie używa Pythona na endpointach: alert na embedded runtime z python.org może być bardzo skutecznym sygnałem.

Źródła / bibliografia

  1. The Hacker News – „Multi-Stage VOID#GEIST Malware Delivering XWorm, AsyncRAT, and Xeno RAT” (06.03.2026). (The Hacker News)
  2. Securonix Threat Research – „VOID#GEIST: Stealthy Multi-Stage Python Loader…” (17.02.2026). (Securonix)
  3. MITRE ATT&CK – T1055.004 Process Injection: Asynchronous Procedure Call (w tym wariant Early Bird). (MITRE ATT&CK)
  4. MITRE ATT&CK – T1547.001 Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder. (MITRE ATT&CK)

APT28 i nowy duet malware: BadPaw + MeowMeow w kampanii przeciw Ukrainie

Wprowadzenie do problemu / definicja luki

Na początku marca 2026 r. badacze opisali ukierunkowaną kampanię phishingową wymierzoną w ukraińskie podmioty, w której pojawiają się dwie wcześniej nieudokumentowane rodziny złośliwego oprogramowania: BadPaw (loader w .NET) oraz MeowMeow (backdoor). Rdzeniem problemu nie jest pojedyncza „luka” CVE, lecz złożony łańcuch infekcji oparty o socjotechnikę, wieloetapowe uruchamianie komponentów oraz mechanizmy utrudniające analizę i detekcję.

W skrócie

  • Wejście: phishing z wiarygodnie wyglądającego nadawcy w domenie ukr[.]net, plus przynęta związana z „apelacją / sprawą graniczną”.
  • Telemetria kliknięcia: ofiara jest kierowana najpierw na tracking pixel (miniaturowy obraz), co daje operatorom sygnał, że link został otwarty.
  • Dropper: archiwum ZIP zawiera plik udający HTML, który w praktyce jest HTA uruchamiającym kolejne etapy.
  • Steganografia: VBScript wyciąga z obrazu PNG ukryty plik wykonywalny (PE) – tak powstaje loader BadPaw.
  • Backdoor: BadPaw pobiera i instaluje MeowMeow, zdolny m.in. do uruchamiania poleceń PowerShell i operacji na plikach.
  • Atrybucja: ClearSky ocenia kampanię jako rosyjsko-ukierunkowaną (wysoka pewność) oraz wiąże ją z APT28 tylko z niską pewnością; THN opisuje powiązanie z APT28 jako umiarkowane.

Kontekst / historia / powiązania

APT28 (znany też m.in. jako Fancy Bear / STRONTIUM / Forest Blizzard) to wieloletnio aktywny klaster działań przypisywany rosyjskim strukturom wojskowego wywiadu; w ATT&CK widnieje jako grupa G0007, aktywna co najmniej od 2004 r.
Microsoft w publicznych materiałach opisuje Forest Blizzard (d. STRONTIUM) jako aktora państwowego wykorzystującego m.in. spearphishing i techniki kradzieży poświadczeń, atakującego sektor rządowy, dyplomatyczny i obronny, w tym Ukrainę.

W omawianej kampanii istotny jest też „lokalny realizm” przynęty: narracja w języku ukraińskim i tematyka przekraczania granicy / urzędowej korespondencji. To typowa oś dla operacji szpiegowskich, gdzie liczy się nie masowość, a trafienie w konkretnych adresatów.

Analiza techniczna / szczegóły luki

Poniżej – łańcuch infekcji od kliknięcia do backdoora, w ujęciu „co robi napastnik” i „co widać w telemetryce”.

1. Inicjacja: phishing + telemetria kliknięcia

  • Wiadomość pochodzi z adresu w ukr[.]net (według raportu: konkretna skrzynka nadawcy związana z narracją „graniczną”).
  • Kliknięcie uruchamia dwa równoległe przekierowania:
    1. na domenę hostującą tracking pixel (sygnał „link kliknięty”),
    2. na skrócony URL, który inicjuje pobranie ZIP.

Warto detekcyjnie: nietypowa sekwencja przekierowań + pobranie archiwum po „mikro-obrazie” często wskazuje na kampanie z telemetrią skuteczności.

2. ZIP → HTA (podszycie pod HTML)

W archiwum znajduje się plik z rozszerzeniem .html, który w rzeczywistości jest HTA (HTML Application). Uruchomienie HTA:

  • otwiera dokument-wabik (odwrócenie uwagi),
  • w tle odpala kolejne etapy infekcji.

3. Anti-sandbox na starcie: „wiek systemu”

HTA sprawdza klucz rejestru HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate i przerywa działanie, jeśli system jest „zbyt świeży” (mniej niż 10 dni). To klasyczny trik na unikanie automatycznych sandboxów i świeżych maszyn analityków.

4. Persistencja i steganografia: VBS + PNG

Kolejny etap to:

  • wydobycie z ZIP VBScript i obrazu PNG,
  • utworzenie Scheduled Task uruchamiającego VBS (persistencja),
  • VBS parsuje PNG, szuka markera typu <STEGO_START> i wyciąga ukryty PE (zapisuje go jako osobny plik).

To ważne, bo w wielu środowiskach obrazki nie są traktowane jako nośnik „aktywny”, a tu PNG pełni rolę kontenera dla wykonywalnego loadera.

5. BadPaw: loader w .NET z „dummy mode”

BadPaw to komponent w .NET, dodatkowo pakowany/obfuskowany przez .NET Reactor, co utrudnia analizę statyczną.
Cechy wyróżniające:

  • jeśli uruchomiony poza właściwym łańcuchem, wykonuje „fałszywą” logikę i pokazuje pozornie legalne GUI (w raporcie: narzędzie typu „Regex Finder”).
  • właściwa złośliwa logika uruchamia się dopiero po podaniu parametru uruchomieniowego (np. -renew).

6. Komunikacja C2 i etapowe pobieranie payloadu

W raporcie wskazano infrastrukturę C2 oraz etapowe odpowiedzi serwera:

  • po stronie sieci widać żądania do domeny C2 i endpointów typu /getcalendar, /eventmanager, /planneractivate,
  • w jednym z etapów serwer zwraca stronę HTML zawierającą blok ASCII osadzony między znacznikami, który następnie jest dekodowany do kolejnego komponentu,
  • po tym malware upuszcza m.in. pliki konfiguracyjne oraz finalny backdoor MeowMeow.

7. MeowMeow: backdoor z wielowarstwową ochroną

MeowMeow również wykorzystuje:

  • obfuskację (.NET Reactor),
  • „dummy mode” (fałszywe GUI z motywem kota; kliknięcie przycisku wyświetla komunikat, bez działań szkodliwych),
  • uruchomienie złośliwej funkcjonalności dopiero przy właściwym parametrze (np. -v przekazywanym przez łańcuch infekcji),
  • rozbudowane anti-analysis: wykrywanie narzędzi typu Wireshark/Procmon/Ollydbg/Fiddler i mechanizmów wirtualizacji, z przerwaniem pracy po detekcji.

Funkcjonalnie MeowMeow pozwala na:

  • zdalne wykonywanie poleceń (wprost wskazywany PowerShell),
  • operacje na plikach: sprawdzanie istnienia, odczyt/zapis/usuwanie.

Praktyczne konsekwencje / ryzyko

  1. Szpiegostwo i dostęp długoterminowy: MeowMeow to backdoor, więc ryzyko obejmuje rekonesans, eksfiltrację i przygotowanie kolejnych etapów (np. kradzież dokumentów, utrzymanie przyczółka).
  2. Trudniejsza analiza incydentu: „dummy mode” + parametry uruchomieniowe mogą powodować, że próbki uruchamiane w izolacji wydają się „nieszkodliwe”, co opóźnia klasyfikację i reakcję.
  3. Wysoka skuteczność spearphishingu: lokalny kontekst (ukraińska treść, tematyka graniczna, nadawca w ukr[.]net) zwiększa wiarygodność i szanse kliknięcia.

Rekomendacje operacyjne / co zrobić teraz

1. Szybkie działania defensywne (48–72h)

  • Blokuj/ogranicz HTA i VBScript: jeśli biznesowo możliwe, wyłącz obsługę lub uruchamianie mshta.exe, ogranicz wscript.exe/cscript.exe (ASR / AppLocker / WDAC). Łańcuch bazuje na HTA→VBS.
  • Poluj na Scheduled Tasks tworzone nietypowo (nowe zadania uruchamiające VBS z katalogów użytkownika/tymczasowych) – to kluczowy punkt persistencji.
  • Detekcje EDR: alerty na procesy mshta.exe → wscript.exe + dostęp do plików PNG, a następnie uruchomienie nowego .exe z nietypowej ścieżki.
  • Zasady proxy/DNS: dodaj blokady i alerty na domeny i ścieżki opisane w raporcie (C2 i tracking), oraz na nietypowe sekwencje przekierowań (pixel → pobranie ZIP).

2. Hardening i odporność na kampanie podobnego typu

  • Zaostrzenie polityk pocztowych: filtrowanie linków do archiwów, sandboxing załączników/URL, ostrzeganie o skracaczach linków. (Tu skrócony URL był elementem łańcucha.)
  • Least privilege + segmentacja: backdoor z PowerShell to paliwo do ruchu bocznego i działań post-exploitation — ogranicz uprawnienia lokalne i lateral movement.
  • Ćwiczenia socjotechniczne: scenariusze „urząd / dokument graniczny / potwierdzenie” dopasowane do realiów odbiorców są dziś ważniejsze niż ogólne szkolenia.

Różnice / porównania z innymi przypadkami

Na tle „typowych” loaderów .NET, ta kampania wyróżnia się trzema elementami praktycznie podnoszącymi koszt obrony:

  1. Steganografia w PNG jako kanał przeniesienia PE (utrudnia polityki oparte o typy plików).
  2. Podwójna przynęta: wabik dokumentu + „dummy GUI” w przypadku uruchomienia poza łańcuchem (utrudnia triage i reverse engineering).
  3. Parametry uruchomieniowe jako „klucz” do aktywacji złośliwych funkcji — bez nich próbka może wyglądać na nieszkodliwą.

Podsumowanie / kluczowe wnioski

BadPaw i MeowMeow pokazują, że spearphishing nadal jest skuteczny, gdy jest konsekwentnie lokalizowany, a technicznie wzmacniany przez wieloetapowość, steganografię i anti-analysis. Raport ClearSky sugeruje silne powiązania z rosyjskim ekosystemem operacji przeciw Ukrainie, przy ostrożności w przypisywaniu tego konkretnie do APT28.
Dla obrony kluczowe są: kontrola HTA/VBS, monitoring Scheduled Tasks, oraz detekcje na łańcuch procesów i nietypowe pobrania/redirecty.

Źródła / bibliografia

  1. ClearSky, BadPaw and MeowMeow (raport PDF, marzec 2026). (clearskysec.com)
  2. The Hacker News, APT28-Linked Campaign Deploys BadPaw Loader and MeowMeow Backdoor in Ukraine (05.03.2026). (The Hacker News)
  3. The Record (Recorded Future News), Russian hackers deploy new malware in phishing campaign targeting Ukraine (04.03.2026). (The Record from Recorded Future)
  4. MITRE ATT&CK, APT28 (G0007). (attack.mitre.org)
  5. Microsoft Security Insider, Threat Actor: Forest Blizzard (formerly STRONTIUM). (Microsoft)

UAT-9244: chińsko-powiązany APT atakuje operatorów telekomunikacyjnych w Ameryce Południowej (TernDoor, PeerTime, BruteEntry)

Wprowadzenie do problemu / definicja luki

Cisco Talos opisał nowy klaster działań nazwany UAT-9244, który – według analityków – z wysoką pewnością jest powiązany z chińskim zapleczem APT i ściśle zbieżny operacyjnie z ekosystemem znanym jako FamousSparrow (oraz wskazuje na nakładanie się z Tropic Trooper). Kampania ma trwać co najmniej od 2024 r. i koncentruje się na krytycznej infrastrukturze telekomunikacyjnej w Ameryce Południowej, obejmując systemy Windows, Linux oraz urządzenia brzegowe (edge).

W praktyce nie jest to „pojedyncza luka” typu CVE, tylko zestaw technik intruzyjnych + 3 implanty malware, które razem umożliwiają: utrzymanie trwałego dostępu (backdoory), poruszanie się po środowisku oraz przekształcanie przejętych hostów/edge w węzły masowego skanowania i brute force.

W skrócie

  • Cel: operatorzy telco (Ameryka Południowa), środowiska mieszane Windows/Linux + edge.
  • Implanty:
    • TernDoor (Windows) – nowy wariant rodziny CrowDoor/SparrowDoor, uruchamiany przez DLL side-loading, z komponentem sterownika do zarządzania procesami.
    • PeerTime (Linux/ELF, multi-arch) – backdoor P2P używający protokołu BitTorrent do pobierania informacji C2 i ładunków.
    • BruteEntry (Linux/edge, Go) – agent budujący ORB (Operational Relay Box): pobiera zadania z C2, masowo skanuje i brute-forcuje SSH, Postgres, Tomcat.
  • Ważny kontekst obrony: ORB to często infrastruktura „na wynajem”/zarządzana przez pośredników, szybko rotowana, co skraca „żywotność” IOC i utrudnia atrybucję po samych IP.

Kontekst / historia / powiązania

Talos wiąże UAT-9244 z FamousSparrow na podstawie zbieżności narzędzi, TTP i doboru ofiar. Jednocześnie podkreśla, że mimo podobnego profilu celów (telco) nie potwierdzono twardego powiązania z klastrem określanym jako Salt Typhoon.

Dodatkowo:

  • ESET opisuje FamousSparrow jako aktywną od co najmniej 2019 r. grupę cyberszpiegowską, która rozwijała warianty SparrowDoor i w różnych kampaniach wykorzystywała m.in. webshee na IIS oraz środowiska podatne/nieaktualne.
  • Materiały z Virus Bulletin (VB2023) wskazują na relację Tropic Trooper ↔ FamousSparrow poprzez współdzielenie/obserwację CrowDoor, opisywanego jako nazwanego „od SparrowDoor” i wykazującego podobieństwa w loaderze.
  • Trend Micro opisuje Earth Estries (aka Salt Typhoon) jako aktora używającego m.in. Crowdoor w łańcuchu narzędzi i technik, co pomaga zrozumieć „rodzinę” i obieg komponentów w tym ekosystemie.

Analiza techniczna / szczegóły luki

1) TernDoor (Windows): DLL side-loading + loader + sterownik

Talos opisuje łańcuch infekcji, w którym UAT-9244 uruchamia legalny plik wsprint.exe, aby załadować złośliwy loader DLL BugSplatRc64.dll (klasyczny DLL side-loading). Loader czyta z dysku plik danych WSPrint.dll, odszyfrowuje go i wykonuje w pamięci, finalnie uruchamiając backdoor TernDoor.

Cechy wyróżniające TernDoor względem znanych wariantów CrowDoor:

  • inne zestawy kodów poleceń (command codes),
  • osadzony sterownik Windows (SYS) szyfrowany (AES) w shellcodzie, wykorzystywany do wstrzymywania/wznawiania/ubijania procesów (ułatwienia ewazji/utrzymania dostępu).

Persistencja i ukrywanie śladów:

  • persistencja przez Scheduled Task (np. zadanie „WSPrint”) lub klucz Run,
  • dodatkowe modyfikacje w rejestrze związane z TaskCache, aby ukryć zadanie.

2) PeerTime (Linux/ELF, P2P): BitTorrent jako kanał C2

PeerTime to backdoor ELF kompilowany na wiele architektur (ARM/AARCH/PPC/MIPS itd.), co sugeruje gotowość do infekowania także środowisk wbudowanych i urządzeń brzegowych. Dostarczany jest przez skrypt powłoki, który pobiera loader i binarkę „instrumentora”; instrumentor sprawdza obecność Dockera i potrafi uruchamiać loader w kontekście docker.

Najciekawsze elementy:

  • BitTorrent do pozyskiwania informacji C2, pobierania plików od „peerów” i wykonywania ich na hoście,
  • użycie BusyBox do kopiowania payloadów,
  • co najmniej dwie linie rozwojowe: starsza C/C++ i nowsza w Rusta.

3) BruteEntry (Go): ORB i masowe brute force

Trzeci implant, BruteEntry, to narzędzie do budowania operacyjnych węzłów pośredniczących (ORB) na przejętych systemach Linux/edge. Mechanika wygląda jak „agent + C2 + kolejka zadań”:

  • agent rejestruje się do C2 (IP/hostname),
  • dostaje agent_id,
  • pobiera listę zadań (/tasks/<agent_id>?limit=1000) i wykonuje skany/brute force w zależności od typu: tomcat / postgres / ssh,
  • wyniki raportuje POST-em do C2 (success/notes).

W praktyce oznacza to, że przejęte urządzenia brzegowe mogą zostać zamienione w masowo-skanujące „proxy-boty”, wspierające dalsze włamania (w telco i poza nim).

ORB (Operational Relay Box): dlaczego to boli obrońców

Google/Mandiant opisuje ORB jako sieci węzłów infrastrukturalnych (kompromitowane routery, VPS-y lub miks), często administrowane przez pośredników/kontraktorów, a nie przez pojedynczą grupę APT. Skutki:

  • infrastruktura rotuje szybko (czasem ~miesiąc na IPv4), co przyspiesza „IOC extinction”,
  • sama obserwacja IP egress nie wystarcza do pewnej atrybucji – trzeba patrzeć na narzędzia i TTP.

Praktyczne konsekwencje / ryzyko

  1. Ryzyko dla telco = ryzyko dla państwa i gospodarki. Operatorzy telekomunikacyjni to naturalny cel cyberszpiegostwa (dane billingowe, metadane, dostęp do segmentów szkieletowych, punkty integracji).
  2. Atak na edge = efekt mnożnikowy. Jeśli edge staje się ORB, organizacja może nie tylko tracić kontrolę nad własnym ruchem, ale też stać się „infrastrukturą” do ataków na innych (ryzyko prawne, reputacyjne, blacklisting).
  3. Wykrywalność po IP spada. Szybka rotacja ORB skraca użyteczność list IOC i wymusza podejście behawioralne (telemetria EDR/NDR, modelowanie TTP).

Rekomendacje operacyjne / co zrobić teraz

Priorytet 1: twardnienie edge i Linux

  • inwentaryzacja urządzeń brzegowych i usług zdalnych (SSH/Tomcat/Postgres), ograniczenie ekspozycji, wymuszenie MFA tam, gdzie możliwe, oraz odcięcie paneli administracyjnych od Internetu (VPN/Zero Trust). (BruteEntry celuje właśnie w te powierzchnie).
  • rotacja i weryfikacja haseł (szczególnie „domyślnych” i współdzielonych), polityki anty-brute-force, rate limiting, fail2ban/sshguard, blokady na warstwie WAF/IPS dla paneli Tomcat Manager.

Priorytet 2: polowanie na artefakty TernDoor

  • monitoruj oznaki DLL side-loading i nietypowe uruchomienia wsprint.exe,
  • szukaj anomalii: katalog/ścieżka i pliki powiązane z „WSPrint” (zadanie harmonogramu, klucze Run), oraz działań ukrywających task w TaskCache.

Priorytet 3: wykrywanie PeerTime

  • na Linux/embedded: detekcja nietypowego użycia BitTorrent w serwerach produkcyjnych + procesów podszywających się pod „benign” (PeerTime potrafi zmieniać nazwę procesu),
  • anomalia: uruchamianie binarek przez docker <ścieżka_binarki> w sposób niespójny z praktykami devops.

Priorytet 4: obserwacje sieciowe i podejście „ORB-aware”

  • zamiast wyłącznie blokowania IP: korelacja zachowań ORB (rotacja, geograficzna „bliskość” źródeł, nietypowe wzorce egress) i „fingerprintów” narzędzi/TTP,
  • w SOC: playbook pod kampanie telco z naciskiem na lateral movement i długotrwałe utrzymanie dostępu.

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

  • UAT-9244 vs klasyczne kampanie APT oparte o stałe C2: tutaj dochodzi warstwa ORB, która „rozmywa” infrastrukturę i utrudnia blokowanie po IOC.
  • TernDoor/CrowDoor/SparrowDoor: Talos opisuje TernDoor jako wariant CrowDoor, a materiały branżowe (VB) pokazują, że CrowDoor bywa zestawiany z rodziną SparrowDoor i pojawia się w kontekstach łączących Tropic Trooper z FamousSparrow.
  • Atrybucja a „Salt Typhoon”: ESET i Talos ostrożnie podchodzą do łączenia klastrów wyłącznie po profilu celu (telco) – podkreślając potrzebę dowodów TTP/tooling.

Podsumowanie / kluczowe wnioski

UAT-9244 to przykład „pełnego pakietu” dla cyberszpiegostwa przeciw telco: Windowsowy backdoor z driverem (TernDoor), Linuxowy P2P backdoor (PeerTime) oraz agent ORB do skanowania i brute force (BruteEntry). Warto potraktować tę kampanię jako sygnał, że obrona telco (i dostawców telco) powinna iść w stronę: twardnienia edge, ograniczania powierzchni administracyjnej, detekcji behawioralnej oraz analizy TTP ponad listami IP.

Źródła / bibliografia

  1. Cisco Talos Intelligence Blog – opis kampanii UAT-9244 i implantów (TernDoor/PeerTime/BruteEntry). (Cisco Talos Blog)
  2. Google Cloud / Mandiant – koncepcja ORB, rotacja infrastruktury i „IOC extinction”. (Google Cloud)
  3. ESET (WeLiveSecurity) – analiza FamousSparrow i kontekst atrybucyjny wokół Salt Typhoon. (welivesecurity.com)
  4. Trend Micro – Earth Estries (aka Salt Typhoon) i użycie Crowdoor w łańcuchach ataku. (www.trendmicro.com)
  5. Virus Bulletin (VB2023, slajdy) – CrowDoor/SparrowDoor i relacje Tropic Trooper ↔ FamousSparrow.

Bing AI promował fałszywe repozytorium OpenClaw na GitHubie. Efekt: infostealery i proxy GhostSocks na stacjach użytkowników

Wprowadzenie do problemu / definicja luki

To nie jest klasyczna „luka” w sensie CVE. To łańcuch nadużyć z pogranicza SEO/brand-impersonation + zaufania do GitHuba + „AI answer engine”. W praktyce: użytkownik wpisuje w Bing zapytanie w stylu „OpenClaw Windows”, a mechanizm odpowiedzi AI potrafi polecić fałszywe repozytorium na GitHubie z instrukcjami instalacji prowadzącymi do uruchomienia malware.

W skrócie

  • Kampania dotyczyła fałszywych „installerów” OpenClaw hostowanych na GitHubie i polecanych w wynikach Bing (AI).
  • Okno aktywności zidentyfikowane przez Huntress: 2–10 lutego 2026.
  • Dla Windows: dostarczano infostealery (m.in. Vidar) oraz GhostSocks (backconnect proxy); część loaderów była pisana w Rust i wykonywała payloady w pamięci.
  • Dla macOS: instrukcje prowadziły do pobrania/uruchomienia komponentów powiązanych z Atomic macOS Stealer (AMOS).

Kontekst / historia / powiązania

OpenClaw to popularny, open-source’owy „agent”/asystent AI, który z definicji działa lokalnie i ma dostęp do plików oraz integracji (poczta, komunikatory, usługi online). To sprawia, że jest atrakcyjnym celem: jedna infekcja infostealerem = dostęp do haseł + tokenów + potencjalnie sekretów w konfiguracjach narzędzi AI.

W ostatnich tygodniach temat bezpieczeństwa ekosystemu OpenClaw przewijał się również w kontekście „skills”/rozszerzeń i ryzyka dowożonego przez instrukcje uruchamiania poleceń w shellu.

Analiza techniczna / szczegóły kampanii

1) Socjotechnika + wiarygodność GitHuba + „autorytet” AI w wyszukiwarce

Huntress opisał przypadek, w którym użytkownik trafił na repo podszywające się pod instalator Windows, a Bing AI wskazał je jako „top” sugestię dla frazy „OpenClaw Windows”.

Repo wyglądało wiarygodnie m.in. dlatego, że:

  • było podpięte pod organizację w stylu „openclaw-installer” (wrażenie „oficjalności”),
  • zawartość kodu źródłowego częściowo kopiowała legalny projekt (moltworker od Cloudflare), co podbija „legit look” i może mylić zarówno ludzi, jak i systemy automatyczne.

2) Windows: 7z z „OpenClaw_x64.exe”, loadery w Rust, Vidar i GhostSocks

Z perspektywy Windows wektorem był plik wykonywalny (m.in. w archiwum 7-Zip), który prowadził do uruchomienia kilku komponentów:

  • Rust-based loadery, które uruchamiały infostealery w pamięci (utrudnia analizę i detekcję opartą o artefakty na dysku),
  • Vidar stealer – według opisu potrafił pozyskiwać dane C2 m.in. poprzez odwołania do profili na Telegramie i Steam,
  • GhostSocks backconnect proxy – malware zamieniające maszynę ofiary w węzeł proxy.

GhostSocks jest tutaj szczególnie groźny operacyjnie: jeśli infostealer wyciągnie ciasteczka/tokenty/hasła, to operator może logować się „z IP ofiary”, obchodząc antyfraud oparte o geolokację, reputację IP czy „impossible travel”. Huntress wprost wskazuje tę wartość dla atakującego.

Dodatkowo Huntress opisał użycie Stealth Packer (packer/injector), który ma realizować m.in. wstrzykiwanie do pamięci, modyfikacje reguł zapory i artefakty w harmonogramie zadań oraz proste anty-VM (np. warunek ruchu myszy).

3) macOS: „bash one-liner” i AMOS

W wariancie dla macOS repo instruowało użytkownika, by wkleił w Terminalu jednowierszową komendę bash, która pobierała zasoby z innej organizacji/repo. W analizie wskazano, że ładunek odpowiadał schematowi shell script + Mach-O, a finalnie mapował się na Atomic macOS Stealer (AMOS).

Praktyczne konsekwencje / ryzyko

  1. Kradzież danych uwierzytelniających i tokenów
    Infostealery klasy Vidar/AMOS typowo polują na dane przeglądarek, menedżerów haseł, portfeli krypto, komunikatorów itd. W kampanii dodatkowo dochodzi ryzyko przejęcia materiałów do logowania, które potem można monetyzować lub użyć do dalszych włamań.
  2. Bypass antyfraud/MFA przez proxy „z hosta ofiary”
    GhostSocks buduje warstwę „wiarygodnego ruchu” dla napastnika, co w praktyce zwiększa skuteczność przejęć kont i omijania mechanizmów ryzyka.
  3. Eksfiltracja sekretów z narzędzi AI/agentów
    Huntress podkreśla, że nawet przy legalnej instalacji OpenClaw konfiguracje mogą zawierać wrażliwe dane (API keys, tokeny, hasła). Infostealer na zainfekowanej stacji może je po prostu zebrać.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i zespołów IT (szybkie „must do”)

  • Bookmarkuj oficjalne źródła (repo/strony projektu) i instaluj wyłącznie z nich — nie polegaj na wyszukiwaniu „za każdym razem”.
  • Nie uruchamiaj poleceń typu curl|bash / „wklej do Terminala” z README, jeśli nie potrafisz samodzielnie zweryfikować, co pobierasz i wykonujesz (hash, podpis, źródło, historia repo).
  • Weryfikuj reputację repozytorium: data utworzenia konta/org, historia commitów, spójność kodu źródłowego z release’ami, podpisy, powiązanie z oficjalnym projektem.

Detekcja i reakcja (jeśli podejrzewasz kompromitację)

  • Na Windows sprawdź: nietypowe zadania Harmonogramu, reguły firewalla, procesy o „installerowych” nazwach, podejrzane połączenia wychodzące; uruchom pełny skan EDR/Defender. (Kampania była wykrywalna i w analizowanym przypadku pliki były kwarantannowane przez rozwiązania Microsoft).
  • Rotuj hasła i tokeny (zwłaszcza przeglądarkowe, API keys, tokeny sesji) oraz włącz/utwardź MFA tam, gdzie to możliwe — przy założeniu, że infostealer mógł pozyskać ciasteczka/tokenty.
  • Jeśli używasz OpenClaw/agentów AI: traktuj pliki konfiguracyjne jak „sekrety produkcyjne” (min. uprawnienia, separacja kont, trzymanie kluczy w menedżerze sekretów, ograniczenie dostępu na stacji roboczej).

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

  • Ten incydent pokazuje zmianę taktyki: nie trzeba „hakować” modelu ani prowadzić skomplikowanego prompt injection. Wystarczy odpowiednio „opakować” fałszywe repo na zaufanej platformie i sprawić, by system odpowiedzi AI uznał je za relewantne. Huntress zestawia to z wcześniejszymi kampaniami wykorzystującymi mechanizmy AI/udostępniania treści do socjotechniki, ale tu kluczowe było samo „zaufane hostowanie” na GitHubie + widoczność w Bing AI.
  • Równolegle ekosystem OpenClaw bywa nadużywany także przez złośliwe „skills”/rozszerzenia, co wzmacnia tezę, że agentic AI + lokalne uprawnienia + społecznościowy ekosystem dystrybucji to mieszanka wymagająca twardych kontroli bezpieczeństwa.

Podsumowanie / kluczowe wnioski

  • „AI w wyszukiwarce” potrafi zwiększyć skuteczność klasycznych podszyć, bo nadaje im pozór autorytetu.
  • GitHub jako hosting podnosi wiarygodność w oczach użytkowników, a kopiowanie legalnego kodu wzmacnia kamuflaż.
  • Najgroźniejszy miks w tej kampanii to infostealer + proxy (GhostSocks): kradzież materiału do logowania i natychmiastowa możliwość „wejścia jako ofiara” z jej własnego hosta.
  • Jeśli instalujesz popularne narzędzia (zwłaszcza agentów AI): instalacja = procedura bezpieczeństwa, nie „kliknięcie z wyszukiwarki”.

Źródła / bibliografia

  1. BleepingComputer – opis incydentu i elementów ładunku (Windows/macOS, Vidar, GhostSocks). (BleepingComputer)
  2. Huntress – analiza kampanii (okno 2–10 lutego 2026, Stealth Packer, GhostSocks, AMOS, mechanika Bing AI). (Huntress)
  3. The Register – podsumowanie roli Bing AI i GitHuba w dystrybucji fałszywych installerów. (theregister.com)
  4. Trend Micro – kontekst zagrożeń AMOS/kradzieży danych na macOS (tło rodzinne). (www.trendmicro.com)
  5. The Verge – szerszy kontekst ryzyk w ekosystemie OpenClaw (skills/rozszerzenia). (The Verge)