Archiwa: APT - Strona 28 z 45 - Security Bez Tabu

Tag: APT

RedKitten: irańska kampania szpiegowska z „akceleracją AI” celuje w NGO i aktywistów

Wprowadzenie do problemu / definicja luki

Kampania RedKitten to świeżo zidentyfikowany łańcuch ataku, który wykorzystuje klasyczny wektor „dokument z makrem”, ale dokłada do niego dwie nowoczesne cechy: komodytyzację infrastruktury (usługi chmurowe i komunikatory zamiast własnych serwerów) oraz oznaki LLM-wspomaganego developmentu (styl kodu, komentarze, szybka iteracja). W praktyce to nie „jedna luka CVE”, tylko zestaw technik prowadzących do zdalnej kontroli i eksfiltracji danych.

Badacze HarfangLab opisują tę aktywność jako kampanię obserwowaną na początku stycznia 2026 r., wymierzoną w osoby i organizacje dokumentujące nadużycia praw człowieka.

W skrócie

  • Punkt startu: archiwum (m.in. 7z) z arkuszami XLSM zawierającymi złośliwe makra.
  • Dropper z makra uruchamia implant C# (w raporcie nazwany SloppyMIO) i wykorzystuje AppDomainManager injection jako technikę uruchomienia w kontekście .NET.
  • Konfiguracja i moduły są pobierane z legalnych usług: GitHub oraz Google Drive, a kanał C2 realizowany jest przez Telegram.
  • W infrastrukturze widoczne są elementy steganografii (konfiguracja osadzana w obrazach) oraz iteracyjny rozwój (zmiany w gistach, wersjonowanie).
  • Atrybucja: silne przesłanki na aktora farsi-języcznego powiązanego z interesami państwowymi Iranu, ale bez jednoznacznego przypisania do znanej grupy.

Kontekst / historia / powiązania

Wątek „kittens” to nie przypadek: w ekosystemie threat intel nazewnictwo wielu irańskich klastrów i grup często zawiera „Kitten”. Opisuje to m.in. Middle East Institute w przeglądzie irańskich APT i konwencji nazewniczych.

W tle warto też pamiętać o długiej historii irańskich działań ofensywnych, w tym operacji określanych jako Fox Kitten w bazie MITRE ATT&CK.
Z kolei raport ClearSky Cyber Security (2020) pokazuje, że część irańskich kampanii łączyła rozpoznanie i utrzymanie dostępu z gotowością do eskalacji (np. do działań destrukcyjnych) oraz wykorzystywała szeroką infrastrukturę i dostęp przez zewnętrzne usługi zdalne.

Analiza techniczna / szczegóły luki

1) Initial access: XLSM + makra + socjotechnika

Atak startuje od dokumentów XLSM podszywających się pod materiały związane z ofiarami protestów (tematyka „shock lures”).
W opisie The Hacker News podkreślono oznaki generowania lub wspomagania kodu VBA przez LLM (styl, nazewnictwo, komentarze typu „PART …”).

2) Execution: AppDomainManager injection (w praktyce: .NET-owe „hijackowanie” ładowania)

Makro działa jako dropper dla implantu C# i wykorzystuje technikę AppDomainManager injection.
Z perspektywy obrony to istotne, bo AppDomainManager może umożliwiać wykonanie arbitralnego kodu w procesie .NET poprzez kontrolę sposobu ładowania domen aplikacji i assembly. Dobre omówienie mechaniki i tropów detekcyjnych opisuje Pentest Laboratories.

3) Implant i moduły: SloppyMIO jako „mini-framework” z pobieraniem funkcji na żądanie

W raporcie HarfangLab implant SloppyMIO:

  • cyklicznie odświeża konfigurację,
  • pobiera moduły (źródła .cs lub gotowe DLL),
  • buforuje je (cache) i uruchamia funkcje typu Run().

Wprost opisano też funkcje modułowe, m.in. wykonywanie poleceń, zbieranie plików i wysyłkę danych kanałem C2, z uwzględnieniem limitów rozmiaru wiadomości/dokumentów.

4) C2 i infrastruktura: „legit services only” + steganografia

Najbardziej charakterystyczny fragment tej kampanii to przeniesienie kluczowych elementów w legalne platformy:

  • dead drop/resolver na GitHub (gisty),
  • hostowanie modułów i obrazów na Google Drive,
  • sterowanie przez Telegram (bot token + chat ID w konfiguracji).

HarfangLab opisuje również wersjonowanie „steganographic configuration image” oraz timeline commitów gistów od października 2025 do 23 stycznia 2026 r., co sugeruje iteracyjne dopracowywanie narzędzia i (paradoksalnie) zostawia sporo metadanych.

Praktyczne konsekwencje / ryzyko

  1. Ryzyko dla NGO / OSINT / aktywistów: kradzież dokumentacji, list kontaktów, materiałów dowodowych, metadanych (kto, kiedy, z kim).
  2. Ryzyko organizacyjne: kompromitacja skrzynek, komunikatorów i repozytoriów danych może prowadzić do deanonimizacji źródeł i działań odwetowych.
  3. Utrudnione blokowanie po IP/domenie: jeśli ruch idzie do usług powszechnie używanych (Drive/Telegram), polityka „po prostu zablokuj domenę” bywa nierealna.
  4. Próg wejścia spada: jeśli LLM realnie przyspiesza pisanie makr/loaderów i modułów, to tempo iteracji w kampaniach phishingowych może rosnąć (więcej wariantów, krótsze cykle).

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (0–72h)

  • Zablokuj makra z Internetu w środowisku M365 (Attack Surface Reduction / Office policy) i ogranicz uruchamianie XLSM do zaufanych lokalizacji.
  • Hunting po artefaktach: w raporcie HarfangLab są IOC (hash’e), ścieżki oraz nazwy zaplanowanych zadań (scheduled tasks) i reguły YARA — warto je wciągnąć do procesu detekcji w EDR/SIEM.
  • Telemetria dla .NET: poluj na anomalie wokół AppDomainManager (np. nietypowe pliki konfiguracyjne, podejrzane assembly ładowane przez legalne binarki .NET) – technika bywa używana dla „cichego” wykonania.

Twardnienie i prewencja (1–4 tygodnie)

  • Segmentacja i kontrola egress: jeśli nie możesz zablokować Telegram/Drive globalnie, rozważ:
    • allowlistę procesów/hostów, które mogą rozmawiać z tymi usługami,
    • inspekcję DNS/HTTP(S) pod kątem nietypowych wzorców pobrań modułów.
  • Detekcja „living on popular services”: buduj reguły korelacyjne typu: uruchomienie Office → tworzenie DLL/artefaktów w profilu użytkownika → scheduled task → ruch do Drive/Telegram.
  • Szkolenia anty-phishingowe ukierunkowane na „dokumenty-pułapki” i scenariusze kryzysowe (lures o silnym ładunku emocjonalnym).

Różnice / porównania z innymi przypadkami

  • „Kitteny” różnią się tradecraftem: część historycznych kampanii skupiała się na utrzymaniu dostępu i eksploatacji usług zdalnych (VPN/RDP), co opisywał ClearSky w kontekście Fox Kitten.
  • RedKitten idzie mocno w „legit infra” i automatyzację: zamiast klasycznej infrastruktury C2 – Telegram + Drive + GitHub, do tego steganografia i modułowość.
  • Podobieństwa w „protest lures”: Kaspersky opisywał w 2021 r. kampanię Ferocious Kitten, która także wykorzystywała dokumenty-wabiki z makrami i tematy protestów, a nawet celowała w ekosystem komunikatorów.

Podsumowanie / kluczowe wnioski

  • RedKitten to kampania szpiegowska, która łączy stare dobre makra z nowoczesnym podejściem do infrastruktury (popularne usługi) i prawdopodobnym wsparciem LLM przy wytwarzaniu kodu.
  • Największym wyzwaniem obronnym jest nie sam dropper, tylko detekcja i blokowanie modularnego implantu korzystającego z Drive/Telegram bez wyraźnych „złych domen”.
  • Najbardziej praktyczny krok: twarda polityka dla makr + hunting po IOC/YARA + telemetria .NET pod kątem AppDomainManager.

Źródła / bibliografia

  1. HarfangLab – RedKitten: AI-accelerated campaign targeting Iranian protests (29 stycznia 2026). (HarfangLab)
  2. The Hacker News – opis kampanii i wskazówki dot. LLM-generowanych makr (31 stycznia 2026). (The Hacker News)
  3. MITRE ATT&CK – wpis o Fox Kitten (G0117) i kontekst grup powiązanych (aktualizacje do 2024). (attack.mitre.org)
  4. ClearSky – Fox Kitten – Widespread Iranian Espionage-Offensive Campaign (2020). (clearskysec.com)
  5. Kaspersky – A 6-year cyberespionage campaign… (Ferocious Kitten, 2021). (Kaspersky)

Polska wskazuje Static Tundra jako sprawcę destrukcyjnych ataków na energetykę z 29 grudnia 2025 – co wiemy o DynoWiper, FortiGate i wektorach OT/IT

Wprowadzenie do problemu / definicja luki

29 grudnia 2025 r. w Polsce odnotowano skoordynowaną serię ataków o czysto destrukcyjnym celu (w raporcie porównywaną do „cyfrowego podpalenia”). Kampania objęła ponad 30 farm wiatrowych i fotowoltaicznych, firmę z sektora produkcyjnego oraz dużą elektrociepłownię (CHP) dostarczającą ciepło dla ok. pół miliona odbiorców. Kluczowe jest to, że incydent dotknął jednocześnie środowisk IT i OT, co nadal jest rzadkością w publicznie opisywanych zdarzeniach.

Wąskim gardłem nie była „jedna magiczna luka CVE”, tylko kombinacja: ekspozycja zdalnego dostępu, słabe uwierzytelnianie (w tym brak MFA), odziedziczone konfiguracje i praktyki (np. powtarzanie kont/ haseł między lokalizacjami), a następnie konsekwentna automatyzacja działań destrukcyjnych w sieciach stacyjnych/zakładowych.

W skrócie

  • Ataki z 29.12.2025 były skoordynowane i nastawione na sabotaż (niszczenie danych/urządzeń), a nie ransomware.
  • Wektor na obiektach OZE: urządzenia FortiGate jako VPN/firewall z wystawionym interfejsem VPN do Internetu, bez MFA; dodatkowo pojawia się wątek reuse’owania poświadczeń między obiektami.
  • W OT obserwowano m.in. działania na RTU/HMI: użycie domyślnych danych logowania (np. na kontrolerach) i próby uszkadzania/wymazywania systemów oraz elementów sterowania.
  • CERT Polska przypisał aktywność klastrowi Static Tundra (powiązywanemu z FSB / Center 16), podczas gdy część analiz zewnętrznych (m.in. ESET) wskazuje na możliwe związki z Sandworm.
  • Rząd podkreśla, że Polska obroniła się przed skutkami typu blackout, ale incydent potraktowano jako sygnał do dalszego wzmacniania systemu.

Kontekst / historia / powiązania

W ostatnich latach granica między „APT do szpiegostwa” a „APT do sabotażu” coraz częściej się zaciera. W tym incydencie istotne są dwa równoległe wątki:

  1. Atrybucja państwowa: według informacji opisywanych publicznie, strona polska wskazuje na rosyjską służbę (FSB) jako prawdopodobnego sprawcę, a sam incydent miał miejsce w okresie niskich temperatur i śnieżyc, co zwiększało potencjalną presję operacyjną na energetykę i ciepłownictwo.
  2. Spór o „kto dokładnie”: CERT przypisuje kampanię klastrowi Static Tundra, natomiast część badaczy zwraca uwagę na podobieństwa wipera DynoWiper do wcześniejszych narzędzi kojarzonych z Sandworm (w tym do wipera nazwanego przez ESET „ZOV”). To klasyczny przypadek, gdzie malware similarity ≠ jednoznaczna atrybucja, bo narzędzia i techniki mogą być współdzielone, odsprzedawane lub kopiowane.

Analiza techniczna / szczegóły luki

1) OZE i punkt przyłączenia (GCP): FortiGate jako brama wejścia

Raport wskazuje, że w badanych obiektach OZE urządzenia typu FortiGate pełniły rolę koncentratora VPN i firewalla. W każdym przypadku interfejs VPN był wystawiony do Internetu i dopuszczał uwierzytelnianie kontami z konfiguracji bez MFA. Ze względu na destrukcję, nie zawsze udało się odzyskać komplet logów, ale z analizy wynika, że część urządzeń bywała w przeszłości podatna (w tym na klasy błędów umożliwiających RCE) przez dłuższe okresy.

Dodatkowo pojawia się ważna obserwacja operacyjna: w branży ma być powszechne powtarzanie kont i haseł między wieloma lokalizacjami. To oznacza, że kompromitacja jednego obiektu może stać się „kluczem głównym” do kolejnych.

2) OT: RTU, przekaźniki zabezpieczeniowe, HMI – sabotaż zamiast tylko IT

W części środowisk sterowania obserwowano działania, które nie polegały wyłącznie na niszczeniu plików na stacjach roboczych, ale również na destabilizacji komponentów OT (np. poprzez logowanie z domyślnymi poświadczeniami i wykonywanie komend destrukcyjnych na kontrolerach). To szczególnie niebezpieczne, bo „wymazanie” lub uszkodzenie urządzeń OT może wymagać interwencji terenowej i wydłużać czas odtworzenia usług.

3) Wipery i dystrybucja: DynoWiper i LazyWiper oraz GPO/PowerShell

CERT opisuje użycie wcześniej niekojarzonych rodzin wiperów, których celem było nieodwracalne niszczenie danych, bez elementu wymuszenia okupu. W raporcie rozróżniono scenariusze uruchomienia: w środowiskach OZE malware miał być odpalany bezpośrednio na maszynie HMI, a w elektrociepłowni i firmie produkcyjnej dystrybucja odbywała się w domenie Active Directory przez skrypt PowerShell uruchomiony na kontrolerze domeny (model „szybkiego rażenia” wielu hostów).

4) Firma produkcyjna: kompromitacja urządzenia brzegowego i persistence

W przypadku firmy produkcyjnej opisano dostęp przez urządzenie brzegowe Fortinet, a także modyfikacje konfiguracji, które miały zapewnić trwałość dostępu nawet po zmianach haseł (m.in. poprzez mechanizmy skryptowe na urządzeniu).

5) Atrybucja techniczna: „Static Tundra” i zastrzeżenia dot. podobieństw do Sandworm

CERT wskazuje, że infrastruktura i charakterystyki komunikacji pokrywają się z tym, co publicznie opisywano dla klastra „Static Tundra”, a jednocześnie zaznacza, że podobieństwa DynoWiper do wiperów wiązanych z Sandworm są zbyt ogólne, by same w sobie przesądzały o sprawstwie.
Z kolei ESET opisuje podobieństwa DynoWiper do ich wcześniejszych obserwacji destrukcyjnego malware przypisywanego Sandworm (ZOV), przy jednoczesnym zastrzeżeniu, że nie wszystkie elementy operacji muszą pochodzić od jednej grupy.

Praktyczne konsekwencje / ryzyko

  1. Ryzyko kaskadowe w OZE: nawet jeśli pojedyncza farma nie destabilizuje systemu, równoległe uderzenie w dziesiątki obiektów zwiększa obciążenie operatorów, czas reakcji i ryzyko błędów proceduralnych.
  2. Czas odtworzenia w OT: urządzenia sterujące, RTU czy elementy telemechaniki mogą wymagać fizycznej wymiany/ponownego wgrania firmware’u i walidacji – a to oznacza realny koszt i przestoje.
  3. Eskalacja intencji: publicznie podkreślano, że to incydent „sabotażowy” i jeden z poważniejszych tego typu w ostatnich latach. Taki sygnał zmienia model zagrożeń dla firm, które dotychczas projektowały ochronę głównie pod wyciek danych lub phishing.

Rekomendacje operacyjne / co zrobić teraz

Poniżej „checklista” w kolejności od działań o najwyższym ROI do bardziej złożonych:

1) Zdalny dostęp (VPN/edge) – natychmiastowe „higieniczne minimum”

  • Włącz MFA wszędzie, gdzie jest zdalny dostęp administracyjny lub operatorski (VPN, portale, jump-hosty). Brak MFA pojawia się wprost jako element ryzyka.
  • Wymuś unikalne konta i hasła per obiekt (koniec z re-use między farmami/lokalizacjami).
  • Audyt urządzeń brzegowych: aktualizacje, przegląd ekspozycji usług, usunięcie „starych” reguł i kont technicznych.

2) Segmentacja IT/OT i kontrola ścieżek lateral movement

  • Odseparuj domenę/AD od stref OT (lub przynajmniej twardo kontroluj relacje zaufania, konta serwisowe i ścieżki RDP/SMB).
  • W OT: dopuszczaj tylko niezbędne protokoły i kierunki komunikacji; rozważ jump-serwery z silnym uwierzytelnianiem i pełnym logowaniem.

3) Eliminacja domyślnych poświadczeń i twardnienie urządzeń OT

  • Usuń domyślne hasła/konta na RTU/HMI i urządzeniach pośredniczących (to w raporcie pojawia się jako realny wektor destrukcji).
  • Włącz i egzekwuj mechanizmy weryfikacji firmware (tam, gdzie dostępne) oraz kontroluj proces aktualizacji i źródła obrazów.

4) Odporność na wipery

  • Kopie zapasowe offline/immutable + testy odtworzenia (nie „mamy backup”, tylko RTO/RPO na stole).
  • EDR/monitoring na kontrolerach domeny i serwerach zarządzających: wykrywanie nietypowych działań PowerShell/GPO, masowych modyfikacji polityk, nietypowych zadań harmonogramu itp. (w raporcie opisano dystrybucję przez skrypt i domenę).

5) Przygotowanie organizacyjne

  • Scenariusze IR dla sabotażu (wiper/OT): procedury izolacji, odcięcia zdalnego dostępu, przełączeń ręcznych, kontaktów vendor/PSIRT.
  • W sektorze energii: ćwiczenia „table-top” łączące zespoły SOC + automatycy + utrzymanie ruchu.

Różnice / porównania z innymi przypadkami

Static Tundra (FSB) vs Sandworm (GRU) w tym incydencie sprowadza się do pytania: czy obserwujemy „nową fazę” tej samej grupy, współdzielenie narzędzi, czy operację mieszaną?

  • CERT argumentuje atrybucję do klastra Static Tundra m.in. na podstawie infrastruktury i jej charakterystyk, jednocześnie traktując podobieństwa DynoWiper do narzędzi sandwormowych jako niewystarczające do twardej identyfikacji.
  • ESET widzi techniczne podobieństwa DynoWiper do ZOV i łączy je z Sandworm, ale też dopuszcza, że elementy operacji mogły być rozdzielone między różne podmioty.
  • Publiczne doniesienia podkreślają, że polskie władze wskazały na FSB jako prawdopodobnego sprawcę, a sama operacja była postrzegana jako eskalacja w stronę działań destrukcyjnych.

W praktyce dla obrońców wniosek jest prosty: modeluj zagrożenie po TTP, nie po etykiecie grupy. Jeśli masz ekspozycję VPN bez MFA, re-use poświadczeń i słabą separację IT/OT – „kto” jest drugorzędne wobec „jak szybko może to powtórzyć ktoś inny”.

Podsumowanie / kluczowe wnioski

  • To był incydent, w którym sabotaż cyfrowy dotknął jednocześnie IT i OT, a celem było niszczenie, nie zysk.
  • Najbardziej „przyziemne” problemy (MFA, unikalne hasła, ekspozycja VPN, domyślne konta) okazały się krytyczne w skali krajowej.
  • Atrybucja (Static Tundra vs Sandworm) jest ważna politycznie, ale operacyjnie kluczowe są powtarzalne techniki: kompromitacja edge, ruch boczny, a potem szybka destrukcja (w tym przez mechanizmy domenowe).
  • Nawet gdy nie doszło do blackoutu, incydent pokazuje, że odporność musi obejmować wipery + OT recovery, a nie tylko ochronę przed wyciekiem danych.

Źródła / bibliografia

  1. Raport techniczny CERT: „Energy Sector Incident Report – 29 December 2025”. (cert.pl)
  2. Artykuł: The Hacker News – podsumowanie i kontekst (DynoWiper/LazyWiper, wątki FortiGate, przypisanie do Static Tundra). (The Hacker News)
  3. Analiza: ESET – „DynoWiper update: Technical analysis and attribution”. (welivesecurity.com)
  4. Komunikat rządowy: Gov.pl – o odparciu ataku i działaniach wzmacniających. (Gov.pl)
  5. Depesza: Reuters – wątek przypisania i komentarze ekspertów. (Reuters)

Google rozbija IPIDEA: „domowy” rynek proxy używany przez cyberprzestępców i grupy APT traci miliony węzłów

Wprowadzenie do problemu / definicja „luki”

IPIDEA to przykład residential proxy network – usługi, która sprzedaje możliwość kierowania ruchu przez prawdziwe, domowe adresy IP (należące do operatorów ISP), często bez pełnej, świadomej zgody użytkowników końcowych. Taki model jest szczególnie atrakcyjny dla atakujących, bo ruch wygląda jak „normalny” (pochodzi z mieszkań i małych firm), przez co trudniej go odfiltrować prostymi listami blokad i heurystykami.

W styczniu 2026 Google Threat Intelligence Group (GTIG) przeprowadził skoordynowane działania, które – według Google – zdegradowały możliwości IPIDEA i zmniejszyły pulę dostępnych urządzeń o „miliony”.

W skrócie

  • Google podjął kroki prawne wobec domen C2 i domen „biznesowych” (marketing/SDK), aby odciąć kontrolę nad węzłami i dystrybucję ekosystemu IPIDEA.
  • GTIG wskazuje, że w 7-dniowym oknie w styczniu 2026 ponad 550 śledzonych grup korzystało z wyjściowych IP IPIDEA do maskowania działań (w tym aktorzy powiązani z Chinami, KRLD, Iranem i Rosją).
  • Google zidentyfikował ponad 600 aplikacji na Androida oraz 3 075 unikalnych plików na Windows powiązanych z infrastrukturą.
  • Google wymusił egzekwowanie polityk platformy: Play Protect ma automatycznie ostrzegać, usuwać aplikacje z SDK IPIDEA i blokować ponowne instalacje (na certyfikowanych urządzeniach).
  • IPIDEA zaprzecza intencjonalnie „złośliwemu” modelowi, twierdząc m.in. że wymaga od integratorów komunikatu o roli urządzenia jako exit node i że posiada mechanizmy KYC/antyabuzywne, ale przyznaje, że „otwarta sieć” może być nadużywana i że część resellerów nie wdraża rygorów w pełni.

Kontekst / historia / powiązania

GTIG opisuje IPIDEA jako element szerszego, dynamicznie rosnącego „szarego rynku” dostępu do cudzej przepustowości i adresów IP, który bywa wykorzystywany do działań cyberprzestępczych i szpiegowskich.

W blogu Google pojawiają się także powiązania z botnetami – GTIG wskazuje, że SDK i/lub proxy software IPIDEA odegrały rolę w kontekście BadBox2.0 (wcześniejsze działania prawne Google) oraz botnetów Aisuru i Kimwolf.

Analiza techniczna / szczegóły „luki” (jak działał model IPIDEA)

1. Mechanizm: SDK w aplikacjach → urządzenie jako „exit node”

Kluczowy element to SDK/komponenty proxy oferowane deweloperom. Po osadzeniu w aplikacji (np. gra, narzędzie, aplikacja „contentowa”) urządzenie użytkownika może zostać dołączone do sieci i pełnić rolę węzła wyjściowego dla klientów proxy. Deweloperzy mieli być wynagradzani zwykle per instalacja/pobranie.

GTIG podkreśla, że urządzenia trafiają do takich sieci zarówno przez aplikacje „trojanizowane” (użytkownik nieświadomy), jak i przez programy obiecujące „monetyzację” wolnego pasma (użytkownik bywa skłaniany obietnicą zysku).

2. Skala i wieloplatformowość

Google opisuje kompatybilność SDK dla Android, Windows, iOS i WebOS, co zwiększa zasięg i utrudnia „jednopunktowe” przecięcie problemu.

3. Co konkretnie zrobił Google (warstwa infrastruktury i ekosystemu)

Działania miały trzy filary:

  1. kroki prawne przeciw domenom używanym do kontroli urządzeń i routowania ruchu (C2 / proxy traffic),
  2. wymiana informacji technicznej (SDK, proxy software) z platformami, organami ścigania i partnerami branżowymi,
  3. wzmocnienie ochrony użytkowników Androida przez Play Protect (ostrzeżenia, usuwanie, blokowanie instalacji). )

Współpraca obejmowała m.in. Cloudflare (utrudnienie rozwiązywania domen), a także firmy badawcze, takie jak Spur i Lumen Black Lotus Labs w zakresie zrozumienia skali i nadużyć rynku.

Praktyczne konsekwencje / ryzyko

Dla użytkowników końcowych

  • Użycie Twojego IP jako „twarzy” ataku: cudzy ruch (np. skanowanie, próby logowania, nadużycia) może wychodzić z Twojego łącza, co skutkuje blokadami, reputacją „podejrzanego” IP i problemami z usługami.
  • Ryzyko dla sieci domowej: GTIG ostrzega, że gdy urządzenie staje się exit node, nie tylko przepuszcza ruch – mogą pojawić się scenariusze, w których ruch jest także kierowany „do” urządzenia w celu jego kompromitacji, co rozszerza ryzyko na inne sprzęty w tej samej sieci.

Dla firm (SOC/Blue Team)

  • Zaciemnienie telemetrii: ataki wyglądają jak pochodzące z konsumenckich ASN/IP, co utrudnia reguły oparte o „data center IP reputation”.
  • Typowe wzorce nadużyć obserwowane przez GTIG przy użyciu exit nodes IPIDEA obejmowały m.in. dostęp do środowisk SaaS, infrastruktury on-prem oraz password spraying.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników (endpoint / mobile)

  1. Włącz i nie wyłączaj Play Protect na certyfikowanych urządzeniach z Google Play Services – Google deklaruje automatyczne wykrywanie/usuwanie aplikacji z SDK IPIDEA i blokowanie ponownej instalacji.
  2. Unikaj aplikacji obiecujących pieniądze za „udostępnianie internetu / niewykorzystane pasmo” – GTIG wskazuje ten wzorzec jako kluczowy mechanizm wzrostu takich sieci.
  3. Przeglądnij aplikacje VPN/proxy i narzędzia „utility” (zwłaszcza spoza głównych sklepów) pod kątem podejrzanych zachowań sieciowych.

Dla organizacji (SOC/IT)

  1. Wykrywanie i blokowanie IOCs: GTIG opublikował zestawy wskaźników (m.in. domeny) w kolekcji dla użytkowników z dostępem – warto je wciągnąć do procesu threat hunting i filtrów DNS/Proxy.
  2. Polityki dostępu i odporność na password spraying: MFA, rate limiting, detekcje anomalii logowań, blokady na poziomie IdP oraz warunkowy dostęp (risk-based). (To bezpośrednio adresuje obserwowane przez GTIG wzorce nadużyć).
  3. Kontrola egress + DNS telemetry: szukaj nietypowych, długotrwałych połączeń do nieznanych domen/hostów, szczególnie na stacjach roboczych użytkowników i urządzeniach mobilnych w MDM.
  4. Edukacja i polityka SDK: jeśli rozwijasz aplikacje, wprowadź formalny proces oceny ryzyka dla SDK „monetyzacyjnych” i komponentów sieciowych (to jeden z głównych wektorów „legalnie wyglądającego” wdrożenia).

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

  • Ten przypadek wyróżnia się uderzeniem jednocześnie w infrastrukturę (C2/domeny), dystrybucję (domeny marketing/SDK) i warstwę ochrony endpointów (Play Protect), zamiast ograniczyć się do samego blokowania IP czy zdejmowania pojedynczych aplikacji.
  • GTIG wiąże IPIDEA z wcześniejszymi obserwacjami botnetów (w tym BadBox2.0) oraz zwraca uwagę na nakładanie się pul exit nodes między dostawcami (resellerzy/partnerstwa), co utrudnia „twardą” atrybucję i kwantyfikację.

Podsumowanie / kluczowe wnioski

Rozbicie infrastruktury IPIDEA pokazuje, że „domowe proxy” to nie tylko narzędzie do web scrapingu, ale realny komponent łańcuchów ataku, używany do maskowania kampanii przestępczych i APT. Według GTIG mówimy o ekosystemie w skali milionów urządzeń, wykorzystywanym przez setki grup w krótkim oknie czasowym.

Dla obrony kluczowe są dwie rzeczy: (1) traktowanie ruchu z „rezydencjalnych” IP jako potencjalnie wrogiego w kontekście logowań i nadużyć oraz (2) ograniczanie wektorów „legalnej” dystrybucji przez niezweryfikowane SDK monetyzacyjne.

Źródła / bibliografia

  1. Google Threat Intelligence Group – „No Place Like Home Network: Disrupting the World’s Largest Residential Proxy Network” (28 stycznia 2026). (Google Cloud)
  2. SecurityWeek – „Google Disrupts IPIDEA Proxy Network” (29 stycznia 2026). (SecurityWeek)
  3. Reuters – „Google disrupts large residential proxy network…” (28 stycznia 2026). (Reuters)
  4. Help Net Security – „Google disrupts proxy network used by 550+ threat groups” (29 stycznia 2026). (Help Net Security)
  5. iTnews – „Global proxy operator IPIDEA denies Google’s malicious intent allegations” (30 stycznia 2026). (iTnews)

OpenSSL łata lukę wysokiej wagi mogącą prowadzić do RCE (CVE-2025-15467). Co trzeba wiedzieć i zrobić

Wprowadzenie do problemu / definicja luki

Pod koniec stycznia 2026 r. projekt OpenSSL opublikował aktualizacje bezpieczeństwa usuwające łącznie 12 podatności, w tym jedną oznaczoną jako High – CVE-2025-15467 – która w określonych warunkach może prowadzić do remote code execution (RCE).

Kluczowe jest to, że nie mówimy o “zwykłym TLS do HTTPS” w oderwaniu od reszty świata, tylko o podatnej ścieżce w parsowaniu CMS/PKCS#7, w szczególności struktur CMS AuthEnvelopedData korzystających z AEAD (np. AES-GCM). Jeśli Twoje środowisko przyjmuje lub przetwarza taki format z niezaufanego źródła (bramki S/MIME, systemy PKI/CA, import certyfikatów, workflow dokumentów podpisanych/szyfrowanych), temat robi się pilny.

W skrócie

  • CVE: CVE-2025-15467 (High) – stack buffer overflow w obsłudze CMS AuthEnvelopedData przy AEAD.
  • Skutek: crash/DoS, a potencjalnie RCE (zależnie od platformy i mitigacji kompilatora/systemu).
  • Warunek wejścia: aplikacja/usługa parsuje niezaufane CMS/PKCS#7 z AEAD; overflow zachodzi przed weryfikacją integralności/tagu.
  • Wersje podatne (gałęzie 3.x):
    • 3.6.0 → przed 3.6.1
    • 3.5.0 → przed 3.5.5
    • 3.4.0 → przed 3.4.4
    • 3.3.0 → przed 3.3.6
    • 3.0.0 → przed 3.0.19
  • Nie dotyczy: OpenSSL 1.1.1 i 1.0.2 (wprost oznaczone jako niepodatne).
  • FIPS: moduły FIPS dla serii 3.x nie są dotknięte, bo implementacja CMS jest poza granicą modułu.
  • Kontekst wydania: w tym samym pakiecie łatek jest też podatność moderate (CVE-2025-11187) i 10 low.

Kontekst / historia / powiązania

Informację o wydaniu łatek opisał m.in. SecurityWeek, podkreślając, że wszystkie 12 podatności zostały odkryte przez jedną firmę (Aisle), przy użyciu autonomicznego analizatora.

Datadog Security Labs zwraca uwagę na jeszcze jeden aspekt: OpenSSL rzadko nadaje “high” podatnościom potencjalnie prowadzącym do RCE, a to wydanie jest zauważalne także z perspektywy klas wejścia danych (CMS/PKCS#12), które występują w realnych pipeline’ach bezpieczeństwa (poczta, PKI, importy/eksporty).

Analiza techniczna / szczegóły luki

Co dokładnie się psuje?

CVE-2025-15467 to przepełnienie bufora na stosie podczas parsowania parametrów ASN.1 dla AEAD w strukturach CMS AuthEnvelopedData. W praktyce problem dotyczy pola IV (Initialization Vector): zakodowana w ASN.1 długość IV jest kopiowana do bufora o stałym rozmiarze bez wystarczającej walidacji, co pozwala doprowadzić do zapisu poza buforem (out-of-bounds write).

Dlaczego “pre-auth” ma znaczenie?

Overflow występuje przed weryfikacją tagu uwierzytelniającego/integrowości, więc atakujący nie musi posiadać poprawnych kluczy ani generować poprawnej kryptograficznie wiadomości, aby “trafić” w podatną ścieżkę. To podnosi realność ataku wszędzie tam, gdzie parser może zetknąć się z danymi od strony napastnika (np. inbound e-mail, upload pliku, integracje B2B).

RCE vs DoS

OpenSSL i NVD opisują skutki jako DoS (najbardziej typowy) oraz potencjalne RCE, zależne od platformy i mitigacji (ASLR, stack canaries, CET, hardening kompilacji, układ stosu itp.). To klasyczny przypadek: błąd pamięci daje prymityw zapisu na stosie, ale droga do stabilnego RCE bywa różna w zależności od środowiska uruchomieniowego.

Praktyczne konsekwencje / ryzyko

Kto jest najbardziej narażony?

Najwyższe ryzyko mają systemy, które:

  • automatycznie przetwarzają niezaufane CMS/PKCS#7 (np. bramki S/MIME, systemy DLP/MTA z funkcjami dekryptażu/analizy, integratory EDI/archiwizacji zabezpieczonej wiadomości),
  • oferują import materiału kryptograficznego/struktur (workflow certyfikatów, PKI tooling),
  • mają bibliotekę OpenSSL 3.x jako zależność i nie mają pełnej kontroli nad formatem danych wejściowych.

Jeśli OpenSSL jest używany głównie do handshake TLS, a aplikacja nie dotyka CMS/PKCS#7 z niezaufanych źródeł, osiągalność podatnej ścieżki bywa ograniczona. Datadog wprost sugeruje takie rozróżnienie w ocenie ekspozycji.

Wpływ na dystrybucje i pakiety systemowe

Dystrybucje publikują własne biuletyny i backporty. Przykładowo Ubuntu w swoim USN opisuje CVE-2025-15467 jako błąd prowadzący do crash/DoS przy niepoprawnym parsowaniu CMS AuthEnvelopedData. To ważne, bo w praktyce “wersja OpenSSL” w systemie często oznacza “wersję pakietu distro”, a nie upstream tarball.

Rekomendacje operacyjne / co zrobić teraz

  1. Zidentyfikuj ekspozycję (reachability), nie tylko wersję
  • Sprawdź, czy w Twoim środowisku istnieje komponent parsujący CMS/PKCS#7 / S/MIME AuthEnvelopedData z danych od użytkownika/Internetu (MTA, gateway, usługi importu, API upload).
  1. Zaktualizuj do wersji naprawionych
    Minimalne wersje naprawione dla gałęzi 3.x (wg OpenSSL):
  • 3.0.19, 3.3.6, 3.4.4, 3.5.5, 3.6.1
    W praktyce w środowiskach produkcyjnych często aktualizujesz pakiet systemowy (np. przez apt/yum/zypper) – wtedy kieruj się biuletynem dostawcy (np. USN w Ubuntu).
  1. Uważaj na “własny OpenSSL” w runtime’ach i kontenerach
    Niektóre środowiska mogą dostarczać własne buildy OpenSSL (np. część runtime’ów/obrazów). Datadog podkreśla, że samo podbicie pakietu systemowego nie zawsze wystarczy – czasem trzeba zaktualizować cały runtime/artefakt.
  2. Mitigacje tymczasowe (jeśli nie możesz patchować natychmiast)
  • Ogranicz/wyłącz przetwarzanie niezaufanego S/MIME/CMS AuthEnvelopedData tam, gdzie to możliwe (polityki gateway, izolacja pipeline’u, sandbox).
  • Rozważ uruchamianie parserów w izolacji (separacja procesu, seccomp/AppArmor/SELinux, ograniczenia uprawnień) – to nie naprawia błędu, ale redukuje blast radius w scenariuszu RCE. (To jest dobra praktyka ogólna przy parserach danych binarnych.)
  1. Monitoring i IR
    Na dziś opisy źródłowe skupiają się na aktualizacji i ocenie ekspozycji; nie wynika z nich jednoznacznie, że istnieje masowa eksploatacja “in the wild”. Mimo to, traktuj to jak podatność parsera: monitoruj crashe procesów (segfault), wzrost błędów w usługach mail/PKI oraz nietypowe wejścia CMS/PKCS#7.

Różnice / porównania z innymi przypadkami

  • Nie “kolejny Heartbleed”: wektor jest znacznie bardziej specyficzny – dotyczy parsowania CMS AuthEnvelopedData z AEAD, a nie każdego połączenia TLS. To dobra wiadomość dla typowych serwerów WWW, ale zła dla systemów, które masowo obrabiają S/MIME/CMS.
  • Waga “High” i potencjalne RCE: Datadog zauważa, że OpenSSL rzadko klasyfikuje potencjalne RCE aż tak wysoko, co sugeruje ostrożność w bagatelizowaniu tego jako “tylko DoS”.
  • Podobieństwo klasowe: to klasyczny błąd pamięci (CWE-787 / out-of-bounds write) – a więc kategoria, która historycznie bywa trudna w ocenie “czy to na pewno RCE”, bo dużo zależy od kompilacji i mitigacji.

Podsumowanie / kluczowe wnioski

  • CVE-2025-15467 to High w OpenSSL 3.x: przepełnienie stosu w parsowaniu CMS AuthEnvelopedData (AEAD).
  • Realny wpływ zależy od tego, czy Twoja aplikacja parsuje niezaufane CMS/PKCS#7 – w takich środowiskach priorytet patchowania powinien być wysoki.
  • Aktualizuj do: 3.0.19 / 3.3.6 / 3.4.4 / 3.5.5 / 3.6.1 (lub odpowiednich backportów dystrybucji).
  • Jeśli nie możesz patchować natychmiast: ogranicz powierzchnię (S/MIME/CMS), izoluj parsery, wzmocnij monitoring crashy – ale traktuj to jako rozwiązania przejściowe.

Źródła / bibliografia

  1. OpenSSL Library – Vulnerabilities 3.4 (CVE-2025-15467; wersje podatne i naprawione, opis podatności). (openssl-library.org)
  2. OpenSSL Library – Vulnerabilities (opis wpływu i scenariuszy CMS/PKCS#7). (openssl-library.org)
  3. NVD – CVE-2025-15467 (opis techniczny, CWE-787, referencje). (NVD)
  4. Datadog Security Labs – analiza styczniowego wydania OpenSSL 2026 (kontekst, reachability, wskazówki oceny). (securitylabs.datadoghq.com)
  5. SecurityWeek – informacja o wydaniu i kontekście (12 podatności, CVE-2025-15467 jako High). (SecurityWeek)
  6. Ubuntu Security Notice USN-7980-1 (perspektywa dystrybucji / pakietów). (Ubuntu)

Mustang Panda (HoneyMyte) rozwija CoolClient: nowe moduły kradzieży danych z przeglądarek i monitor schowka

Wprowadzenie do problemu / definicja luki

Chińsko-powiązana grupa szpiegowska znana jako Mustang Panda (w nomenklaturze części dostawców także HoneyMyte / Earth Preta / Bronze President) zaktualizowała swój backdoor CoolClient tak, aby skuteczniej wspierał kradzież danych uwierzytelniających i „życie z zasobów” (LOTL) w środowiskach ofiar. Najważniejsza zmiana: CoolClient nie jest już wyłącznie furtką do zdalnego dostępu, ale stał się platformą do wdrażania infostealerów (kradzież logowań z przeglądarek) oraz monitorowania schowka i aktywnego okna.

W skrócie

  • Nowy CoolClient potrafi monitorować schowek i śledzić tytuły aktywnych okien, a także podsłuchiwać poświadczenia do proxy HTTP.
  • W kampaniach zaobserwowano trzy rodziny stealerów: pod Chrome, Edge oraz wariant „uniwersalny” dla przeglądarek Chromium.
  • Eksfiltracja danych (np. cookies) może wykorzystywać legalne usługi (np. Google Drive) i tokeny/API wbudowane w operacje, co utrudnia detekcję po samym „dokąd wychodzi ruch”.
  • Cele kampanii to m.in. instytucje rządowe w kilku krajach Azji oraz poza nią (m.in. Myanmar, Mongolia, Malezja, Rosja, Pakistan).

Kontekst / historia / powiązania

CoolClient jest kojarzony z Mustang Panda co najmniej od 2022 r. i bywał wdrażany jako dodatkowa furtka obok innych znanych implantów tej klasy (np. PlugX, LuminousMoth).
Z perspektywy „rodziny” aktora warto pamiętać, że różni dostawcy opisywali go pod wieloma nazwami (np. Earth Preta), a kampanie często opierały się o spreparowane archiwa-przynęty i klasyczny spear-phishing.
W 2025 r. IBM X-Force wskazywał na szeroki arsenał i nakładające się klastry aktywności przypisywane temu ekosystemowi (m.in. ToneShell/Pubload oraz nowe techniki dystrybucji), co dobrze tłumaczy, dlaczego CoolClient jest dziś „rozbudowywany” zamiast zastępowany.

Analiza techniczna / szczegóły luki

1) Łańcuch uruchomienia i wieloetapowość (.DAT)

Z obserwacji badaczy wynika, że CoolClient korzysta z zaszyfrowanych plików .DAT i wieloetapowego wykonania. W opisie Kaspersky widoczny jest schemat, w którym implant:

  • odszyfrowuje kolejne artefakty (np. time.dat, loader.dat, main.dat),
  • uruchamia proces-pośrednik (write.exe) i wstrzykuje do niego kolejny etap,
  • buduje trwałość przez Run key, usługę systemową oraz zaplanowane zadanie.

2) Utrzymanie uprawnień i „passuac”

Warianty widziane w terenie wspierają obejście UAC i eskalację: przy sprzyjających warunkach uruchamiany jest tryb „passuac”, a następnie ustawiana jest trwałość przez zadanie harmonogramu.

3) Nowe funkcje: schowek, aktywne okno, sniffing proxy

Nowością w aktualnych wariantach jest:

  • monitor schowka (m.in. poprzez typowe API systemowe używane przez clipboard stealery),
  • telemetria aktywnego okna (np. tytuł okna),
  • HTTP proxy credential sniffer oparty o inspekcję pakietów i ekstrakcję nagłówków.

4) Ekosystem pluginów i zdalna powłoka

CoolClient utrzymuje architekturę z pluginami ładowanymi w pamięci, rozszerzoną m.in. o:

  • plugin zdalnej powłoki (ukryty cmd.exe, I/O przez potoki),
  • plugin zarządzania usługami (enumeracja, start/stop, modyfikacje),
  • rozbudowany plugin menedżera plików (mapowanie dysków sieciowych, kompresja ZIP, wyszukiwanie, uruchamianie plików).

5) Infostealery: Chrome/Edge/Chromium i eksfiltracja „przez legalne chmury”

W operacjach udokumentowano wdrażanie stealerów kradnących loginy z przeglądarek (różne warianty pod Chrome, Edge i Chromium-based).
Co istotne operacyjnie: w części przypadków eksfiltracja (np. pliki cookies) była wykonywana narzędziowo (np. przez curl) do legalnych usług typu Google Drive, z użyciem tokenów/kluczy wbudowanych w działania aktora, co utrudnia prostą blokadę na podstawie „złośliwej domeny”.

6) Dystrybucja: legalne oprogramowanie i DLL sideloading

BleepingComputer (na bazie ustaleń Kaspersky) wskazuje, że w obserwowanych atakach malware bywał wdrażany przez legalne komponenty związane z Sangfor, a wcześniej operatorzy uruchamiali CoolClient przez DLL side-loading z wykorzystaniem podpisanych binariów (np. popularne aplikacje użytkowe).

Uwaga „na radar”: badacze sygnalizują także użycie nieopisanego wcześniej rootkita w powiązaniu z tym zestawem narzędzi, ale szczegóły mają zostać opublikowane w osobnym raporcie.

Praktyczne konsekwencje / ryzyko

  • Kompromitacja tożsamości: kradzież haseł/cookies/sesji z przeglądarek to ryzyko przejęcia dostępu do poczty, SSO, paneli administracyjnych i narzędzi chmurowych.
  • Trudniejsza detekcja na poziomie sieci: eksfiltracja przez popularne legalne usługi (np. Google Drive) może „zniknąć w szumie” i wyglądać jak typowy ruch biznesowy.
  • Wysokie ryzyko post-exploitation: pluginy (shell, zarządzanie usługami, operacje na plikach) i techniki eskalacji/UAC sprzyjają długiej obecności w sieci i lateral movement.

Rekomendacje operacyjne / co zrobić teraz

  1. Ochrona poświadczeń i sesji
  • Włącz/egzekwuj MFA odporne na phishing (FIDO2/WebAuthn) dla kont uprzywilejowanych i dostępu do krytycznych SaaS.
  • Rotuj hasła i unieważnij sesje tam, gdzie wykryto anomalie przeglądarkowe (cookies/tokens).
  1. Detekcja na endpointach (EDR)
  • Poluj na nietypowe uruchomienia i wstrzyknięcia z udziałem procesów typu write.exe oraz aktywności wokół zaszyfrowanych .dat i nietypowych usług/zadań harmonogramu.
  • Monitoruj wywołania związane ze schowkiem oraz pobieranie danych logowania z profili przeglądarek (szczególnie w kontekście narzędzi typu curl).
  1. Kontrola ruchu do usług chmurowych
  • Nie blokuj „w ciemno” Google Drive, ale wdrażaj CASB / DLP / polityki uploadu dla stacji i kont uprzywilejowanych (kto, co i skąd wysyła pliki).
  • W proxy/secure web gateway ustaw alerty na masowe uploady i podejrzane nagłówki autoryzacji w nietypowych kontekstach (np. curl na stacjach użytkowników).
  1. Higiena oprogramowania i odporność na sideloading
  • Ogranicz uruchamianie nieautoryzowanych binariów (AppLocker/WDAC), zwłaszcza z katalogów użytkownika i ścieżek tymczasowych.
  • Waliduj łańcuch dostaw: jeśli w środowisku jest oprogramowanie wykorzystywane do „legitymizacji” uruchomienia, przejrzyj modele dystrybucji i podpisy/hashe.

Różnice / porównania z innymi przypadkami

W wielu kampaniach APT backdoor służy głównie do zdalnego sterowania i pobierania kolejnych modułów. Tu widać przesunięcie akcentu: CoolClient staje się platformą do kradzieży tożsamości (infostealery, schowek, proxy sniffing) oraz do eksfiltracji „pod przykrywką” legalnych usług.
Na tle wcześniejszych opisów Earth Preta/Mustang Panda (phishing, archiwa-przynęty, szeroki arsenał) to spójna ewolucja: mniej hałaśliwe domeny C2 w warstwie eksfiltracji, większy nacisk na dostęp przez konta i sesje.

Podsumowanie / kluczowe wnioski

CoolClient w najnowszych kampaniach Mustang Panda/HoneyMyte to już nie tylko „backdoor”, ale modułowa platforma post-exploitation z funkcjami typowymi dla wyspecjalizowanych złodziei danych (schowek, przeglądarki, proxy) i z mechanizmami utrzymania dostępu (usługi, taski, obejście UAC). Priorytet obrony powinien przesunąć się na ochronę tożsamości (MFA/FIDO2), telemetry EDR wokół przeglądarek i narzędzi transferu, oraz kontrolę uploadów do legalnych chmur.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii i podsumowanie zmian w CoolClient (27 stycznia 2026). (BleepingComputer)
  2. Kaspersky Securelist (GReAT) – analiza techniczna CoolClient i stealerów (27 stycznia 2026). (Securelist)
  3. Trend Micro – tło dot. Earth Preta/Mustang Panda i taktyk kampanii (2023). (www.trendmicro.com)
  4. IBM X-Force – kontekst dot. Hive0154/Mustang Panda, arsenału i technik dystrybucji (2025). (IBM)

2024 VMware vCenter: krytyczna luka CVE-2024-37079 znów na celowniku – trwa eksploatacja “in the wild”

Wprowadzenie do problemu / definicja luki

vCenter Server to centralny komponent zarządzania środowiskiem VMware vSphere, często stojący “w sercu” wirtualizacji w firmach. Jeśli atakujący przejmie vCenter, zwykle zyskuje ścieżkę do kontroli nad hostami ESXi, maszynami wirtualnymi, siecią wirtualną i mechanizmami automatyzacji.

Właśnie dlatego krytyczna podatność CVE-2024-37079 (ocena CVSS 9.8) wraca jak bumerang: według ostrzeżeń publicznych oraz aktualizacji doradztwa producenta istnieją przesłanki, że jest aktywnie wykorzystywana w atakach.

W skrócie

  • Co: CVE-2024-37079 – błąd typu out-of-bounds write / heap overflow w implementacji DCERPC w VMware vCenter Server, umożliwiający zdalne wykonanie kodu (RCE).
  • Jak: atak przez specjalnie spreparowane pakiety sieciowe, jeśli napastnik ma dostęp sieciowy do vCenter.
  • Kiedy załatano: poprawki opublikowano w czerwcu 2024; Broadcom zaktualizował advisory w styczniu 2026, dodając informację o eksploatacji “in the wild”.
  • Workaround: brak sensownych obejść – trzeba aktualizować.

Kontekst / historia / powiązania

Podatność CVE-2024-37079 została ujawniona w czerwcu 2024 wraz z innymi błędami w vCenter/Cloud Foundation. CERT-EU opisywał wówczas pakiet poprawek obejmujący dwie krytyczne luki RCE (CVE-2024-37079 i CVE-2024-37080) oraz oddzielną podatność do eskalacji uprawnień (CVE-2024-37081).

W styczniu 2026 sytuacja stała się pilniejsza:

  • Broadcom dopisał do advisory uwagę, że ma informacje sugerujące wykorzystanie CVE-2024-37079 w realnych atakach.
  • Media branżowe poinformowały, że luka znalazła się w centrum zainteresowania atakujących, a administracje (w tym federalne w USA) dostały twarde terminy na działanie.

Analiza techniczna / szczegóły luki

CVE-2024-37079 dotyczy implementacji DCE/RPC (DCERPC) w vCenter Server. W praktyce błąd wiąże się z niewłaściwą weryfikacją granic podczas przetwarzania danych z pakietów sieciowych, co prowadzi do przepełnienia sterty (heap overflow) i potencjalnie do zdalnego wykonania kodu.

Kluczowe cechy, które czynią podatność “atrakcyjną” operacyjnie:

  • zdalny wektor ataku (pakiety sieciowe),
  • brak konieczności interakcji użytkownika,
  • wysoki wpływ (C/I/A = High) przy krytycznej ocenie CVSS.

Brak obejść w produkcie oznacza, że w wielu środowiskach jedyną sensowną kontrolą ryzyka jest szybka aktualizacja (oraz twarde ograniczenie ekspozycji sieciowej vCenter).

Praktyczne konsekwencje / ryzyko

Jeśli CVE-2024-37079 zostanie skutecznie wykorzystana, organizacja musi liczyć się z typowymi skutkami przejęcia warstwy zarządzania wirtualizacją:

  • przejęcie kontroli nad środowiskiem vSphere (zmiany konfiguracji, uruchamianie złośliwych zadań, dostęp do konsol VM),
  • eskalacja ataku na hosty i maszyny wirtualne (ruch boczny, kradzież poświadczeń, wyłączanie zabezpieczeń),
  • ryzyko sabotażu/zaszyfrowania (vCenter bywa elementem “szybkiej ścieżki” do masowego wyłączania usług).

Warto też pamiętać o realiach ofensywnych: infrastruktura wirtualizacyjna jest historycznie lubiana zarówno przez grupy APT, jak i cyberprzestępców, bo daje wysoki zwrot z inwestycji (jeden punkt → wiele systemów).

Rekomendacje operacyjne / co zrobić teraz

  1. Zidentyfikuj ekspozycję i wersje
    • Sprawdź, czy masz vCenter Server 7.0/8.0 oraz wdrożenia w ramach VMware Cloud Foundation – to kluczowe linie produktowe wskazywane jako dotknięte.
  2. Wdróż poprawki (priorytet P0)
    • Broadcom w macierzy odpowiedzi wskazuje wersje naprawione m.in.: vCenter 8.0 U2d, 8.0 U1e, 7.0 U3r (zależnie od gałęzi i zakresu CVE).
    • Ponieważ workaroundów brak, aktualizacja to jedyna realna ścieżka redukcji ryzyka.
  3. Odetnij vCenter od internetu i “szerokich” sieci
    • vCenter nie powinno być publicznie wystawione; ogranicz dostęp do segmentów administracyjnych, jump hostów i VPN, stosuj listy ACL i mikrosegmentację. (To zalecenie jest zgodne z praktyką branżową, a wprost podkreślane w komentarzach wokół tej kampanii).
  4. Polowanie na oznaki nadużyć
    • Skoro szczegóły kampanii nie są publiczne, podejdź “symptomatycznie”: nietypowe procesy/usługi na VCSA, nowe konta/klucze, zmiany ról, anomalie w logach vCenter, skoki ruchu do usług RPC, podejrzane zadania automatyzacji.
    • Zabezpiecz dowody (snapshoty, eksport logów), zanim wykonasz działania naprawcze w razie incydentu.
  5. Zarządzanie ryzykiem terminowym
    • W kontekście KEV/terminów egzekucyjnych (dla części podmiotów) w obiegu pojawia się data 13 lutego 2026 jako deadline na załatanie w administracji federalnej USA – potraktuj to jako czytelny sygnał pilności także dla biznesu.

Różnice / porównania z innymi przypadkami

  • CVE-2024-37079 vs CVE-2024-37080: oba błędy są krytyczne, oba dotyczą DCERPC i klasy heap overflow, z podobnym potencjałem RCE przy dostępie sieciowym.
  • CVE-2024-37081: to inna klasa problemu – lokalna eskalacja uprawnień wynikająca z błędnej konfiguracji sudo. Jest ważna, ale zwykle wymaga już jakiejś formy dostępu lokalnego do appliance.
  • Wątek “DCERPC w vCenter” jako powracający motyw: komentatorzy zwracają uwagę na wcześniejsze podatności w tej okolicy funkcjonalnej, co ułatwia atakującym priorytetyzację celu i budowę TTP wokół infrastruktury wirtualizacyjnej.

Podsumowanie / kluczowe wnioski

CVE-2024-37079 to klasyczny przykład “starej” krytycznej luki, która wraca ze zdwojoną siłą, gdy pojawiają się sygnały realnej eksploatacji. Jeśli zarządzasz VMware vCenter:

  • traktuj temat jako incydent waiting-to-happen,
  • aktualizuj natychmiast (brak workaroundów),
  • upewnij się, że vCenter jest ściśle odseparowane sieciowo,
  • uruchom hunt na oznaki kompromitacji w środowiskach, które mogły być narażone.

Źródła / bibliografia

  1. SecurityWeek – “2024 VMware Flaw Now in Attackers’ Crosshairs” (SecurityWeek)
  2. Broadcom (VMware) – VMSA-2024-0012 / aktualizacja o eksploatacji CVE-2024-37079 (Support Portal)
  3. NVD (NIST) – opis i metryki CVE-2024-37079 (nvd.nist.gov)
  4. CERT-EU – advisory 2024-060 dot. vCenter/Cloud Foundation (cert.europa.eu)
  5. The Register – kontekst KEV i presja terminowa (m.in. 13 lutego 2026) (theregister.com)

DynoWiper: nowy wiper użyty w nieudanej próbie sabotażu polskiego sektora energii (Sandworm)

Wprowadzenie do problemu / definicja luki

Pod koniec grudnia 2025 r. odnotowano skoordynowaną próbę ataku na polski sektor energetyczny, w której wykorzystano destrukcyjne złośliwe oprogramowanie typu wiper (malware do trwałego niszczenia danych). Według ustaleń ESET oraz relacji medialnych, atak był nieudany – nie ma dowodów na skuteczne zakłócenie działania infrastruktury.

W tym przypadku kluczowe jest to, że mówimy o klasie incydentów nastawionych nie na kradzież danych czy okup (ransomware), ale na szybkie unieruchomienie systemów poprzez kasowanie/niszczenie plików oraz potencjalne utrudnienie odtworzenia środowiska.

W skrócie

  • Atak miał miejsce 29–30 grudnia 2025 r. i obejmował m.in. dwie elektrociepłownie (CHP) oraz system wspierający zarządzanie energią z OZE (np. wiatr i fotowoltaika).
  • ESET przeanalizował próbkę nowego wipera, nadając mu nazwę DynoWiper (detekcja: Win32/KillFiles.NMO).
  • Atrybucja do grupy Sandworm (powiązanej z rosyjskim GRU) ma według ESET „średni” poziom pewności i opiera się na nakładaniu się TTP oraz podobieństwach do wcześniejszych aktywności destrukcyjnych.
  • Kontekst historyczny jest istotny: Sandworm ma udokumentowaną historię operacji destrukcyjnych, w tym kampanii przeciw energetyce.

Kontekst / historia / powiązania

Sandworm to jeden z najbardziej znanych „destrukcyjnych” aktorów APT, wiązany z jednostką GRU 74455 i aktywny co najmniej od 2009 r. W narracji wokół incydentu pojawia się też wymiar symboliczny: ESET zwraca uwagę, że działania zbiegły się z 10. rocznicą głośnego ataku na ukraińską energetykę (2015), który był szeroko opisywany jako przełomowy przykład cyberataku na infrastrukturę krytyczną.

Z perspektywy strategii zagrożeń ważny jest sam wybór celów: połączenie aktywów wytwórczych (CHP) oraz elementów „krwiobiegu” nowoczesnej energetyki – systemów komunikacji i zarządzania generacją rozproszoną (OZE).

Analiza techniczna / szczegóły luki

1) Co wiemy na pewno o DynoWiper

Publicznie udostępnione informacje są na razie dość oszczędne: ESET potwierdza analizę nowego wipera DynoWiper i wskazuje jego charakter destrukcyjny (data-wiping), a także nazwę detekcji Win32/KillFiles.NMO. Reuters i inne media streszczają, że malware miało niszczyć pliki i unieruchamiać systemy.

2) Jak typowo działają wipery w środowiskach IT/OT (użyteczne do obrony)

Ponieważ szczegóły implementacyjne DynoWiper nie zostały szeroko opisane w materiałach publicznych (na dzień publikacji źródeł), warto przełożyć „wiper” na obserwowalne artefakty obronne. W praktyce wipery często realizują część lub całość poniższych działań:

  • masowe usuwanie plików (czasem z użyciem list rozszerzeń/ścieżek) lub ich nadpisywanie,
  • kasowanie kopii zapasowych/Shadow Copies i punktów przywracania,
  • destabilizacja systemu (np. niszczenie konfiguracji, usług, krytycznych katalogów),
  • równoległe użycie narzędzi „living-off-the-land” (np. do dystrybucji w domenie) – szczególnie w kampaniach przypisywanych Sandworm, gdzie destrukcja bywa etapem końcowym po wcześniejszym dostępie i przygotowaniu środowiska. (To jest uogólnienie na bazie znanego profilu grupy w ATT&CK.)

3) Atrybucja: dlaczego Sandworm

ESET komunikuje atrybucję do Sandworm z „medium confidence”, wskazując na silne nakładanie się z wcześniejszymi aktywnościami wiperowymi tej grupy. Z kolei MITRE ATT&CK opisuje Sandworm jako grupę o profilu destrukcyjnym, z historią operacji obejmujących m.in. NotPetya i wcześniejsze kampanie przeciw sektorom państwowym i krytycznym.

Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyko w tym typie incydentu to krótki czas do efektu i wysoki koszt odtwarzania. Nawet jeśli atak nie powoduje natychmiastowego blackoutu, wiper:

  • może zatrzymać procesy biznesowe (OT/IT) przez konieczność odbudowy stacji, serwerów i domeny,
  • utrudniać sterowanie i bilansowanie (szczególnie, gdy celem są elementy komunikacji OZE z operatorami),
  • generować koszty operacyjne i reputacyjne – nawet przy braku fizycznych skutków.

W tym przypadku polskie władze i badacze mówią, że nie doszło do skutecznych zakłóceń, ale sam dobór celów (CHP + zarządzanie OZE) pokazuje, gdzie atakujący mógłby próbować uzyskać efekt „systemowy”.

Rekomendacje operacyjne / co zrobić teraz

Poniższe działania są praktyczne niezależnie od tego, czy DynoWiper pojawi się ponownie (i nawet przy ograniczonej widoczności jego IoC):

  1. Segmentacja IT/OT i kontrola przepływów
  • „Hard separation” krytycznych stref OT (SCADA/EMS/DMS, serwery inżynierskie) od IT; dopuszczaj tylko jawnie dozwolone protokoły i kierunki.
  • Bastionowanie dostępu z MFA i rejestrowaniem sesji.
  1. Wzmocnienie Active Directory i mechanizmów dystrybucji
  • Monitoruj nietypowe użycie GPO, PSExec/WMI/WinRM oraz narzędzi zdalnej administracji.
  • Ogranicz uprawnienia kont serwisowych; wprowadź JIT/JEA dla adminów.
  1. Backupy odporne na wipery
  • Kopie offline/immutable, testowane odtwarzanie (bare metal + AD recovery).
  • Osobne poświadczenia i oddzielona sieć do backupu.
  1. Detekcja behawioralna pod destrukcję
  • Alerty na: gwałtowny wzrost operacji delete/rename, masowe modyfikacje w krótkim oknie czasu, niszczenie kopii zapasowych.
  • Korelacja zdarzeń na hostach pełniących role „przesiadkowe” między IT i OT.
  1. Ćwiczenia IR ukierunkowane na „wiper scenario”
  • Procedury: izolacja segmentów, odcięcie dystrybucji narzędzi, priorytety przywracania (najpierw tożsamość, potem łączność, potem aplikacje).

Różnice / porównania z innymi przypadkami

  • DynoWiper vs klasyczne ransomware: tu celem nie jest monetyzacja, tylko degradacja zdolności operacyjnej. To zmienia priorytety: kluczowe są backupy i odtwarzanie, a nie negocjacje/odszyfrowywanie.
  • DynoWiper vs wcześniejsze operacje Sandworm: publicznie potwierdzony jest przede wszystkim „destrukcyjny DNA” Sandworm i jego historia kampanii o wysokim wpływie (MITRE opisuje m.in. NotPetya i ataki na energetykę). W przypadku DynoWiper na ten moment wiemy mniej o technikaliach, ale atrybucja ESET opiera się na zbieżnościach TTP z wcześniejszymi wiperami.

Podsumowanie / kluczowe wnioski

DynoWiper jest kolejnym sygnałem, że destrukcyjne operacje cybernetyczne nie są „historią z 2015 roku”, tylko realnym scenariuszem dla współczesnej energetyki – zwłaszcza w kontekście systemów hybrydowych łączących konwencjonalne źródła z OZE.

Najważniejsze na dziś:

  • traktuj wiper jako scenariusz „fast impact” (minuty–godziny),
  • inwestuj w odporność odtwarzania i segmentację,
  • buduj detekcję behawioralną pod masowe niszczenie danych,
  • ćwicz IR pod operacje destrukcyjne, nie tylko pod wycieki.

Źródła / bibliografia

  1. ESET Research – Sandworm behind cyberattack on Poland’s power grid in late 2025 (welivesecurity.com)
  2. The Hacker News – New DynoWiper Malware Used in Attempted Sandworm Attack on Polish Power Sector (The Hacker News)
  3. Reuters – raport o atrybucji i kontekście ataku (Reuters)
  4. TechCrunch – opis celu i kontekstu ataku (CHP + łączność OZE) (TechCrunch)
  5. MITRE ATT&CK – profil grupy Sandworm (G0034) (attack.mitre.org)