Archiwa: Malware - Strona 283 z 288 - Security Bez Tabu

Tag: Malware

Star Blizzard (Coldriver) porzuca LOSTKEYS. Nowy łańcuch infekcji z backdoorem MAYBEROBOT i downloaderem NOROBOT

Wprowadzenie do problemu / definicja luki

Rosyjska grupa APT Star Blizzard (aliasy: Coldriver, Seaborgium, Callisto, UNC4057) błyskawicznie zretoolowała arsenał po publicznym ujawnieniu złośliwego oprogramowania LOSTKEYS w maju 2025. Zamiast niego obserwowany jest nowy łańcuch infekcji oparty na downloaderze NOROBOT i finalnym backdoorze MAYBEROBOT (po drodze pojawił się krótkotrwale YESROBOT). Ataki nadal wykorzystują socjotechnikę ClickFix z fałszywą stroną CAPTCHA („I’m not a robot”), ale porzucają wcześniejszy, wieloetapowy łańcuch oparty na PowerShell i LOSTKEYS. Źródła Google Threat Intelligence (GTIG) i relacje branżowe potwierdzają, że od publikacji z maja nie zaobserwowano ponownego użycia LOSTKEYS.

W skrócie

  • Zmiana TTP w 5 dni: Coldriver przestał używać LOSTKEYS w ciągu pięciu dni od publicznej analizy i uruchomił nowe „rodziny” malware.
  • Nowy łańcuch: NOROBOT (pobranie następnego etapu, utrwalenie) → historycznie YESROBOT (Python backdoor) → MAYBEROBOT (lekki, obfuskowany PowerShell backdoor; 3 komendy).
  • Wejście socjotechniczne: nadal ClickFix + fałszywa CAPTCHA, zachęcająca do uruchomienia DLL przez rundll32.
  • Cele: osoby i organizacje „high value” (NGO, doradcy polityczni, kręgi eksperckie i rządowe w państwach zachodnich).
  • Tempo rozwoju: aktywne modyfikacje łańcucha i NOROBOT (rotacja infrastruktury, zmiany nazw plików/eksportów, podział kluczy kryptograficznych).

Kontekst / historia / powiązania

W maju 2025 GTIG opisał LOSTKEYS – kradnący pliki i informacje systemowe komponent Coldrivera, dostarczany m.in. przez mechanizm ClickFix. Po publikacji zespół Google nie rejestrował już użycia LOSTKEYS; w jego miejsce pojawił się zestaw narzędzi „ROBOT” (NOROBOT/YESROBOT/MAYBEROBOT). Temat podjęły m.in. The Record, Dark Reading oraz SecurityWeek, wskazując, że to przykład szybkiego „pivotu” APT po „spaleniu” kampanii.

Analiza techniczna / szczegóły luki

Wejście (socjotechnika): ClickFix + CAPTCHA

  • Strona-lurka podszywa się pod zasób dla środowisk obywatelskich/think tanków. Użytkownik proszony jest o „weryfikację, że nie jest robotem”, co pobiera DLL i instruuje do uruchomienia przez rundll32 (np. artefakty nazw „iamnotarobot.dll”, eksport humanCheck).

Etap 1: NOROBOT (aka BAITSWITCH wg Zscaler)

  • Rola: downloader i przygotowanie środowiska, łączność z hard-coded C2, utrwalenie.
  • Ewolucja: od wersji „głośnych” (instalacja pełnego Python 3.8, zadania harmonogramu, BITS do pobrania modułów .py) do uproszczonych wariantów, a następnie ponownie „utajnionych” przez podział kluczy kryptograficznych i reintrodukcję etapów pośrednich.

Etap 2 (krótkotrwale): YESROBOT (Python backdoor)

  • Minimalny backdoor wykonujący polecenia Python pobierane z C2; wymagał pełnego interpretera, co zwiększało wykrywalność. Zaobserwowany jedynie incydentalnie w maju; szybko porzucony.

Etap 3: MAYBEROBOT (aka SIMPLEFIX) – finalny backdoor

  • PowerShell, ciężko obfuskowany, 3 komendy: pobierz/uruchom z URL, wykonaj polecenie przez cmd.exe, wykonaj blok PowerShell; potwierdzenia i wyniki wysyłane na inne ścieżki C2.
  • Cel: zastąpić YESROBOT czymś lżejszym i bardziej elastycznym, bez potrzeby instalowania Pythona.

Tempo i OPSEC

  • Coldriver rotuje infrastrukturę, modyfikuje nazwy plików/eksportów, ścieżki i konstrukcję URL-i; raz upraszcza, raz komplikuje łańcuch, utrudniając korelację. Od czerwca do września 2025 obserwowano wiele wariantów NOROBOT, natomiast MAYBEROBOT pozostawał stabilny (grupa koncentruje się na ukryciu „wejścia”, mniej na finalnym backdoorze).

Praktyczne konsekwencje / ryzyko

  • User-assisted execution: ataki obchodzą tradycyjne filtry poczty (plik nie zawsze przechodzi przez MTA), a nacisk pada na rundll32 uruchamiany przez użytkownika.
  • Niska sygnaturowość: miks lekko zmienianych łańcuchów, rotacja C2 i kluczy utrudnia IOC-based detection. Preferowane są behawioralne telemetrie EDR/NDR (nietypowe uruchomienia rundll32, BITS, obfuskowany PowerShell, nowe zadania harmonogramu).
  • Targeting: wysoka selektywność odbiorców i serwer-side filtering zmniejszają „szum” i widoczność kampanii w szerokich telemetriach.

Rekomendacje operacyjne / co zrobić teraz

Prewencja i twardnienie stacji

  1. Zablokuj typowy wektor rundll32:
    • AppLocker/WDAC: deny rundll32.exe uruchamianie DLL z obszarów użytkownika (%TEMP%, %APPDATA%, %LOCALAPPDATA%).
    • ASR: reguły ograniczające LOLBin (rundll32, bitsadmin, reg.exe) oraz uruchamianie skryptów PS z pobranych lokalizacji.
  2. PowerShell Constrained Language Mode oraz Script Block/Module Logging + AMSI – rejestrować i blokować obfuskowane bloki.
  3. BITS i Scheduled Tasks: monitoruj tworzenie zadań („System health check”, nietypowe triggery „At logon”) oraz użycie bitsadmin/Start-BitsTransfer.

Detekcja (idee reguł/Sigma)

  • Rundll32 + URL w argumencie / DLL z folderów profilu.
  • Proces łańcuchowy: rundll32.exe → powershell.exe / cmd.exe; pythonw.exe pojawiający się pod %APPDATA%\Python38-64\.
  • Rejestr: nietypowe klucze binarne pod HKCU\Software\Classes.* (np. .pietas/ratio).
  • Sieć: anomalia HTTP(S) do świeżych domen, ścieżki ACK/RESULT charakterystyczne dla MAYBEROBOT. (Wskazówki techniczne opisane w raporcie GTIG; Google publikuje IoC/YARA).

IR / łagodzenie skutków

  • Zidentyfikuj hosty z logon scripts ustawionymi przez PS, przeglądnij RecentFileCache.bcf/ShimCache pod kątem „iamnotarobot.dll”.
  • Skoreluj alerty Safe Browsing/Gmail Government-backed attacker alerts (jeśli używacie Google Workspace).
  • Jeśli artefakty Pythona zostały znalezione, przeprowadź triage pamięci, sprawdź harmonogram zadań i usługi użytkownika; odizoluj host, rotuj poświadczenia, przeprowadź TH na luki w dostępie do skrzynek e-mail (możliwy wcześniejszy kompromis phishingowy).

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

  • Względem LOSTKEYS (maj 2025): porzucenie długiego łańcucha PS na rzecz DLL+rundll32 i fałszywej CAPTCHA; rotacja do lekkiego backdoora PS.
  • Względem innych rosyjskich APT (np. APT28/NotDoor): różne wektory (Outlook/NotDoor vs. ClickFix/CAPTCHA) i inne docelowe profile ofiar, ale wspólny mianownik to szybka ewolucja TTP i modularność narzędzi. (Wniosek syntetyczny na bazie przeglądu doniesień branżowych.)

Podsumowanie / kluczowe wnioski

  • Coldriver zareagował błyskawicznie: 5 dni po ujawnieniu LOSTKEYS wdrożono nowy łańcuch (NOROBOT → MAYBEROBOT).
  • Socjotechnika jest „kluczem”: fałszywe CAPTCHA skutecznie skłaniają użytkowników do samodzielnego uruchomienia DLL.
  • Detekcja behawioralna > IOC: stale zmieniane artefakty i łańcuchy wymagają skupienia na technikach, nie sygnaturach.
  • Higiena narzędzi w Windows: rundll32/bitsadmin/PowerShell to dziś newralgiczne LOLBiny – ograniczaj, loguj i koreluj.

Źródła / bibliografia

  1. Google Threat Intelligence Group – To Be (A Robot) or Not to Be: New Malware Attributed to Russia State-Sponsored COLDRIVER (20 października 2025). Kluczowy raport techniczny z IoC i opisem NOROBOT/YESROBOT/MAYBEROBOT. (Google Cloud)
  2. SecurityWeek – Russian APT Switches to New Backdoor After Malware Exposed by Researchers (22 października 2025). Przegląd zmian TTP Star Blizzard po publikacji LOSTKEYS. (SecurityWeek)
  3. The Record (Recorded Future News) – Google finds Russian state hackers replacing burned malware with new tools (21 października 2025). Kontekst czasowy (5 dni), nazwy rodzin i agresywność kampanii. (The Record from Recorded Future)
  4. Dark Reading – ColdRiver Drops Fresh Malware on Targets (20 października 2025). Analiza trendu „pivotu” APT i opis łańcucha. (Dark Reading)
  5. CSO Online – ‘I am not a robot’: Russian hackers use fake CAPTCHA lures to deploy espionage tools (22 października 2025). Perspektywa obronna: detekcje behawioralne, ryzyka user-assisted. (CSO Online)

Irańska grupa MuddyWater atakuje ponad 100 instytucji rządowych kampanią z backdoorem Phoenix v4

Wprowadzenie do problemu / definicja luki

Państwowo wspierana irańska grupa MuddyWater (znana również jako Static Kitten, Mercury/Mango Sandstorm, Seedworm) przeprowadziła od 19 sierpnia ukierunkowaną kampanię spear-phishingową na rzecz cyber-szpiegostwa przeciwko ponad 100 podmiotom rządowym w regionie MENA. Ataki dostarczały wersję 4 backdoora Phoenix, nowy wariant własnego implantu tej grupy. Wiadomości wysyłano z przejętej skrzynki pocztowej obsługiwanej przez usługę NordVPN, co zwiększało wiarygodność korespondencji. Cele obejmowały m.in. ambasady, misje dyplomatyczne, ministerstwa spraw zagranicznych i konsulaty. Kampanię opisali badacze Group-IB, a szczegóły potwierdziły niezależne redakcje bezpieczeństwa.

W skrócie

  • Skala: >100 instytucji rządowych w MENA (gł. placówki dyplomatyczne).
  • Wejście: spear-phishing z przejętego mailboxa, dostęp przez NordVPN.
  • Nośnik: dokumenty Microsoft Word z makrami VBA wymuszające „Enable Content”.
  • Łańcuch: VBA → loader FakeUpdate (AES) → Phoenix v4 w C:\ProgramData\sysprocupdate.exe z trwałością przez rejestr i mechanizmy COM.
  • Możliwości Phoenix v4: rozpoznanie hosta, łączność WinHTTP z C2, interaktywny shell, upload/download plików, zmiana interwału beaconingu.
  • Dodatkowe narzędzia: niestandardowy stealer przeglądarek (Chromium/Brave/Chrome/Edge/Opera), a także PDQ i Action1 RMM na infrastrukturze C2.

Kontekst / historia / powiązania

MuddyWater to grupa APT przypisywana irańskiemu MOIS (Ministerstwo Wywiadu i Bezpieczeństwa) i aktywna co najmniej od 2017 r., konsekwentnie atakująca instytucje rządowe, telekomy i sektor energetyczny w wielu regionach. Jej taktyki obejmują phishing, nadużywanie legalnych narzędzi administracyjnych i stałą ewolucję własnego malware. Globalne organy (NSA/CISA/FBI/DC3) w 2025 r. ostrzegały przed wzmożoną aktywnością irańskich aktorów wobec sieci rządowych i infrastruktury krytycznej.

Analiza techniczna / szczegóły luki

Wejście i inicjalny wektor. Atak rozpoczynał się od e-maili z rozmytym dokumentem Word i instrukcją włączenia makr. Po zezwoleniu VBA dekodował i zapisywał loader FakeUpdate, który odszyfrowywał (AES) osadzony ładunek Phoenix v4 i uruchamiał go (code injection we własny proces). Dostęp do przejętego mailboxa realizowano przez NordVPN, co utrudniało szybkie powiązanie aktywności ze znanymi adresami.

Instalacja i trwałość. Phoenix v4 zapisywany był jako
C:\ProgramData\sysprocupdate.exe, tworzył mutex, a następnie utrwalał się przez modyfikacje rejestru (konfiguracje dla bieżącego użytkownika) oraz dodatkowy mechanizm COM-based persistence (nowość vs. v3).

Komunikacja i polecenia. Implant profiluje host (nazwa komputera, domena, wersja Windows, użytkownik), nawiązuje łączność z C2 przez WinHTTP i okresowo odpytuje o polecenia. Zidentyfikowano m.in. komendy: 65 – Sleep, 68 – Upload, 85 – Download, 67 – Start shell, 83 – Update sleep interval.

Infrastruktura i narzędzia towarzyszące. Na C2 (m.in. adres z klasy 159.198.36[.]115) badacze znaleźli PDQ (dystrybucja oprogramowania), Action1 RMM oraz custom stealer przeglądarek Chromium (kradzież bazy logowań i master key do deszyfracji). To typowy dla MuddyWater miks własnego kodu i legalnych narzędzi w celu skrytości i utrzymania dostępu.

Zmiana TTP względem ostatnich kampanii. Ciekawym zwrotem jest powrót do makr Office – techniki popularnej kilka lat temu, ograniczonej po domyślnym wyłączeniu makr przez Microsoft. W przeszłości MuddyWater wykorzystywał m.in. ClickFix i inne wektory socjotechniczne.

Praktyczne konsekwencje / ryzyko

  • Ryzyko strategiczne: Dostęp do skrzynek dyplomatycznych i stacji roboczych w MSZ/ambasadach umożliwia kradzież korespondencji, dokumentów i danych uwierzytelniających, a także ruch boczny do sieci wewnętrznych.
  • Ryzyko operacyjne: Wykorzystanie RMM (PDQ/Action1) i niestandardowych stealerów ułatwia utrzymanie długotrwałej obecności i zacieranie śladów wśród legalnych operacji IT.
  • Ryzyko reputacyjne i dyplomatyczne: Ujawnienia mogą prowadzić do kryzysów komunikacyjnych i eskalacji napięć w relacjach między państwami. (Wniosek na bazie profilu celów i wcześniejszych ostrzeżeń o aktywności irańskich APT.)

Rekomendacje operacyjne / co zrobić teraz

  1. Twarde zasady dla makr Office: globalnie blokuj VBA dla dokumentów z internetu; zezwalaj tylko na podpisane, zaufane źródła (GPO/Intune). Monitoruj zdarzenia uruchamiania makr i nietypowe zapisy do %ProgramData%.
  2. EDR/XDR & reguły behawioralne: wykrywaj WinHTTP beaconing, modyfikacje rejestru dla shell/restartu powłoki i proces injection FakeUpdate → Phoenix. Dodaj reguły na ścieżkę C:\ProgramData\sysprocupdate.exe.
  3. Poczta i tożsamość: wymuś MFA, chroń dostęp do skrzynek (zwłaszcza kont wspólnych), stosuj detekcję anomalii logowania (VPN, geo, user-agent) i DMARC/DKIM/SPF. Zwróć uwagę na przejęte skrzynki wykorzystywane przez VPN komercyjny.
  4. Filtrowanie załączników i sandboxing: izoluj dokumenty Office z makrami, stosuj detonację i reguły blokujące „Enable Content” lures.
  5. Zarządzanie przeglądarkami i sekretami: twarde polityki Login Data i Local State (Chromium), ochrona master key DPAPI, detekcja dostępu do baz przeglądarkowych poza procesami browsera.
  6. Higiena RMM: inwentaryzacja i allowlist PDQ/Action1; blokuj „shadow IT” RMM; alarmuj na nowe instalacje agentów.
  7. Hunt & Threat Intel: poluj proaktywnie na artefakty Phoenix/FakeUpdate i wskaźniki C2; śledź biuletyny NSA/CISA dotyczące irańskich aktorów i ich TTP.

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

  • MuddyWater vs. Peach/Kitten rodziny: W odróżnieniu od Peach Sandstorm (APT33), który ostatnio rozwijał złożony backdoor „Tickler”, MuddyWater w tej kampanii łączy lekki implant Phoenix v4 z makrami i legalnymi RMM – nacisk na prostotę wejścia i długotrwałe utrzymanie.
  • Powrót do makr kontra nowsze łańcuchy (np. ClickFix): bieżąca fala pokazuje, że nawet „stare” techniki wracają, jeśli zwiększają współczynnik sukcesu na celach urzędowych.

Podsumowanie / kluczowe wnioski

  • Kampania MuddyWater od 19–24 sierpnia szybko dostarczyła Phoenix v4 do >100 odbiorców w administracji publicznej MENA, następnie przeszła do kolejnego etapu (wyłączenie serwera i komponentu C2 24 sierpnia – prawdopodobnie pivot do innych narzędzi).
  • Miks socjotechniki, przejętych skrzynek, makr i RMM pozostaje skuteczny w środowiskach urzędowych.
  • Obrona wymaga kombinacji: polityk makr/MFA, telemetrii EDR, huntingu TTP, oraz kontroli RMM i przepływów pocztowych zgodnych z DMARC/DKIM/SPF.

Źródła / bibliografia

  • BleepingComputer: „Iranian hackers targeted over 100 govt orgs with Phoenix backdoor” (22 października 2025). (BleepingComputer)
  • The Hacker News: „Iran-Linked MuddyWater Targets 100+ Organisations in Global Espionage Campaign” (22 października 2025). (The Hacker News)
  • Dark Reading: „MuddyWater Targets 100+ Gov Entities in MEA With Phoenix Backdoor” (22 października 2025). (Dark Reading)
  • MITRE ATT&CK – G0069 MuddyWater (profil grupy). (MITRE ATT&CK)
  • NSA/CISA/FBI/DC3: „Iranian Cyber Actors May Target Vulnerable U.S. Networks and Entities of Interest” (30 czerwca 2025). (nsa.gov)

Rządowe i przemysłowe serwery na celowniku kampanii „PassiveNeuron” powiązanej z Chinami

Wprowadzenie do problemu / definicja luki

Kaspersky ujawnił aktywną kampanię cyberszpiegowską „PassiveNeuron”, która od grudnia 2024 r. do co najmniej sierpnia 2025 r. celowała w serwery Windows Server w organizacjach rządowych, przemysłowych i finansowych na rynkach Azji, Afryki i Ameryki Łacińskiej. Atakujący uzyskiwali zdalne wykonanie kodu (RCE), instalowali web-shelle i wdrażali niestandardowe implanty do eksfiltracji danych oraz dalszej penetracji środowisk. Atrybucja jest ostrożnie przypisana do aktora chińskojęzycznego (niska pewność). Źródła branżowe (SecurityWeek, Dark Reading) potwierdzają wyniki Kaspersky.

W skrócie

  • Wektor: serwery Windows (często z komponentem Microsoft SQL Server), potem web-shell i łańcuch loaderów DLL.
  • Implanty: dwa nieznane wcześniej – Neursite (modularny backdoor C++) i NeuralExecutor (.NET loader) – oraz Cobalt Strike.
  • C2: w nowszych próbkach wykorzystanie techniki „dead drop resolver” z GitHub do pozyskania adresów C2.
  • Kamuflaż: nadmuchane pliki DLL (>100 MB) umieszczane w System32 dla trwałości i uniknięcia detekcji.
  • Zasięg i czas: fala 12.2024–08.2025; wcześniejsze próby z czerwca 2024 r., pauza ~6 mies. i powrót.
  • Atrybucja: przesłanki TTP wskazują na chińskojęzycznego aktora (niska pewność).

Kontekst / historia / powiązania

„PassiveNeuron” po raz pierwszy opisano zwięźle w 2024 r. jako kampanię na rządowe serwery z użyciem nieznanych implantów. Po zatrzymaniu rozprzestrzeniania w połowie 2024 r. aktywność zniknęła, by powrócić w grudniu 2024 r. i trwać do sierpnia 2025 r. Media branżowe odnotowują wzmiankę o celowaniu w serwery (w tym SQL) i sektorach wrażliwych. Wskazówki atrybucyjne z 2025 r. (m.in. dead drop na GitHub z charakterystycznymi delimitrami) korelują ze wzorcami obserwowanymi wcześniej u grup chińskojęzycznych (np. kampania EastWind).

Analiza techniczna / szczegóły kampanii

Początkowy dostęp i RCE

  • W co najmniej jednym incydencie uzyskano RCE poprzez komponenty Microsoft SQL Server na serwerze Windows. Dokładny mechanizm bywa niejasny; Kaspersky wymienia typowe ścieżki: exploity w samym serwerze, SQL injection w aplikacjach korzystających z bazy lub brute-force/kradzież poświadczeń DBA. Próba szybkiego ugruntowania przyczółka to wdrożenie ASPX web-shella.

Łańcuch loaderów i trwałość

  • Gdy web-shell zawiódł, operatorzy wdrażali zaawansowane implanty poprzez łańcuch loaderów DLL umieszczanych w C:\Windows\System32. Pliki były sztucznie „napompowane” (ponad 100 MB), co utrudniało analizę i detekcję sygnaturową. Loader uruchamiał się automatycznie przy starcie systemu.

Neursite (C++ modular backdoor)

  • Obsługa wielu protokołów C2: TCP/SSL/HTTP/HTTPS, łączenie do serwera C2 bezpośrednio lub przez host pośredniczący; możliwość proxy ruchu przez inne zainfekowane maszyny (ułatwienie ruchu lateralnego), zbieranie informacji o systemie, zarządzanie procesami, ładowanie pluginów (shell, operacje na FS, gniazda TCP).

NeuralExecutor (.NET)

  • Loader .NET, obfuskowany ConfuserEx, wielokanałowa komunikacja (TCP/HTTP/HTTPS/named pipes/WebSockets), główna funkcja: doładowywanie i wykonywanie kolejnych ładunków .NET. W wydaniu z 2025 r. pobierał konfigurację/C2 z pliku na GitHub (dead drop resolver) – struny wydzielone specyficznymi delimiterami, dekodowane Base64 i odszyfrowywane AES.

Cobalt Strike

  • Stosowany jako komponent do post-exploitation i manewrów wewnątrz sieci.

Atrybucja i „false flags”

  • W próbkach z 2024 r. widoczne były ciągi w cyrylicy („Супер обфускатор”) – najpewniej fałszywy trop wprowadzony podczas obfuskacji. Sygnatura PDB powiązana wcześniej przez Cisco Talos z działaniami APT41 pojawiła się w jednej z bibliotek (imjp14k.dll), ale kontekst nie jest rozstrzygający. Kaspersky wskazuje niski poziom pewności atrybucji do aktora chińskojęzycznego, opierając się przede wszystkim na TTP.

Praktyczne konsekwencje / ryzyko

  • Ryzyko eksfiltracji danych i długotrwałego utrzymania w sieci (implantly + Cobalt Strike).
  • Ryzyko pivotu z serwerów do krytycznych zasobów (proxy w Neursite, lateral movement).
  • Uderzenie w organizacje o wysokiej wartości (rządy, przemysł, finanse), także z infrastrukturą OT po stronie serwerowej (np. ERP/SCADA back-ends), co wpisuje się w szersze trendy aktywności aktorów powiązanych z ChRL.

Rekomendacje operacyjne / co zrobić teraz

Twarde kontrolki na warstwie serwerów i SQL

  1. Ogranicz ekspozycję serwerów Windows/SQL do Internetu; wymuś MFA i sieciowe listy kontroli dostępu (NACL) / VPN z silnym uwierzytelnianiem dla administracji.
  2. Patching & hardening: aktualizacje Windows Server/SQL; wyłącz zbędne usługi; egzekwuj TLS i szyfrowanie w tranzycie; polityki haseł DBA (długość, rotacja, brak domyślnych). (Najlepsze praktyki wynikają pośrednio z analizy Kaspersky dot. typowych wektorów.)
  3. WAF + bezpieczeństwo aplikacji: testy pod kątem SQLi, reguły blokujące nietypowe kwerendy administracyjne z warstwy aplikacyjnej.

Detekcja i reagowanie
4. Monitoruj artefakty:

  • Nieoczekiwane ASPX web-shelle, pliki DLL w System32 o rozmiarach >100 MB.
  • Ruch wychodzący do GitHub/Gist pobierający konfiguracje (anomalia proxy/IDS).
  • Wskaźniki z najnowszego zestawu IoC opublikowanego przez Kaspersky (hash’e loaderów, imjp14k.dll).
  1. EDR/XDR z regułami na: uruchamianie rundll32/regsvr32 z nietypowymi parametrami, ładowanie .NET assemblies z pamięci, zachowania Cobalt Strike (beaconing, named pipes). (Wnioski z TTP zawartych w raportach.)
  2. Segmentacja i egress filtering: zablokuj nieużywane protokoły, kontroluj HTTP/HTTPS z serwerów bazodanowych, wprowadzaj „deny-by-default” dla wyjść sieciowych. (Wnioski operacyjne na podstawie sposobu komunikacji implantów.)
  3. Hunting: reguły YARA/Sigma oparte na descriptorach Neursite/NeuralExecutor; korelacje logów SQL (np. xp_cmdshell, nieautoryzowane sp_configure, nietypowe EXEC). (Oparte na opisie RCE przez SQL i ładunków .NET.)

Gotowość incydentowa
8. Plany izolacji serwerów, kopie zapasowe offline, ćwiczenia tabletop dla scenariusza „serwer centralny (SQL) jako patient zero”.

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

  • Dead drop resolver na GitHub był wcześniej widoczny w kampaniach przypisywanych aktorom chińskojęzycznym (np. EastWind), co odróżnia PassiveNeuron od wielu operacji, które korzystają z jednoznacznych, własnych serwerów C2.
  • Skupienie na serwerach (zwłaszcza SQL) i nadmuchane DLL-e w System32 to wyróżniki TTP tej kampanii względem typowych łańcuchów opartych na spear-phishingu czy złośliwych sterownikach.

Podsumowanie / kluczowe wnioski

„PassiveNeuron” to konsekwentnie prowadzona, ukierunkowana kampania na serwery Windows, korzystająca z dwóch niestandardowych implantów i technik utrudniających detekcję (dead drop na GitHub, ogromne DLL-e, łańcuch loaderów). Nawet przy niskiej pewności atrybucji, zbieżność TTP z wcześniejszymi operacjami chińskojęzycznymi powinna skłonić SOC do podwyższonej czujności, szczególnie w organizacjach z krytyczną infrastrukturą i systemami bazodanowymi eksponowanymi do sieci.

Źródła / bibliografia

  1. SecurityWeek — „Government, Industrial Servers Targeted in China-Linked ‘PassiveNeuron’ Campaign”, 21 października 2025. (SecurityWeek)
  2. Kaspersky Securelist — „PassiveNeuron: a sophisticated campaign targeting servers of high-profile organizations”, 21 października 2025 (GReAT). Zawiera IoC i szczegóły TTP. (securelist.com)
  3. Kaspersky (komunikat prasowy) — „Kaspersky identifies PassiveNeuron cyberespionage campaign…”, 21 października 2025. (Kaspersky)
  4. Dark Reading — „‘PassiveNeuron’ Cyber Spies Target Orgs With Custom Malware”, 21 października 2025. (Dark Reading)
  5. The Hacker News — „Researchers Identify PassiveNeuron APT Using Neursite and NeuralExecutor…”, 22 października 2025. (The Hacker News)

Atak łańcuchowy na rozszerzenia VS Code z malware „GlassWorm”. Niewidzialny kod, C2 na blockchainie i samopropagacja

Wprowadzenie do problemu / definicja luki

W połowie października 2025 r. wykryto wysoce zaawansowany atak łańcuchowy na ekosystem rozszerzeń dla VS Code. Kampania, nazwana GlassWorm, infekuje rozszerzenia publikowane w OpenVSX (alternatywny, otwarty rejestr) i w pojedynczych przypadkach w Visual Studio Code Marketplace. Celem jest kradzież tokenów NPM/GitHub/Git (i innych), drenaż środków z 49 wtyczek kryptowalutowych, a także przejęcie stacji roboczych deweloperów jako węzłów infrastruktury przestępczej (SOCKS proxy, ukryty VNC). Atak rozpowszechnia się sam — używa przejętych poświadczeń do kompromitowania kolejnych rozszerzeń/pakietów. Pierwsze zainfekowane wydania w OpenVSX pojawiły się 17 października 2025 r.; do 20–21 października potwierdzono ok. 35,8 tys. instalacji złośliwych wersji.

W skrócie

  • Wejście: zainfekowane rozszerzenia VS Code w OpenVSX (i jeden przypadek w oficjalnym marketplace Microsoftu).
  • Technika ukrycia: „niewidzialny kod” oparty o Unicode variation selectors – złośliwy JS nie renderuje się w edytorze i znika w diffach.
  • C2: łańcuch Solana (memo w transakcjach zawiera wskaźnik do ładunku) + Google Calendar jako zapasowy kanał + bezpośrednie IP.
  • Zdolności: exfiltracja sekretów (NPM, GitHub, OpenVSX, Git), drenaż portfeli krypto (49 rozszerzeń), SOCKS proxy, HVNC, P2P (WebRTC), DHT, samopropagacja.
  • Skala: min. 35,8 tys. instalacji; co najmniej 7 rozszerzeń w OpenVSX na starcie, kolejne dołączane w toku.

Kontekst / historia / powiązania

GlassWorm pojawia się miesiąc po kampanii Shai Hulud (samopropagujący się robak w ekosystemie npm), również opisanej przez Koi Security. Wcześniej w 2025 r. społeczność zwracała uwagę na ryzyka marketplace’ów VS Code/OpenVSX (m.in. wycieki sekretów i słabe procesy publikacji). Choć podatność procesu publikacji w OpenVSX zgłoszona w maju i załatana w czerwcu nie miała potwierdzonego nadużycia, łańcuch dostaw rozszerzeń pozostaje atrakcyjny dla atakujących. GlassWorm pokazuje kolejny krok — połączenie samopropagacji z infrastrukturą C2 odporną na „takedown”.

Analiza techniczna / szczegóły luki

Niewidzialny kod (Unicode):
Złośliwe fragmenty są wstrzykiwane z użyciem Unicode variation selectors, które nie generują widocznego znaku. W efekcie w edytorze i w przeglądarce diffów widać „puste” linie; interpreter JS nadal wykonuje payload. To znacząco obniża skuteczność przeglądu kodu i części narzędzi SAST.

  1. Solana – malware wyszukuje transakcje z określonego portfela i odczytuje memo z zaszytym (base64) linkiem do kolejnego etapu; zmiana ładunku to publikacja nowej transakcji (tani, dynamiczny i odporny na usunięcie kanał).
  2. Google Calendar – tytuł wydarzenia zawiera kolejny wskaźnik URL (backup C2).
  3. Bezpośrednie IP – serwer serwujący zaszyfrowane ładunki, z kluczem AES przekazywanym w nagłówkach HTTP.

Łańcuch infekcji i moduły:

  • Etap kradzieży: pozyskanie tokenów NPM/GitHub/Git/OpenVSX + dane z 49 rozszerzeń portfeli kryptowalut.
  • Samopropagacja: użycie skradzionych poświadczeń do publikacji zainfekowanych wersji pakietów/rozszerzeń.
  • „ZOMBI”: aktywacja SOCKS proxy, WebRTC P2P, BitTorrent DHT do dystrybucji komend oraz HVNC (ukryty zdalny pulpit) — pełny, niewidoczny dostęp do stacji roboczej.

Skala i czas:

  • Start: 17 października 2025 – 7 rozszerzeń OpenVSX.
  • 18–21 października: ~35,8 tys. instalacji, kolejne rozszerzenia aktywnie serwowały malware; wykryto też pojedyncze zainfekowane rozszerzenie w Microsoft VS Code Marketplace (usunięte po zgłoszeniu).

Praktyczne konsekwencje / ryzyko

  • Kompromitacja łańcucha dostaw: każdy zainfekowany deweloper staje się wektorem do przejęcia następnych rozszerzeń i repozytoriów.
  • Utrata sekretów i eskalacja: wyciek tokenów repozytoryjnych i rejestrów pakietów = możliwość publikacji trojanizowanych wersji oprogramowania.
  • Pivot do sieci wewnętrznej: HVNC + SOCKS czynią z laptopów deweloperów ukryte backdoory i węzły pośredniczące.
  • Trwałość i odporność na wyłączenie: C2 oparte na blockchainie i usługach chmurowych utrudnia neutralizację i blokowanie.

Rekomendacje operacyjne / co zrobić teraz

Traktuj to jako aktywny incydent, nie tylko „podatność”. Poniżej lista działań priorytetowych:

  1. Natychmiastowa higiena i izolacja
  • Odłącz stacje deweloperskie od sieci firmowej; zablokuj wyjścia do: znanych IoC (np. 217.69.3.218, 140.82.52.31), RPC Solany i wskazanego wydarzenia Google Calendar (blok domenowy/aplikacyjny).
  • Tymczasowo wyłącz auto-aktualizacje rozszerzeń w IDE; wstrzymaj instalacje z OpenVSX i niezweryfikowanych marketplace’ów.
  1. Łańcuch tożsamości i sekretów
  • Rotacja wszystkich sekretów używanych na stacjach deweloperskich: tokeny NPM/GitHub/Git/OpenVSX/VS Code, hasła, klucze SSH; unieważnij sesje.
  • Wymuś re-login po rotacji, włącz obowiązkowo MFA i zasady urządzeń zaufanych.
  1. Triaga i detekcja
  • Przeskanuj hosty pod kątem: procesów HVNC, uruchomionych SOCKS proxy, komponentów WebRTC P2P, wpisów autostartu HKCU/HKLM...\Run, artefaktów z listy IoC Koi.
  • Monitoruj nietypowe połączenia wychodzące (Solana RPC, kalendarz Google, nietypowe IP HTTP z nagłówkami niestandardowymi).
  1. Remediacja hostów
  • Pełny reimage zaufanym obrazem → odtworzenie środowiska developerskiego → dopiero potem przywracanie dostępu do repozytoriów/registrów. (Rekomendowane przez badaczy w związku z HVNC i trwałością modułów).
  1. Zarządzanie ryzykiem marketplace’ów
  • Wprowadź allow-listę rozszerzeń (zarządzanie katalogiem dopuszczonych dodatków), SBOM dla pluginów oraz cykliczny przegląd autorów/łańcucha wydawniczego.
  • Rozważ blokadę OpenVSX w sieci korporacyjnej do czasu pełnego wyjaśnienia; zezwalaj wyłącznie na oficjalny marketplace i/lub wewnętrzne mirrory z walidacją.
  1. Długofalowo
  • Włącz skanery sekretów i SCA dla rozszerzeń i pakietów developerskich; egzekwuj zasady „no tokens in builds”.
  • Edukuj dev-teamy o wektorach „niewidzialnego kodu” (Unicode), kontroluj diffy w trybie view raw bytes lub z narzędziami wykrywającymi znaki kontrolne.

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

  • Shai Hulud (npm, IX 2025) – pierwszy robak samopropagujący w ekosystemie npm (kradł tokeny i publikował zainfekowane wersje). GlassWorm adaptuje ten model do OpenVSX/VS Code i dodaje niewidzialny kod + C2 na blockchainie + HVNC (większa odporność i wpływ na hosta).
  • WhiteCobra / fale złośliwych rozszerzeń – wcześniejsze kampanie (stealery) bazowały głównie na exfiltracji; GlassWorm tworzy żyjący ekosystem z P2P/DHT/HVNC i realnym „przejęciem” stacji. (Wskazuje to trend eskalacji w marketplace’ach IDE).

Podsumowanie / kluczowe wnioski

GlassWorm to punkt zwrotny dla bezpieczeństwa rozszerzeń IDE: łączy trik steganograficzny (Unicode), C2 odporny na likwidację (Solana/Google Calendar) i robakową samopropagację. Organizacje korzystające z VS Code i pochodnych narzędzi powinny potraktować sprawę jak incydent średnio-/wysokiego ryzyka, nie czekać na listy „złych rozszerzeń” i wdrożyć rotację sekretów + reimage najbardziej narażonych hostów developerskich.

Źródła / bibliografia

  • SecurityWeek: „Supply Chain Attack Targets VS Code Extensions With ‘GlassWorm’ Malware”, 21 października 2025. (SecurityWeek)
  • Koi Security (analiza techniczna), 18 października 2025. (koi.ai)
  • Koi Security (strona incydentu z IoC i aktualizacjami), 20 października 2025. (koi.ai)
  • Dark Reading: „Self-Propagating GlassWorm Attacks VS Code Supply Chain”, 20 października 2025. (Dark Reading)
  • CSO Online/InfoWorld: „Self-propagating worm found in marketplaces for VS Code extensions”, 21 października 2025. (CSO Online)

Microsoft Digital Defense Report 2025: AI przyspiesza ewolucję ataków. Czas porzucić wyłącznie „tradycyjne” zabezpieczenia

Wprowadzenie do problemu / definicja luki

Microsoft opublikował najnowszy Digital Defense Report 2025 (MDDR), obejmujący trendy od lipca 2024 do czerwca 2025. Konkluzja jest jasna: AI stała się mnożnikiem siły zarówno dla obrońców, jak i napastników, a poleganie wyłącznie na klasycznych, „perymetrycznych” kontrolach nie wystarczy wobec skali i szybkości współczesnych kampanii. Ponad połowa ataków z ustalonym motywem była napędzana ekstorcją i ransomware, podczas gdy operacje czysto szpiegowskie to zaledwie kilka procent spraw.

W skrócie

  • Ekstorcja/ransomware >50% incydentów z ustalonym motywem (co najmniej 52%); szpiegostwo ~4%.
  • „Nie włamują się — logują się”: wzrost ataków tożsamościowych i roli infostealerów; 97% ataków na tożsamość to ataki hasłowe.
  • AI przyspiesza: generowanie treści socjotechnicznych, automatyzacja ruchu bocznego, wyszukiwanie luk, real-time evasions; jednocześnie same systemy AI stają się celem (prompt injection, data poisoning).
  • Najczęściej atakowane sektory: administracja publiczna i IT; w TOP10 także badania/akademia, NGO, produkcja krytyczna, transport.
  • Najmocniej dotknięte kraje (H1 2025): USA, UK, Izrael, Niemcy.
  • Wniosek strategiczny: modernizacja zabezpieczeń (identity-first, phishing-resistant MFA), odporność chmury, łańcuchy dostaw i współpraca publiczno-prywatna.

Kontekst / historia / powiązania

Tegoroczny raport to szósta edycja MDDR i odzwierciedla przesunięcie ciężaru z incydentów „czysto technicznych” na zdarzenia wpływające na usługi krytyczne oraz codzienne życie (od szpitali po transport). Microsoft akcentuje, że to już problem całospołeczny, wymagający zarówno modernizacji technologii, jak i konsekwencji polityczno-prawnych wobec agresorów (w tym państw narodowych korzystających z ekosystemu cyberprzestępczego).

Analiza techniczna / szczegóły raportu

1) Motywacja i taktyki

  • Ekstorcja odpowiada za ~33% celów w angażach IR, ludzkie/niszczące ransomware ~19%, a faktyczne wdrożenie ładunku ~8%; czyste szpiegostwo ~4%.
  • Kampanie łączą socjotechnikę z eksploatacją techniczną. Na znaczeniu zyskały ClickFix oraz device code phishing, a nadużycia OAuth/legacy auth/AiTM umożliwiają długotrwały dostęp mimo MFA.

2) Wejście początkowe (Initial Access)

  • Wektor „valid accounts”/kradzione sesje zyskuje, a napastnicy coraz częściej „logują się” dzięki infostealerom i wyciekłym danym uwierzytelniającym. Trwa szybka weaponizacja znanych CVE przeciw usługom wystawionym do Internetu i zdalnym usługom.

3) Sektory i geografia

  • Administracja i IT w czołówce celów; w TOP10 również badania/akademia, NGO, produkcja krytyczna, transport, telco, finanse, zdrowie. Największa koncentracja ataków w USA, UK, Izraelu i Niemczech (H1 2025).

4) AI – miecz obosieczny

  • Napastnicy wykorzystują generatywną AI do skalowania phishingu/socjotechniki, odkrywania luk i adaptacyjnego malware; równocześnie rosną ataki na same systemy AI (prompt injection, data poisoning). Po stronie obrony AI skraca detekcję i reakcję oraz redukuje luki w wykrywaniu.

5) Incydent o potencjale systemowym

  • W lutym 2025 udaremniono atak ransomware na globalnego operatora żeglugi – szyfrowanie zatrzymano po 68 sekundach, a całość rozbito w 14 minut; zdarzenie pokazuje kaskadowe ryzyko dla łańcuchów dostaw.

Praktyczne konsekwencje / ryzyko

  • Tożsamość i sesje są najprostszą drogą wejścia (kradzieże haseł/sesji, kupowanie dostępu). Brak phishing-resistant MFA i kontroli aplikacji/OAuth = podwyższone ryzyko trwałej kompromitacji.
  • Szybka weaponizacja CVE skraca okno patchowania; organizacje o wolnych procesach aktualizacji będą statystycznie padać ofiarą skanów-at-scale.
  • AI-first kampanie zwiększają wolumen i jakość socjotechniki (syntetyczne treści, automatyzacja), a atakowana AI może stać się przekaźnikiem błędnych decyzji (np. zatruwanie danych, wstrzykiwanie promptów).
  • Usługi krytyczne i sektor publiczny są narażone na realny wpływ (zdrowie, edukacja, służby). Wymagana jest współpraca z rządami i egzekwowanie konsekwencji wobec agresorów.

Rekomendacje operacyjne / co zrobić teraz

Na bazie zaleceń MDDR i praktyk defensywnych:

  1. Identity-First Security
  • Phishing-resistant MFA (FIDO2/Passkeys) dla wszystkich ról – priorytet dla kont uprzywilejowanych.
  • Warunki dostępu (Conditional Access), governance aplikacji/OAuth, ciągłe monitorowanie tokenów; eliminacja legacy auth.
  1. Twarda higiena i ekspozycja
  • Inwentaryzacja usług public-facing, skanowanie i szybkie łatanie; SLA na patch skrócone do dni/godzin przy krytycznych CVE.
  • Wymuszenie Secure by Default: EDR/AV, blokady makr, kontrola PowerShell, Least Privilege.
  1. Odporność chmury i danych
  • Segregacja tożsamości (admin/workload), Just-in-Time/Just-Enough-Access, separacja tenants/subskrypcji.
  • Kopie niezmienialne (immutability), testy odtwarzania, segmentacja sieci.
  1. AI Security
  • Threat modeling dla AI: ochrona przed prompt injection, data poisoning, wyciekiem danych z modeli; kontrola dostępu do modeli i pipeline’ów ML.
  1. Detekcja zachowań i automatyzacja reakcji
  • Telemetria z tożsamości, punktów końcowych, chmury i poczty; korelacja oparta na zachowaniach; SOAR do skracania MTTR.
  1. Łańcuch dostaw i third parties
  • Ocena ryzyka dostawców (m.in. nadużycia zaufanych relacji), minimalizacja dostępu stałego, monitoring anomalii integracji.
  1. Governance i współpraca
  • Raportowanie do zarządu (metryki: pokrycie MFA, czas łatania, MTTR, incydenty/semestr).
  • Współpraca z CERT/CSIRT oraz branżą (dzielenie się TTP, IOCs) i egzekwowanie konsekwencji wobec agresorów.
  1. Horyzont PQC (post-quantum)
  • Inwentaryzacja miejsc użycia kryptografii i plan migracji do post-quantum crypto zgodnie z ewolucją standardów.

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

W porównaniu z wcześniejszymi edycjami MDDR, tegoroczny raport wyraźniej eksponuje skalę operacji państw narodowych (m.in. wzrost rosyjskiej aktywności wobec państw NATO) przy jednoczesnym stwierdzeniu, że głównym wolumenem nadal są kampanie przestępcze nastawione na zysk. To koreluje z doniesieniami mediów o rosnącym użyciu AI w operacjach wpływu i kampaniach technicznych.

Podsumowanie / kluczowe wnioski

  • AI zmienia dynamikę: zwiększa efektywność ataków i obrony — wygrywa strona, która szybciej i mądrzej ją wdroży.
  • Tożsamość to nowy perymetr: MFA odporne na phishing, governance aplikacji i higiena tokenów to absolutne „must have”.
  • Odporność organizacyjna > pojedyncze narzędzia: modernizacja procesów, automatyzacja reakcji i przygotowanie na zakłócenia łańcuchów dostaw.
  • Współpraca i polityka są tak samo ważne, jak technologia — bez nich odstraszanie agresorów będzie nieskuteczne.

Źródła / bibliografia

  1. Microsoft Digital Defense Report 2025 (pełny PDF). Kluczowe dane: sektory, geografia, motywy, timeline incydentu w transporcie. (Microsoft)
  2. Microsoft – CISO Executive Summary (PDF). Nowe trendy: ClickFix, device code phishing, nadużycia OAuth; AI jako cel ataku. (Microsoft)
  3. Microsoft Security / On the Issues – MDDR 2025 (blog, 16.10.2025). Zakres czasowy, 52% ataków motywowanych zyskiem, 97% ataków tożsamościowych hasłowych, rola MFA. (The Official Microsoft Blog)
  4. Microsoft – strona raportu (Security Insider). Priorytety obronne: tożsamość, odporność chmury, łańcuchy dostaw, partnerstwa. (Microsoft)
  5. Industrial Cyber – omówienie (21.10.2025). Kontekst dla OT/CI, wątki polityki odstraszania i governance. (Industrial Cyber)

Hakerzy wykorzystali SnappyBee (Deed RAT) i lukę w Citrix NetScaler do ataku na europejskiego operatora telekomunikacyjnego

Wprowadzenie do problemu / definicja luki

Na początku lipca 2025 r. europejski dostawca usług telekomunikacyjnych został zaatakowany przez aktora powiązanego z Chinami, śledzonego jako Salt Typhoon (aka Earth Estries / FamousSparrow / GhostEmperor / UNC5807/UNC2286). Wektor wejścia stanowił Citrix NetScaler Gateway (dawniej ADC/Gateway), a po uzyskaniu przyczółka napastnicy przeszli na hosty Citrix Virtual Delivery Agent (VDA) w segmencie Machine Creation Services (MCS). W dalszej fazie zastosowano DLL sideloading z wykorzystaniem podpisanych plików znanego oprogramowania AV oraz wdrożono backdoora SnappyBee (Deed RAT) – uważanego za następcę ShadowPad. Incydent wykryto i zneutralizowano we wczesnym etapie.

W skrócie

  • Aktor: Salt Typhoon (chińska grupa APT ukierunkowana na telekomy i infrastrukturę krytyczną).
  • Wejście: eksploatacja urządzenia Citrix NetScaler Gateway i pivot do hostów Citrix VDA (MCS).
  • Ukrycie: ruch przez SoftEther VPN oraz DLL sideloading na bazie legalnych plików AV (Norton, Bkav, IObit).
  • Malware: SnappyBee/Deed RAT – łańcuch pokrewieństwa do ShadowPad.
  • C2: kontakt z aar.gandhibludtric[.]com (HTTP i niestandardowy TCP).

Kontekst / historia / powiązania

Salt Typhoon od 2019 r. prowadzi długotrwałe kampanie cyberszpiegowskie wobec operatorów telekomunikacyjnych, administracji i sektora energii – na wielu kontynentach. W latach 2024–2025 szereg doniesień (m.in. Reuters) wskazywał na skoordynowane włamania do sieci telekomów w USA i innych krajach, o dużej głębokości utrzymania się w środowiskach ofiar. Amerykańskie instytucje publiczne publikowały ostrzeżenia i środki zaradcze wobec działań aktorów sponsorowanych przez władze ChRL.

Trend Micro profiluje „Earth Estries” jako grupę o bogatym arsenale – od SnappyBee (Deed RAT) po inne niestandardowe implanty – oraz stałej preferencji do utrzymywania się w sieciach telekomunikacyjnych przez długie okresy.

Analiza techniczna / szczegóły luki

Wejście i pivot:

  • Eksploatacja bramy Citrix NetScaler Gateway → ruch atakującego widoczny z zasobów powiązanych z SoftEther VPN (maskowanie pochodzenia).
  • Później pivot do hostów Citrix VDA w podsieci MCS – logiczny krok po przejęciu bramy dostępowej w środowiskach wirtualnych pulpitów.

Egzekucja i ukrywanie (Defense Evasion):

  • DLL sideloading: dostarczenie złośliwych bibliotek w pakiecie z legalnymi EXE antywirusów (Norton AV, Bkav AV, IObit Malware Fighter). To znana technika wielu chińskojęzycznych grup – pozwala ominąć kontrole aplikacji i EDR bazujące na reputacji.

Backdoor / ładunek:

  • SnappyBee (aka Deed RAT) – opisywany jako następca modularnego ShadowPad. Umożliwia zdalne sterowanie, eksfiltrację i rozbudowę funkcji. W innych kampaniach obserwowano rozwinięte „linie rodowe”, np. BLOODALCHEMY jako warianty Deed RAT.

C2 i łączność:

  • Observed C2: aar.gandhibludtric[.]com (HTTP + nieokreślony protokół TCP). Sugeruje hybrydowy model komunikacji i próby mieszania się z ruchem webowym.

Techniki MITRE ATT&CK (mapowanie przykładowe):

  • Initial Access: Exploiting Public-Facing Application (T1190) – urządzenia brzegowe.
  • Defense Evasion/Execution: DLL Search Order Hijacking (T1574.001), Signed Binary Proxy Execution (T1218).
  • Command and Control: Application Layer Protocol – Web Protocols (T1071.001), Non-Standard Port (T1571).
    (Uzasadnienie na bazie opisu Darktrace i zgodności z wcześniejszymi TTP Earth Estries).

Praktyczne konsekwencje / ryzyko

  • Telekomy jako cel o wysokiej wartości: przejęcie bramy zdalnego dostępu (NetScaler) i pivot do VDI zwiększa ryzyko dostępu do systemów OSS/BSS, podsłuchu, danych abonentów, a nawet ruchu sygnalizacyjnego. Globalne doniesienia z 2024–2025 r. potwierdzają, że Salt Typhoon potrafi osiągać głęboki poziom uprzywilejowania i długą obecność.
  • DLL sideloading przez „zaufane” EXE: utrudnia detekcję opartą o reputację i listy zaufanych wydawców – ryzyko false negative w EDR bez silnej telemetrii modułów ładowanych do procesu.
  • SoftEther i inne kanały maskujące: komplikują śledzenie źródeł i korelację zdarzeń na brzegu sieci.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowy przegląd i hardening NetScaler/NetScaler Gateway
    • Upewnij się, że bramy są na najnowszych wersjach i że konfiguracje AAA/Gateway są zgodne z zaleceniami producenta.
    • Włącz nacisk na monitoring anomalii w ruchu do/od urządzeń brzegowych (szczególnie HTTP(S) do nietypowych hostów).
    • Zestaw kontrolek dla Citrix VDA/MCS: ograniczenie lateral movement (mikrosegmentacja, ACL, firewall hostowy).
      (Ogólne zalecenia wynikają z opisu wektora w raporcie Darktrace i ostrzeżeń instytucji dot. PRC aktorów).
  2. Polityki anty-sideloading i „living off trusted binaries”
    • Block/Allow-list na poziomie DLL search order i ścieżek ładowania bibliotek dla aplikacji krytycznych (w tym AV).
    • W EDR/XDR twórz reguły detekcyjne dla: signed EXE + niepodpisany/nieznany DLL w katalogu aplikacji, nieoczekiwane moduły w procesach AV.
  3. Myśli przewodnie dla detekcji C2
    • Reguły na nietypowe domeny oraz C2 over HTTP + nietypowy TCP; korelacja z danymi DNS/SSL SNI (np. „aar.gandhibludtric[.]com”).
    • Uważna inspekcja tuneli VPN typu SoftEther i innych user-space VPN.
  4. Higiena tożsamości i segmentacja
    • MFA, rotacja haseł uprzywilejowanych, Just-In-Time dostępy dla adminów VDI/VDA, tiering kont i serwerów.
    • Mikrosegmentacja podsieci VDI/MCS oraz ograniczenia RDP/SMB z bramy do VDA tylko wg zasady najmniejszych uprawnień.
  5. Ćwiczenia IR + playbook pod APT
    • Scenariusz: kompromitacja urządzenia brzegowego + pivot do VDI + DLL sideloading.
    • Włącz w playbook pre-collection artefaktów: listy załadowanych modułów, ścieżki DLL, telemetry z NetScaler/Gateway i VDA.

Różnice / porównania z innymi przypadkami (telekomy 2024–2025)

W porównaniu do ujawnionych w 2024–2025 r. kampanii Salt Typhoon przeciwko telekomom w USA (AT&T, Verizon i inni), obecny przypadek z UE pokazuje zbliżony modus operandi: wejście przez urządzenia brzegowe, długotrwałość, nacisk na ukrycie i pozyskiwanie danych o wysokiej wartości. Elementem wyróżniającym jest udokumentowane użycie SnappyBee/Deed RAT dostarczanego przez DLL sideloading na bazie plików AV, co Darktrace opisuje bardzo konkretnie dla tej operacji.

Podsumowanie / kluczowe wnioski

  • Salt Typhoon pozostaje jednym z najgroźniejszych aktorów dla telekomów – atakuje edge (Citrix), szybko pivotuje do VDI i utrzymuje się dzięki sideloadingowi i niestandardowym backdoorom (SnappyBee/Deed RAT).
  • Nawet podpisane i „zaufane” binaria (AV) mogą stać się nośnikiem ładunków – procesy AV trzeba monitorować jak aplikacje wysokiego ryzyka.
  • Obrona wymaga twardych aktualizacji Citrix, telemetrii DLL, dyscypliny segmentacyjnej w VDI/MCS oraz analityki C2. Zalecenia CISA dot. aktorów państwowych wspierają takie podejście.

Źródła / bibliografia

  1. Darktrace – opis incydentu i TTP: „Darktrace’s view on a recent Salt Typhoon intrusion” (opublikowano 20 października 2025). (darktrace.com)
  2. The Hacker News – „Hackers Used Snappybee Malware and Citrix Flaw to Breach European Telecom Network” (21 października 2025). (The Hacker News)
  3. Trend Micro – „Breaking Down Earth Estries’ Persistent TTPs in Prolonged Cyber Operations” (8 listopada 2024) – kontekst SnappyBee/Deed RAT i Earth Estries. (www.trendmicro.com)
  4. CISA – „Countering Chinese State-Sponsored Actors Compromise of Networks Worldwide” (3 września 2025) – zalecenia strategiczne dot. aktorów PRC. (CISA)
  5. Reuters – „AT&T, Verizon targeted by Salt Typhoon…” (29 grudnia 2024) – tło i skala kampanii na telekomy. (Reuters)

Google identyfikuje trzy nowe rodziny malware rosyjskiego COLDRIVER: NOROBOT, YESROBOT i MAYBEROBOT

Wprowadzenie do problemu / definicja luki

Google Threat Intelligence Group (GTIG) ujawniła 20 października 2025 r. trzy powiązane ze sobą rodziny malware wykorzystywane przez rosyjską grupę COLDRIVER (znaną też jako Star Blizzard, Callisto, UNC4057): NOROBOT (downloader DLL), YESROBOT (backdoor w Pythonie) oraz MAYBEROBOT (implant PowerShell). Zidentyfikowany łańcuch infekcji stanowi ewolucję wcześniejszych kampanii z przynętą „ClickFix” i fałszywą weryfikacją CAPTCHA, których celem jest nakłonienie użytkownika do ręcznego uruchomienia złośliwego komponentu przez rundll32.exe.

W skrócie

  • COLDRIVER w ciągu 5 dni od publikacji analizy ich poprzedniego narzędzia (LOSTKEYS, maj 2025) wprowadził nowe „ROBOT-y”, znacząco zwiększając tempo rozwoju i modyfikacji TTP.
  • NOROBOT dostarcza kolejne etapy i przygotowuje środowisko; w najstarszych wariantach pobierał nawet pełną instalację Pythona 3.8 – artefakt głośny i łatwy do wykrycia.
  • YESROBOT to minimalny backdoor (Python/HTTPS, AES), zaobserwowany tylko dwukrotnie pod koniec maja 2025 r.; szybko go porzucono.
  • MAYBEROBOT (PowerShell) zastąpił YESROBOT: ma elastyczny protokół C2 i trzy komendy (pobierz/uruchom z URL, cmd.exe, blok PowerShell).
  • Zscaler śledzi część tego łańcucha jako BAITSWITCH (NOROBOT) i SIMPLEFIX (MAYBEROBOT); kampanie wykorzystywały przynęty ClickFix.

Kontekst / historia / powiązania

COLDRIVER od lat specjalizuje się w wyrafinowanym phishingu ukierunkowanym na NGO, think-tanki, doradców politycznych i dysydentów w krajach NATO. NCSC UK i CISA dokumentowały aktywność tej grupy jako Star Blizzard, przypisując jej operacje cyberszpiegowskie na rzecz interesów rosyjskich. W 2025 r. Google opisał LOSTKEYS – kradnący pliki stealer – oraz zwrot ku mechanice ClickFix, wcześniej obserwowanej m.in. przez Proofpoint również u aktorów państwowych.

Analiza techniczna / szczegóły luki

Wejście: ClickFix + CAPTCHA → rundll32.exe

  • Użytkownik trafia na stronę z fałszywą CAPTCHA (wariant przynęty COLDCOPY), która instruuje, by „zweryfikować człowieczeństwo” poprzez pobranie i uruchomienie DLL-a z użyciem rundll32.exe (np. plik „iamnotarobot.dll”, eksport humanCheck).

Etap 1: NOROBOT (downloader DLL)

  • Zadania: przygotowanie hosta, utrwalenie, pobranie kolejnych etapów z twardo zakodowanego C2.
  • Wczesny NOROBOT: dzielony klucz kryptograficzny (część w rejestrze, część w pliku), harmonogram zadań, pobieranie pełnego Python 3.8 i modułów (bitsadmin) – to prowadziło do YESROBOT.
  • Późniejsze NOROBOT: uproszczony łańcuch (logon script), rotacja infrastruktury/nazw plików/eksportów.

Etap 2a: YESROBOT (Python backdoor – szybko zarzucony)

  • C2 przez HTTPS, polecenia zaszyfrowane AES, identyfikacja hosta w nagłówku User-Agent. Minimalna funkcjonalność – każde polecenie musi być poprawnym kodem Python. Zaobserwowane dwa wdrożenia przez ~2 tygodnie w maju 2025 r.

Etap 2b: MAYBEROBOT (PowerShell implant – obecny standard)

  • Ciąg znaków C2, protokół obsługujący: (1) pobierz/uruchom z URL, (2) wykonaj polecenie przez cmd.exe, (3) wykonaj blok PowerShell; potwierdzenia i wyniki na osobnych ścieżkach. Bardziej elastyczny, bez potrzeby instalacji Pythona. W nomenklaturze Zscalera: SIMPLEFIX.

Nazewnictwo i powiązania

  • NOROBOT ≈ BAITSWITCH, MAYBEROBOT ≈ SIMPLEFIX (Zscaler ThreatLabz, IX–X 2025).

Praktyczne konsekwencje / ryzyko

  • Wzrost tempa operacji: szybkie przełączanie narzędzi po deanonimizacji (5 dni po publikacji LOSTKEYS) utrudnia detekcję opartą na wskaźnikach.
  • Technika ClickFix: socjotechnika wymuszająca manualne uruchomienie złośliwego kodu obchodzi wiele polityk kontroli skryptów i utrudnia klasyczne filtrowanie e-mail. Proofpoint raportował upowszechnienie ClickFix również u aktorów państwowych.
  • Priorytetyzacja celów: GTIG ocenia, że NOROBOT/MAYBEROBOT są zarezerwowane dla wysokowartościowych celów, być może już wcześniej wyłudzonych phishingiem (eskalacja z kradzieży kont do eksfiltracji z hosta).

Rekomendacje operacyjne / co zrobić teraz

Prewencja i twardnienie stacji roboczych

  1. Zablokuj uruchamianie rundll32.exe z katalogów użytkownika / pobierania (WDAC/AppLocker, SRP), monitoruj nietypowe ścieżki DLL.
  2. Wymuś Constrained Language Mode/AMS podpisy w PowerShell, blokuj bitsadmin/curl/Invoke-WebRequest z niezaufanych kontekstów.
  3. Wdróż Attack Surface Reduction (ASR): blokowanie tworzenia zadań harmonogramu przez nieluźno zaufane procesy, ogranicz WMI i skrypty logon.
  4. Ogranicz instalacje Pythona na endpointach; wykrywaj nagłe pojawienie się katalogów typu %APPDATA%\Python38-64\. (artefakt wczesnego łańcucha).

Detekcja (przykładowe sygnały behawioralne)

  • Sekwencja: przeglądarka → pobranie DLL → rundll32.exe z parametrem exportu nietypowej nazwy (humanCheck) → komunikacja HTTPS do rzadkiej domeny/C2 → tworzenie zadania „System health check” → wywołanie Pythona/PowerShella.
  • Anomalia w User-Agent i nietypowe endpointy ACK/OUT w ścieżkach C2 (MAYBEROBOT).

Hunting / logi do korelacji

  • Sysmon: Event ID 1/7 (process/create), 3 (network), 11 (file create), 13 (registry), 19/20/21 (WMI), 24/25 (clipboard jeśli stosowane).
  • Windows Task Scheduler operational log (Microsoft-Windows-TaskScheduler/Operational) pod kątem nazwy „System health check”.

Szybkie playbooki reakcji

  • Izoluj host; zbierz scheduled tasks, klucze rejestru z przestrzeni HKCU\SOFTWARE\Classes.pietas (jeśli obecne), ślady bitsadmin.
  • Zastosuj blokadę wycieków (DLP) i tymczasową segmentację sieci dla kont wysokiego ryzyka.

Różnice / porównania z innymi przypadkami

  • LOSTKEYS (V1, maj 2025) vs ROBOT-y (X 2025): przejście od prostego stealera do elastycznych implantów operacyjnych (szczególnie PowerShell), rezygnacja z ciężkiego runtime (Python) na rzecz stealth.
  • ClickFix w 2025 r.: wcześniej kojarzony z cyberprzestępczością; od Q1–Q2 2025 r. Proofpoint dokumentuje jego adopcję przez aktorów państwowych (Rosja, Iran, Korea Płn.). COLDRIVER wpisuje się w ten trend.
  • Nazewnictwo: GTIG (NOROBOT/YESROBOT/MAYBEROBOT) vs Zscaler (BAITSWITCH/SIMPLEFIX) – to te same elementy łańcucha widziane z różnych etapów telemetrycznych.

Podsumowanie / kluczowe wnioski

COLDRIVER przyspieszył cykl eksponowanie → retooling → redeployment, co wymaga od obrońców skupienia się na behawioralnych wskaźnikach ataku (rundll32 z nietypowych lokalizacji, harmonogram, PowerShell C2), a nie wyłącznie na IOC. Elastyczny MAYBEROBOT oraz stale modyfikowany NOROBOT sugerują operacje precyzyjne przeciw celom wysokiej wartości, prawdopodobnie jako kolejny etap po udanym phishingu.

Źródła / bibliografia

  1. Google Cloud – To Be (A Robot) or Not to Be: New Malware Attributed to Russia State-Sponsored COLDRIVER (20.10.2025). (Google Cloud)
  2. Zscaler ThreatLabz – COLDRIVER Updates Arsenal with BAITSWITCH and SIMPLEFIX (24.09.2025). (Zscaler)
  3. Proofpoint – Around the World in 90 Days: State-Sponsored Actors Try ClickFix (17.04.2025). (Proofpoint)
  4. CISA / NCSC UK – Russian FSB cyber actor Star Blizzard continues worldwide spear-phishing campaigns (07.12.2023) — tło/atrybucja. (CISA)
  5. The Hacker News – Google Identifies Three New Russian Malware Families Created by COLDRIVER Hackers (21.10.2025). (The Hacker News)