Archiwa: Windows - Strona 59 z 65 - Security Bez Tabu

Lazarus (Korea Płn.) atakuje europejskie firmy obronne z sektora UAV. Nowa fala „Operation DreamJob”

Wprowadzenie do problemu / definicja kampanii

Badacze ESET opisali nową odsłonę operacji szpiegowskiej Operation DreamJob przypisywanej grupie Lazarus powiązanej z Koreą Północną. Od końca marca 2025 r. atakujący sukcesywnie zaatakowali trzy firmy z branży obronnej w Europie Środkowej i Południowo-Wschodniej, z czego co najmniej dwie są silnie związane z technologiami UAV (drony). Cel: kradzież własności intelektualnej i know-how produkcyjnego. Główne narzędzie na etapie post-exploitation to RAT ScoringMathTea.

Informacje te potwierdzają także serwisy branżowe, które podkreślają związek kampanii z rozwojem programu dronowego w KRLD oraz wykorzystanie fałszywych ofert pracy jako wektora wejścia.

W skrócie

  • Cel: szpiegostwo przemysłowe dotyczące dronów (UAV), komponentów i oprogramowania.
  • Ofiary: 3 firmy obronne (metalurgia, producent części lotniczych, firma obronna).
  • Wejście: socjotechnika „DreamJob” – rekruter + spreparowana dokumentacja / czytnik PDF.
  • Łańcuch infekcji: trojanizowane projekty OSS (np. MuPDF, wtyczki Notepad++/WinMerge, TightVNC, libpcre, DirectX), DLL sideloading, ładowanie w pamięci (MemoryModule-style).
  • Payload: ScoringMathTea RAT (~40 komend), C2 na skompromitowanych serwerach (często w katalogach WordPress).
  • Artefakt: dropppery z wewnętrzną nazwą DroneEXEHijackingLoader.dll (wskazówka na fokus „drone”).
  • Szerszy obraz: stała, ewolucyjna zmiana bibliotek do DLL proxying i dobór nowych projektów OSS do trojanizacji.

Kontekst / historia / powiązania

Operation DreamJob to długoletnia taktyka Lazarusa oparta na latach udanych kampanii z wabikami rekrutacyjnymi; nakłada się z wcześniej opisywanymi operacjami (np. North Star, DeathNote). Motywacja Lazarusa obejmuje szpiegostwo, sabotaż i zysk finansowy, ale w tej fali dominuje espionage na rzecz rozwoju zdolności wojskowych KRLD (m.in. drony). W artykule ESET wskazano również kontekst wojny Rosja–Ukraina i doniesień o przyspieszeniu programu UAV w KRLD.

Analiza techniczna / szczegóły kampanii

Wektor wejścia i initial access

  • Kontakt „rekrutera”, dokument z opisem stanowiska i trojanizowany czytnik PDF do jego otwarcia.
  • Alternatywnie – zachęta do pobrania „przydatnej” wtyczki/oprogramowania OSS z dołączonym loaderem.

Łańcuch infekcji (przykładowy)

  1. Uruchomienie trojanizowanej aplikacji/plugina (MuPDF, Notepad++/WinMerge plugin, TightVNC, libpcre, DirectX wrapper).
  2. DLL sideloading / proxying – złośliwy DLL ładowany przez zaufany proces.
  3. Loader decrypts & reflectively loads payload w pamięci (MemoryModule-style).
  4. Dostarczenie ScoringMathTea RAT lub BinMergeLoader (MISTPEN) – ten drugi potrafi nadużywać Microsoft Graph API i tokenów do pozyskiwania dalszych ładunków.

ScoringMathTea RAT

  • ~40 poleceń: zarządzanie plikami/procesami, recon, wymiana konfiguracji, otwieranie połączeń TCP, pobieranie/uruchamianie kolejnych modułów.
  • C2 często na skompromitowanych serwerach www, ukryty w folderach WordPress (motywy/wtyczki).
  • Obserwowany w atakach od 2022/2023 r., m.in. na firmy w PL (obrona), UK (automatyka), IT (aerospace), co potwierdza, że to „flagowy” ładunek DreamJob.

Artefakty i telemetry

  • Wspólna wewnętrzna nazwa DLL: DroneEXEHijackingLoader.dll.
  • Zgłoszenia do VirusTotal (IT, ES) z próbkami trojanizowanych komponentów (np. MuPDF, dinput.dll).

Praktyczne konsekwencje / ryzyko

  • Utrata IP (projekty, BOM, procesy technologiczne, sterowanie, algorytmy kontroli lotu).
  • Ryzyko supply-chain – trojanizowane biblioteki OSS w toolchainie inżynierskim.
  • Eskalacja geopolityczna – wykorzystanie wycieków do rozwoju programów zbrojeniowych KRLD i eksportu uzbrojenia.
  • Trwałość operacji – stabilny TTP (DLL sideloading + OSS trojanizacja) + niska widoczność (reflective loading).

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/IR

  1. Hunting TTP-based:
    • Wzorce DLL sideloading (nieoczekiwane biblioteki przy zaufanych EXE, anomalie w LoadLibrary),
    • Reflective loader artefakty w pamięci, nietypowe sekcje PE, brak na dysku,
    • Nienaturalne wywołania Graph API/tokeny z hostów użytkowników.
  2. Network:
    • Wykrywanie C2 w katalogach WordPress (ścieżki /wp-content/themes/, /plugins/ używane nienormalnie),
    • Egress deny-by-default + TLS inspection dla ruchu do rzadkich hostów,
    • Blokada nietypowych TCP beacons z aplikacji biurowych.
  3. EDR/OS hardening:
    • Windows Defender Application Control / WDAC lub AppLocker do whitelisting’u binarek i DLL,
    • PreferSecureLibraryLoading / Safe DLL Search Mode i blokady znanych ścieżek sideloadingu,
    • ASR rules (blokowanie ładowania DLL z katalogów użytkownika/temp). (Dobre praktyki branżowe w kontekście DLL sideloading).
  4. OSS hygiene:
    • Mirror / hash-pinning dla MuPDF, Notepad++/WinMerge plugins, TightVNC, libpcre itp.; pobrania tylko z verified release z podpisem,
    • SBOM i skan integralności w CI/CD narzędzi inżynierskich,
    • Blokada uruchamiania niepodpisanych plug-inów.
  5. Identity & SaaS:
    • MFA odporne na phishing (FIDO2),
    • Monitorowanie rzadkich grantów i uprawnień Microsoft Graph oraz tworzenia ukrytych rejestracji aplikacji.
  6. User awareness / proces HR:
    • Procedura „oddzielne środowisko” do otwierania dokumentów rekrutacyjnych (sandbox/VDI),
    • Weryfikacja rekruterów (domena, DKIM/DMARC, kontakt przez oficjalny portal),
    • Zakaz instalacji „czytników” przysłanych przez osoby trzecie.

ESET opublikował IoC (domeny, skróty binarek) do tej fali – włącz je do SIEM/EDR i feedów blokujących.

Różnice / porównania z innymi przypadkami

  • Konsekwencja zamiast rewolucji: ScoringMathTea od 2022/2023 r. zmienił się nieznacznie – Lazarus stawia na stabilny, wystarczający zestaw funkcji, a polimorfizm przenosi do warstwy dropperów/loaderów.
  • Nowe biblioteki do proxy’owania DLL i dobór mniej popularnych projektów OSS do trojanizacji zwiększają evasiveness przy zachowaniu tego samego „silnika” C2.
  • Fokus sektorowy: wcześniejsze DreamJob częściej celowały w krypto/IT; obecnie nacisk na UAV i łańcuch dostaw obronności.

Podsumowanie / kluczowe wnioski

Lazarus nie musi przeprojektowywać narzędzi – wystarczy zmieniać nośniki (OSS, wtyczki) i utrzymywać presję socjotechniczną. Organizacje z sektora obronnego, szczególnie UAV, powinny przenieść kontrolę z samej detekcji plików na TTP-first detection & hardening (DLL sideloading, reflective loading, Graph API abuse) oraz uszczelnić procesy HR.

Źródła / bibliografia

  • ESET Research – „Gotta fly: Lazarus targets the UAV sector” (23.10.2025). Najpełniejsza analiza techniczna i kontekst. (welivesecurity.com)
  • ESET Newsroom – komunikat prasowy z kluczowymi tezami i timeline. (ESET)
  • BleepingComputer – omówienie łańcuchów ataku, OSS i IoC. (BleepingComputer)
  • CyberScoop – streszczenie z akcentem na motywację i artefakt „DroneEXEHijackingLoader.dll”. (CyberScoop)
  • Dark Reading – komentarz o stabilności ScoringMathTea i ewolucji DLL proxying. (Dark Reading)

Hakerzy podszywają się pod kirgiskich urzędników. Kampania cyberszpiegowska wymierzona w rosyjskie instytucje (FoalShell & StallionRAT)

Wprowadzenie do problemu / definicja luki

Między majem a sierpniem 2025 r. klaster szpiegowski określany jako Cavalry Werewolf (powiązywany także z nazwami YoroTrooper i Silent Lynx) prowadził kampanię spear-phishingową wymierzoną w rosyjską administrację publiczną oraz firmy z sektorów energii, górnictwa i produkcji. Atakujący podszywali się pod kirgiskie ministerstwa, rozsyłając pisma urzędowe z archiwami RAR zawierającymi autorskie malware: FoalShell (reverse shell) i StallionRAT (RAT sterowany przez bota Telegram) — w części przypadków z wykorzystaniem skompro­m­itowanych prawdziwych skrzynek rządowych.

W skrócie

  • Wejście: spójne stylistycznie maile „z urzędu” (m.in. z resortów gospodarki i transportu KR), nierzadko z prawdziwych, przejętych adresów. Załączniki RAR prowadzą do droppera FoalShell/StallionRAT.
  • Cel: rosyjskie instytucje rządowe + przemysł (energia, górnictwo, produkcja); pojawiają się ślady zainteresowania Tadżykistanem i pliki nazwane po arabsku (rekonesans na Bliski Wschód).
  • TTPs: własne narzędzia, testowanie dodatkowych tooli (np. AsyncRAT), C2 przez Telegram, reverse shell w C# / C++ / Go.
  • Atrybucja historyczna: wcześniejsze badania Cisco Talos łączą YoroTrooper z Kazachstanem (język, waluta, profil celów).

Kontekst / historia / powiązania

YoroTrooper/Silent Lynx obserwowany jest co najmniej od 2022 r., z celami w regionie WNP i placówkach dyplomatycznych. W 2023 r. Talos opublikował obszerny przegląd kampanii YoroTrooper; w 2023–2025 pojawiały się kolejne doniesienia o podszywaniu się pod instytucje państwowe w Azji Centralnej. Najnowsza fala (lato 2025) koncentruje się na Rosji, ale wskazówki językowe i nazewnicze sugerują szersze ambicje geograficzne.

Analiza techniczna / szczegóły luki

Łańcuch infekcji

  1. Spear-phishing: wiadomości stylizowane na korespondencję urzędową (np. „trzymiesięczne wyniki wspólnych działań”, „lista pracowników do premii”), nadane z look-alike’ów lub przejętych kont urzędowych.
  2. Załącznik RAR: zawiera loader prowadzący do FoalShell (reverse shell) lub StallionRAT.
  3. Utrzymanie dostępu i C2:
    • FoalShell: wielojęzyczne implementacje (C#, C++, Go) uruchamiają ukryty cmd.exe i tunelują I/O do C2 (różne adresy IP/443 wg wariantów).
    • StallionRAT: implementacje w Go/PowerShell/Python; komunikacja i polecenia przez bota Telegram (/list, /go, /upload), exfil plików do katalogów publicznych.

Techniki (wybrane mapowanie MITRE ATT&CK):

  • T1566.001 Spear-phishing Attachment (RAR/archiwa) — wektor wejścia.
  • T1059 Command and Scripting Interpreter (PowerShell, cmd.exe).
  • T1105 Ingress Tool Transfer / T1071.001 Application Layer (Telegram jako kanał C2).
  • T1036 Masquerading (wiarygodne nazwy plików, formaty pism).

Dodatkowe obserwacje obronne (DFIR/Threat Hunting):

  • Monitorowanie tworzenia archiwów o nazwach „biurowych” w %LocalAppData%\Microsoft\Windows\INetCache\Content.Outlook\ na stacjach z Outlookiem.
  • Wykrywanie krótkotrwałych procesów cmd.exe uruchamianych przez nietypowych rodziców oraz anomalii w ruchu do Telegram API z hostów korporacyjnych.

Praktyczne konsekwencje / ryzyko

  • Kradzież danych i dostępów w instytucjach publicznych i firmach infrastrukturalnych (ryzyko wtórnych nadużyć, pivotu do OT, kompromitacji łańcucha dostaw).
  • Eskalacja geograficzna: artefakty w jęz. tadżyckim i arabskim wskazują na przygotowania do ataków poza Rosją; organizacje w Azji Centralnej i na Bliskim Wschodzie powinny podnieść czujność.
  • Inżynieria społeczna na brandach państwowych: podszywanie się pod ministerstwa zwiększa skuteczność kliknięć i utrudnia filtrowanie poczty.

Rekomendacje operacyjne / co zrobić teraz

E-mail i brama:

  • Blokowanie RAR/ACE/ISO z poczty do czasu ręcznej weryfikacji; sandboxing archiwów i skryptów.
  • Reguły YARA/EDR pod FoalShell i StallionRAT (na bazie IOCs z publikacji) oraz detekcja wywołań PowerShell z EncodedCommand/Bypass.

Host:

  • Polityki Constrained Language Mode dla PowerShell, Script Block Logging + centralna telemetria.
  • Detections na ukryte uruchomienia cmd.exe i nietypowe parent-child (np. z katalogów tymczasowych/outlook cache).

Sieć:

  • Blokowanie/monitoring ruchu do Telegram z sieci korporacyjnej; TLS inspection na wybranych strefach; listy dozwolonych.

Tożsamość i procesy:

  • Ochrona i audyt skrzynek „wysokiego zaufania” (departamenty: kadry, finanse, protokół dyplomatyczny), MFA i DMARC/DKIM/SPF w trybie reject dla domen urzędowych/partnerskich.

Threat Intel & IR:

  • Konsumpcja IOC/TTP z najnowszych analiz (BI.ZONE, Picus) i korelacja z lokalnymi logami; playbook IR na przypadki Telegram-C2.

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

  • YoroTrooper vs. inne rosyjsko-powiązane APT: Choć część klastrów w regionie bywa łączona z Rosją (np. APT28/Sednit), w przypadku YoroTrooper/Cavalry Werewolf wcześniejsze prace Cisco Talos wskazują na powiązania z Kazachstanem (język, waluta, profil celów), a nie z GRU/FSB. Nie ma jednoznacznej, oficjalnej atrybucji państwowej dla najnowszej fali; Picus jej nie stawia.
  • Kanał C2 przez Telegram odróżnia kampanię od wielu klasycznych operacji (częściej HTTP(S)/mail/OneDrive), choć aplikacyjne C2 pojawiało się już wcześniej u innych aktorów.

Podsumowanie / kluczowe wnioski

Cavalry Werewolf skutecznie eksploatuje zaufanie między instytucjami państwowymi (tu: wizerunek urzędów Kirgistanu), łącząc wysokiej jakości socjotechnikę z lekkimi, autorskimi narzędziami (FoalShell, StallionRAT). Wektor wejścia jest prosty (RAR w e-mailu), ale opakowany w wiarygodne, urzędowe narracje. Organizacje — zwłaszcza w administracji i przemyśle — powinny zaostrzyć polityki pocztowe, telemetrię PowerShell, oraz filtrować/monitorować Telegram jako potencjalny kanał C2.

Źródła / bibliografia

  1. The Record: „Hackers posing as Kyrgyz officials target Russian agencies in cyber espionage campaign”, 23 października 2025. (The Record from Recorded Future)
  2. BI.ZONE: „Espionage clusters disguise themselves as Kyrgyz state officials”, 2 października 2025. (BI.ZONE)
  3. Picus Security: „Cavalry Werewolf APT: Exposing FoalShell and StallionRAT Malware”, 20 października 2025. (Picus Security)
  4. Cisco Talos: „YoroTrooper operators likely based in Kazakhstan”, 25 października 2023. (Cisco Talos Blog)
  5. Cisco Talos: „Talos uncovers espionage campaigns targeting CIS countries… (YoroTrooper)”, 14 marca 2023. (Cisco Talos Blog)

Microsoft wyłącza podgląd w folderze „Pobrane” – nowe zabezpieczenie przed kradzieżą skrótów NTLM

Wprowadzenie do problemu / definicja luki

Microsoft wprowadził zmianę, która automatycznie wyłącza okienko podglądu (Preview Pane) w Eksploratorze plików dla plików pobranych z Internetu i plików oglądanych z udziałów sklasyfikowanych jako Internet Zone. Celem jest zablokowanie kradzieży skrótów NTLM podczas samego zaznaczenia pliku do podglądu – bez otwierania go w aplikacji. Zmiana obowiązuje po instalacji aktualizacji zabezpieczeń z 14 października 2025 r. i nowszych (Windows 11 oraz Windows Server) i jest włączana automatycznie.

W skrócie

  • Co się zmieniło: Eksplorator Windows nie pokaże podglądu plików oznaczonych Mark of the Web (MotW) ani przeglądanych z udziałów w strefie Internet. Zamiast tego zobaczysz komunikat ostrzegawczy.
  • Po co: aby zablokować scenariusze, w których sam podgląd pliku (np. z tagami HTML odwołującymi się do zewnętrznych ścieżek) powodował wysłanie uwierzytelnienia NTLM do serwera atakującego.
  • Kontekst: w 2025 r. udokumentowano aktywnie wykorzystywaną podatność ujawniającą skróty NTLM przy użyciu plików .library-ms rozsyłanych w phishingu.
  • Status: zmiana jest już dystrybuowana w październikowych aktualizacjach, co potwierdził również przegląd branżowy.

Kontekst / historia / powiązania

W pierwszej połowie 2025 r. badacze wskazali, że odpowiednio spreparowane pliki .library-ms mogą wywoływać ujawnienie skrótów NTLM (NTLM hash disclosure) i służyć do relay/brute-force w dalszych etapach ataku. CISA dodała CVE-2025-24054 do katalogu Known Exploited Vulnerabilities, a analizy Check Point opisały aktywne nadużycia od 19 marca 2025 r. w kampaniach phishingowych.

Równolegle Microsoft przyspieszył odchodzenie od NTLM w Windows 11 24H2/Windows Server 2025 (m.in. usunięcie NTLMv1, nowe logowanie audytowe NTLM), jednak pełne wyłączenie NTLMv2 to proces wieloetapowy.

Analiza techniczna / szczegóły luki

  • Vektor ataku: plik oznaczony MotW lub przeglądany z Internet Zone zawiera treści, które w czasie renderowania podglądu (Preview Pane) mogą odwołać się do zasobów zdalnych (np. przez tagi HTML <link>/src> lub podobne mechanizmy w handlerach podglądu).
  • Skutek: system może spróbować uwierzytelnić dostęp do zewnętrznego zasobu przy użyciu NTLM, wysyłając skrót (hash). Napastnik, kontrolując serwer, może przechwycić hash i wykorzystać go w atakach NTLM relay lub do offline cracking.
  • Mitigacja Microsoftu (październik 2025): pełne wyłączenie podglądu dla takich plików – użytkownik widzi komunikat: „The file you are attempting to preview could harm your computer…”. Wyjątki wymagają świadomego odblokowania przez użytkownika/admina.

Ta zmiana minimalizuje interakcję wymaganą od ofiary – wcześniej wystarczało zaznaczenie pliku, teraz podgląd nie zostanie wygenerowany automatycznie.

Praktyczne konsekwencje / ryzyko

  • Użytkownicy końcowi: mniej „cichych” wektorów phishingu – przypadkowe zaznaczenie pliku z poczty/WWW nie wyśle już NTLM.
  • Zespoły IT: możliwe skargi na „brak podglądu” w procesach pracy z pobranymi dokumentami (np. oceną plików). Dla zaufanych źródeł trzeba używać mechanizmu Unblock lub stref Trusted sites/Local intranet – z pełną świadomością, że to obniża poziom ochrony.
  • Zagrożenia, które pozostają: środowiska z włączonym NTLM nadal są podatne na inne kanały wycieku (SMB, WebDAV, Outlook, itp.), stąd potrzeba szerszego hardeningu NTLM i monitoringu.

Rekomendacje operacyjne / co zrobić teraz

  1. Zastosuj październikowe aktualizacje (2025-10-14 i nowsze) na Windows 11/Windows Server. Zmiana włączy się automatycznie.
  2. Zachowaj domyślne wyłączenie podglądu dla plików z MotW/Internet Zone. Nie globalnie odblokowuj, o ile nie jest to absolutnie konieczne.
  3. Jeżeli musisz umożliwić podgląd zaufanych plików:
    • pojedynczy plik: Properties → Unblock (wymaga ponownego logowania, by zadziałało konsekwentnie),
    • udział: dodaj do Trusted sites/Local intranet – pamiętaj, że obniżasz ochronę wszystkich plików z tego udziału.
  4. Ogranicz użycie NTLM w domenie: egzekwuj preferencję Kerberos (Negotiate), wyłącz NTLMv1 (jeśli jeszcze gdzieś żyje), zaplanuj deprecjację NTLMv2 zgodnie ze wskazówkami Microsoft (24H2/Server 2025 wprowadzają audyt ułatwiający inwentaryzację użycia NTLM).
  5. Monitoruj zdarzenia NTLM (Windows 11 24H2 / Server 2025 mają nowe logi: Applications and Services Logs → Microsoft → Windows → NTLM → Operational). Ustal progi alertowania dla nietypowych źródeł/hostów.
  6. Uzupełnij kontrolami towarzyszącymi: ASR/SmartScreen dla MotW, blokady makr, egzekwowanie SMB Signing, segmentacja serwerów, EDR z detekcją NTLM relay. (Wnioski na podstawie kierunku zmian Microsoft i analizy incydentów z CVE-2025-24054).

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

  • W CVE-2025-24054 atak opierał się na plikach .library-ms i mógł zostać zainicjowany już na etapie podglądu/renderowania zasobów; obecna zmiana systemowo ucina ten wektor w Eksploratorze.
  • Wcześniejsze działania Microsoft dotyczyły protokolarnego poziomu NTLM (usuwanie NTLMv1, audyt), natomiast tutaj to zabezpieczenie UX/systemowe w warstwie shell/preview handlers. Razem składają się na obronę w głąb.

Podsumowanie / kluczowe wnioski

Blokada podglądu dla plików z Internetu to prosty, ale skuteczny sposób na wyeliminowanie popularnego wektora kradzieży skrótów NTLM bez zmuszania użytkowników do zmiany nawyków. Dla SOC/IT to dobry moment, by przycisnąć deprecjację NTLM, wdrożyć audyt 24H2/Server 2025 i konsekwentnie redukować wyjątki w Trusted sites.

Źródła / bibliografia

  1. Microsoft Support – File Explorer automatically disables the preview feature for files downloaded from the internet (KB 5070960), 22.10.2025. (Microsoft Support)
  2. BleepingComputer – Microsoft disables File Explorer preview for downloads to block attacks, 23.10.2025. (BleepingComputer)
  3. Check Point Research – CVE-2025-24054: NTLM exploit in the wild, 16.04.2025. (Check Point Research)
  4. CISA – Known Exploited Vulnerabilities Catalog (CVE-2025-24054). (cisa.gov)
  5. Microsoft Support – Overview of NTLM auditing enhancements in Windows 11 24H2 & Windows Server 2025, 11.07.2025; oraz Upcoming changes to NTLMv1…, 29.08.2025. (Microsoft Support)


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)