Archiwa: Windows - Strona 75 z 80 - Security Bez Tabu

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.exepowershell.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 GroupTo 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. SecurityWeekRussian 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 ReadingColdRiver 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)

CISA dodaje nową lukę do katalogu KEV: krytyczne RCE w Motex LANSCOPE Endpoint Manager (CVE-2025-61932)

Wprowadzenie do problemu / definicja luki

22 października 2025 r. CISA dodała jedną nową pozycję do katalogu Known Exploited Vulnerabilities (KEV), wskazując na potwierdzoną eksploatację w środowiskach produkcyjnych. Chodzi o CVE-2025-61932 w Motex LANSCOPE Endpoint Manager (on-premises) — podatność umożliwiającą zdalne wykonanie kodu (RCE) bez uwierzytelnienia poprzez specjalnie spreparowane pakiety. Federalne agencje w USA mają czas na remediację do 12 listopada 2025 r. (termin KEV).

W skrócie

  • Produkt: Motex LANSCOPE Endpoint Manager (on-prem) – moduły klienta MR i agenta detekcyjnego DA.
  • CVE: CVE-2025-61932.
  • Wpływ: zdalne wykonanie kodu (RCE) z sieci, bez uprawnień i interakcji użytkownika.
  • Ocena: CVSS v3.0 9.8 (Critical) / CVSS v4.0 9.3.
  • Status: potwierdzona eksploatacja; wpis w CISA KEV z datą dodania 2025-10-22 i terminem 2025-11-12.

Kontekst / historia / powiązania

CISA systematycznie aktualizuje KEV, aby egzekwować priorytetowe łatanie realnie atakowanych błędów w ramach BOD 22-01. Dodanie pojedynczej pozycji 22 października nastąpiło zaraz po większych aktualizacjach z 14 i 20 października (Apple, Microsoft, Oracle, Kentico), co podkreśla dynamiczną sytuację w październiku 2025 r.

Analiza techniczna / szczegóły luki

  • Klasa błędu: Improper Verification of Source of a Communication Channel (CWE-940) — niewłaściwe weryfikowanie źródła kanału komunikacyjnego.
  • Wektor ataku: Network, AC: Low, PR: None, UI: None — atakujący może wysłać specjalnie przygotowane pakiety do komponentów klienta/agentów.
  • Skutek: wykonanie arbitralnego kodu na hoście z zainstalowanym agentem/klientem LANSCOPE.
  • Pochodzenie informacji: opisy JVN/JPCERT oraz NVD/CVE.org doprecyzowują, że błąd dotyczy wersji on-premises i wynika z niewłaściwej weryfikacji pochodzenia żądań.

Warto dodać, że JVN odnotował potwierdzony przypadek otrzymania złośliwego pakietu u klienta dostawcy, co skorelowało się z decyzją CISA o wpisie do KEV.

Praktyczne konsekwencje / ryzyko

  • Szeroka powierzchnia ataku: endpointy z agentem DA/MR często mają łączność sieciową — podatność może zostać wykorzystana zdalnie w sieci korporacyjnej.
  • Łańcuchowanie: RCE na stacjach roboczych/serwerach z agentem może służyć do lateral movement, eskalacji uprawnień i wyłączenia kontroli EDR.
  • Ryzyko operacyjne: potencjalne przerwy w monitoringu bezpieczeństwa, utrata integralności/ poufności danych oraz możliwość wdrożenia ładunków ransomware.
  • Priorytet KEV: krótki deadline (12 listopada 2025 r.) wymusza natychmiastowy plan remediacji i weryfikacji ekspozycji.

Rekomendacje operacyjne / co zrobić teraz

  1. Inwentaryzacja: zidentyfikuj wszystkie instalacje LANSCOPE Endpoint Manager (on-prem), wersje klienta MR i agenta DA.
  2. Patch/Upgrade: zastosuj poprawki producenta dla CVE-2025-61932 zgodnie z JVN/MOTEX; jeśli niezwłoczny update jest niemożliwy, wdroż obejścia producenta i segmentację.
  3. Segmentacja i kontrola dostępu: ogranicz ruch do/od agentów (ACL, VLAN, mikrosegmentacja), rozważ izolację management serwerów LANSCOPE.
  4. Monitoring i detekcja:
    • logi sieciowe pod kątem nietypowych pakietów kierowanych do portów i usług agenta/klienta,
    • EDR/SIEM: zdarzenia spawn procesów przez komponenty LANSCOPE, anomalia w pamięci i rejestrze,
    • NIDS/NIPS: sygnatury dla charakterystycznych ciągów/protokołów (po publikacji reguł).
  5. Hardening: jeśli to możliwe, włącz mTLS / weryfikację źródła w kanałach komunikacyjnych agent–serwer, whitelistę adresów zarządzających.
  6. Plan awaryjny: gdzie aktualizacja nie jest możliwa — czasowe wyłączenie agentów w strefach o najwyższym ryzyku zgodnie z BOD 22-01 (zasada: lepiej tymczasowo ograniczyć funkcjonalność niż utracić integralność).

Różnice / porównania z innymi przypadkami

  • W odróżnieniu od niedawnego CVE-2025-33073 (Windows SMB Client), gdzie konieczna bywa interakcja protokołowa SMB z podstępnym serwerem, tutaj wystarczy osiągalność sieciowa agenta/klienta LANSCOPE. Ryzyko szybkiej automatyzacji ataków jest więc wysokie.
  • W październiku do KEV trafiały także błędy w Apple/Oracle/Kentico, jednak CVE-2025-61932 dotyczy oprogramowania zabezpieczającego/zarządzającego endpointami, co czyni je szczególnie atrakcyjnym celem do przejęcia domeny/ESM.

Podsumowanie / kluczowe wnioski

  • CVE-2025-61932 to krytyczny RCE w Motex LANSCOPE Endpoint Manager (on-prem), aktywnie wykorzystywany — wpisany do CISA KEV 22.10.2025, z terminem remediacji 12.11.2025.
  • Atak jest bezuwierzytelnieniowy i bez interakcji użytkownika, co sprzyja masowej eksploatacji.
  • Priorytet: natychmiastowy patch, segmentacja, wzmocnienie kontroli na styku agent–serwer oraz intensywny monitoring.

Źródła / bibliografia

  • CISA — alert „CISA Adds One Known Exploited Vulnerability to Catalog” (22.10.2025). (CISA)
  • CISA — KEV Catalog (metadane pozycji: data dodania i due date). (CISA)
  • NVD/NIST — karta CVE-2025-61932 (opis, CVSS). (NVD)
  • JVN/JPCERT — advisory dla LANSCOPE EPM (opis, CVSS, potwierdzenie złośliwego pakietu u klienta). (jvn.jp)
  • CVE.org — rekord CVE-2025-61932 (zgodny opis). (cve.org)

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)

CISA ostrzega przed wykorzystywanymi lukami w Apple, Kentico i Microsoft. Co to oznacza dla Twojej organizacji?

Wprowadzenie do problemu / definicja luki

Amerykańska agencja CISA dodała do katalogu Known Exploited Vulnerabilities (KEV) nowe pozycje: podatność w Windows SMB Client (CVE-2025-33073), dwie luki omijające uwierzytelnianie w Kentico Xperience CMS (CVE-2025-2746 i CVE-2025-2747) oraz starszą lukę w produktach Apple (CVE-2022-48503). Dodanie do KEV oznacza potwierdzoną eksploatację „in the wild” oraz obowiązek pilnego łatania w agencjach federalnych USA (standardowo w ciągu 3 tygodni).

W skrócie

  • Microsoft Windows (SMB Client) – CVE-2025-33073 (CVSS 8.8): błąd kontroli dostępu umożliwiający eskalację uprawnień do SYSTEM po skłonieniu hosta do uwierzytelnienia do kontrolowanego przez atakującego serwera SMB. Luka załatana w czerwcu 2025 r.; istniały PoC. Teraz potwierdzono aktywne wykorzystanie.
  • Kentico Xperience – CVE-2025-2746 i CVE-2025-2747 (CVSS 9.6): ominięcie uwierzytelniania w komponencie Staging/Sync Server; w typowych konfiguracjach może prowadzić do przejęcia obiektów administracyjnych i zdalnego wykonania kodu (RCE) w łańcuchu ataku. Poprawki dostępne w wersjach 13.0.173 i 13.0.178.
  • Apple – CVE-2022-48503 (CVSS 8.8): błąd w JavaScriptCore skutkujący wykonaniem dowolnego kodu, naprawiony w 2022 r. (macOS, iOS/iPadOS, Safari, tvOS, watchOS). CISA wskazuje na aktywną eksploatację.

Kontekst / historia / powiązania

  • SMB Client (MS): luka została załatana w ramach Patch Tuesday w czerwcu 2025 r., a Microsoft informował o dostępnych dowodach koncepcji (PoC). Dodanie do KEV 20 października 2025 r. sugeruje, że PoC-y przerodziły się w realne ataki.
  • Kentico: badacze watchTowr opisali łańcuchy prowadzące do pre-auth RCE przy włączonym Staging Sync Server z uwierzytelnianiem hasłem (powszechna konfiguracja). Kentico opublikowało poprawki w linii 13.0.x.
  • Apple: luka z 2022 r. wraca na radar, co pokazuje długą „żywotność” błędów – część środowisk mogła pozostać na niezałatanych wydaniach.

Analiza techniczna / szczegóły luk

CVE-2025-33073 – Microsoft Windows SMB Client (EoP)

  • Wektor: sieciowy; wymagane PR:L (autoryzowany napastnik) i brak interakcji użytkownika.
  • Mechanika: niewłaściwa kontrola dostępu w kliencie SMB pozwala przestępcy wymusić połączenie ofiary z kontrolowanym serwerem SMB i uwierzytelnić się, co w konsekwencji umożliwia eskalację uprawnień do SYSTEM.

CVE-2025-2746 / CVE-2025-2747 – Kentico Xperience (auth bypass → RCE chain)

  • Powierzchnia ataku: CMS.Synchronization.WSE3.SyncServer (SOAP/WS-Security).
  • Warunki podatności: włączony Staging/Sync Server i uwierzytelnianie login/hasło (X.509 niepodatny).
  • Istota błędów: błędy w obsłudze tokenów i haseł (m.in. zachowania związane z SHA-1/digest oraz sprawdzaniem użytkownika) pozwalają ominąć uwierzytelnianie i sterować obiektami administracyjnymi; po złączeniu z RCE po uwierzytelnieniu – pełne przejęcie instancji.
  • Łatki: 13.0.173 (WT-2025-0006) i 13.0.178 (WT-2025-0011).

CVE-2022-48503 – Apple (JavaScriptCore RCE)

  • Komponent: JavaScriptCore (silnik JS w WebKit).
  • Wpływ: zdalne wykonanie dowolnego kodu po przetworzeniu złośliwej zawartości web.
  • Zasięg: macOS Monterey 12.5, iOS/iPadOS 15.6, Safari 15.6, tvOS 15.6, watchOS 8.7 (i pokrewne).

Praktyczne konsekwencje / ryzyko

  • Ransomware i LPE: CVE-2025-33073 idealnie nadaje się do eskalacji uprawnień w późniejszych etapach ataku po początkowym wdarciu (np. przez phishing), co zwiększa prawdopodobieństwo pełnej kompromitacji domeny.
  • Przejęcia CMS i supply chain web: Ominięcie auth w Kentico z włączonym stagingiem to przejęcie stron/treści, wstrzyknięcia skryptów, pivot do sieci wewnętrznej. Dodatkowo ryzyko RCE przy łańcuchach ataku.
  • Dług życiowy podatności: powrót CVE z 2022 r. (Apple) do KEV potwierdza, że stare błędy nadal są wykorzystywane, gdy urządzenia nie są aktualizowane.

Rekomendacje operacyjne / co zrobić teraz

  1. Zastosuj poprawki w SLA „KEV-critical”:
    • Windows: wdroż czerwcowe łatki 2025 obejmujące CVE-2025-33073 i wymuś restart tam, gdzie to wymagane. Zweryfikuj, czy polityki blokują nieautoryzowane połączenia SMB do Internetu.
    • Kentico: zaktualizuj co najmniej do 13.0.178, a najlepiej do najnowszej wersji dostępnej u producenta; jeśli Staging/Sync Server nie jest potrzebny – wyłącz. Jeśli potrzebny – przełącz na uwierzytelnianie X.509, zrotuj hasła i tokeny.
    • Apple: podnieś systemy do wersji zawierających poprawkę na CVE-2022-48503 (macOS/iOS/iPadOS/Safari/tvOS/watchOS) – nawet jeśli sprzęt jest starszy.
  2. Twarde ograniczenia sieciowe: blokuj nieautoryzowany SMB (445/TCP) na granicach sieci; stosuj SMB signing i segmentację.
  3. Higiena tożsamości: monitoruj NTLM/SMB relay, ogranicz NTLM, preferuj Kerberos; włącz Protected Users/LDAP signing/SMB signing.
  4. Telemetria i wykrywanie:
    • Szukaj nietypowych połączeń SMB do niespodziewanych hostów (np. z segmentów użytkowników do Internetu).
    • W Kentico – audytuj logi CMSPages/Staging/SyncServer.asmx, próby WS-Security z pustymi/niepoprawnymi tokenami.
  5. IR gotowość: przygotuj playbook na LPE oraz na kompromitację CMS – szybka izolacja hostów, reset haseł, wymuszenie reautoryzacji sesji.
  6. Zgodność z KEV: jeśli podlegasz regulacjom zbliżonym do BOD 22-01, przyjmij deadline 21 dni jako twardy SLO.

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

  • SMB LPE vs. RCE: CVE-2025-33073 to eskalacja uprawnień (wymaga już jakiegoś footholdu), ale w praktyce często decydująca dla pełnej kompromitacji. Kentico (CVE-2025-2746/2747) potrafi dać pre-auth dostęp i po złączeniu z inną luką – RCE na serwerze WWW.
  • Stare vs. nowe: Apple CVE z 2022 r. pokazuje, że stare luki bywają równie groźne jak świeże błędy, jeśli pozostają niezałatane – stąd sensowność polityk „n-1” i regularnych aktualizacji.

Podsumowanie / kluczowe wnioski

  • CISA potwierdziła aktywną eksploatację trzech rodzin luk obejmujących popularne środowiska: Windows, Kentico Xperience i Apple.
  • Priorytety: Windows (SMB LPE) → Kentico (auth bypass/chain to RCE) → Apple (nadrobienie zaległości patchowych).
  • Działania: patch, segmentacja i blokada SMB, twarde uwierzytelnianie dla usług staging/sync, monitoring anomalii SMB/WS-Security oraz egzekwowanie terminów z KEV.

Źródła / bibliografia

  • SecurityWeek: „CISA Warns of Exploited Apple, Kentico, Microsoft Vulnerabilities” (21 października 2025). (SecurityWeek)
  • CISA Alert: „CISA Adds Five Known Exploited Vulnerabilities to Catalog” (20 października 2025). (CISA)
  • NVD: CVE-2025-33073 – Windows SMB Client Improper Access Control. (NVD)
  • WatchTowr Labs: „Bypassing Authentication Like It’s The ‘90s – Pre-Auth RCE Chain(s) in Kentico Xperience CMS” (marzec 2025). (watchTowr Labs)
  • NVD: CVE-2025-2746 i CVE-2025-2747 – Kentico Xperience Authentication Bypass. (NVD)
  • NVD: CVE-2022-48503 – Apple JavaScriptCore RCE (z informacjami o wersjach z poprawkami). (NVD)

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)

Microsoft: Październikowe aktualizacje powodują problemy z uwierzytelnianiem kartami inteligentnymi w Windows

Wprowadzenie do problemu / definicja luki

Październikowy zestaw poprawek Microsoftu (opublikowany 14 października 2025 r.) wywołał u części organizacji problemy z uwierzytelnianiem opartym o karty inteligentne i certyfikaty na systemach Windows 10, Windows 11 oraz Windows Server. Microsoft powiązał incydent z wprowadzonym domyślnie utwardzeniem kryptografii w usługach Windows Cryptographic Services. Sprawa została oznaczona jako znany problem (known issue), otwarty 17 października i oznaczony jako „Resolved” (z rozwiązaniem/procedurą) 20 października 2025 r. w panelu Release Health.

W skrócie

  • Objawy: brak rozpoznania kart jako dostawcy CSP w aplikacjach 32-bitowych, błędy przy podpisywaniu, awarie logowania CBA; komunikaty typu „invalid provider type specified” i CryptAcquireCertificatePrivateKey error.
  • Przyczyna: wymuszenie użycia KSP (Key Storage Provider) zamiast CSP (Cryptographic Service Provider) dla certyfikatów RSA na kartach, w ramach zabezpieczenia luki CVE-2024-30098.
  • Status: Microsoft udokumentował wykrywanie i obejście (klucz rejestru DisableCapiOverrideForRSA). Strona Release Health wskazuje stan „Resolved” od 20.10.2025 (17:49 PT).

Kontekst / historia / powiązania

Zmiana kryptograficzna jest częścią dłuższej ścieżki utwardzania tożsamości i kryptografii w Windows (m.in. modyfikacje zachowania CAPI/KSP, wzmocnienia Kerberosa i CBA w 2025 r.). W tym miesiącu Microsoft równolegle korygował inny błąd z Październikowego Patch Tuesday (niedziałające USB we Windows Recovery Environment), który naprawiono 20 października aktualizacją awaryjną KB5070773—to inny problem, ale pokazuje, że październikowe poprawki były wyjątkowo „ruchome”.

Analiza techniczna / szczegóły luki

Październikowe aktualizacje (m.in. KB5066791 dla Windows 10 22H2 i KB5066793/ KB5066835 dla gałęzi Windows 11/Server) egzekwują użycie KSP zamiast CSP dla certyfikatów RSA na kartach inteligentnych. Celem jest utrudnienie nadużyć opisanych w CVE-2024-30098 (obejście funkcji zabezpieczeń w Windows Cryptographic Services). Jeśli środowisko lub aplikacje oczekiwały starszego modelu CSP, pojawiają się błędy podczas operacji kryptograficznych i uwierzytelniania CBA.

Microsoft udokumentował również sposób detekcji ryzyka: przed wdrożeniem aktualizacji warto sprawdzić, czy w dzienniku System dla usługi Smart Card Service występuje Event ID 624 („system używa CAPI do operacji RSA”). Obecność zdarzenia wskazuje na większe prawdopodobieństwo wystąpienia problemu po aktualizacji.

Praktyczne konsekwencje / ryzyko

  • Tożsamość i dostęp: potencjalna niemożność logowania z użyciem kart inteligentnych (CBA) do stacji roboczych/serwerów oraz usług zależnych od certyfikatów użytkownika.
  • Procesy biznesowe: podpisy elektroniczne i operacje kryptograficzne w aplikacjach 32-bitowych mogą przestać działać do czasu dostosowania środowiska.
  • Utrzymanie: eskalacje do servicedesków i rolling back mogą zwiększać ryzyko ekspozycji, bo cofnięcie poprawek znosi również łatki bezpieczeństwa. Lepszą ścieżką jest kontrolowane obejście i kompatybilność po stronie aplikacji. (Wniosek na podstawie dokumentacji KB/Release Health.)

Rekomendacje operacyjne / co zrobić teraz

  1. Zweryfikuj wpływ w logach przed wdrożeniem szerokim frontem. Szukaj Event ID 624 w dzienniku System/Smart Card Service na reprezentatywnych hostach.
  2. Jeśli już wystąpił problem – zastosuj obejście Microsoftu (per-host):
    • Otwórz Regedit → przejdź do HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais → utwórz/edytuj wartość DWORD DisableCapiOverrideForRSA i ustaw 0restart. (Klucz nie jest dodawany przez system/aktualizacje – trzeba go utworzyć ręcznie). Uwaga: edycję rejestru wykonuj po kopii zapasowej.
  3. Rozmawiaj z dostawcami aplikacji i PKI. Celem jest usunięcie zależności od CSP i pełna zgodność z KSP. Obejście rejestrowe traktuj jako tymczasowe. (Potwierdza to komunikacja MS w Release Health/KB).
  4. Zachowaj aktualność poprawek. Nie cofaj całych pakietów, aby nie tracić łatek bezpieczeństwa—monitoruj panel Release Health dla swojego wydania (Windows 10/11/Server) i stosuj poprawki uzupełniające.
  5. Change management: wstrzymaj globalne wdrożenia do czasu weryfikacji w pilotażu; przygotuj GPO/skrpty ustawiające DisableCapiOverrideForRSA=0 na hostach dotkniętych problemem (zgodnie z polityką organizacji). (Wniosek operacyjny na bazie dokumentacji MS.)

Różnice / porównania z innymi przypadkami (październik 2025)

  • Smart card/KSP vs. WinRE/USB: Problemy z kartami wynikają z twardego przełączenia CSP→KSP (kompatybilność aplikacji), natomiast błąd WinRE/USB był klasycznym regresem sterowników/środowiska odzyskiwania i został naprawiony aktualizacją awaryjną KB5070773.

Podsumowanie / kluczowe wnioski

  • Październikowe łatki wymuszają KSP dla certyfikatów RSA na kartach, co poprawia bezpieczeństwo (CVE-2024-30098), ale ujawniło zależności od starego CSP w części środowisk.
  • Microsoft podał procedurę obejścia (DisableCapiOverrideForRSA=0) i oznaczył problem jako „Resolved” w Release Health (20.10.2025), jednak długofalowo należy zmigrować aplikacje i łańcuchy kryptograficzne do modelu KSP.

Źródła / bibliografia

  • BleepingComputer: „Microsoft warns of Windows smart card auth issues after October updates”, 20 paź 2025. (BleepingComputer)
  • Microsoft Release Health – Resolved issues (Windows 11 25H2): status, objawy, rejestr, daty 17–20 paź 2025. (Microsoft Learn)
  • Microsoft Support (KB) – KB5066791 (Windows 10 22H2), sekcja [Cryptography]: wymuszenie KSP i odwołanie do CVE-2024-30098. (Microsoft Support)
  • Microsoft Support/Release Health – KB5070773 (hotfix WinRE USB), tło innych problemów październikowych. (Microsoft Learn)