Archiwa: Firewall - Strona 7 z 22

eScan: złośliwa aktualizacja z oficjalnego serwera. Co wiemy o ataku supply chain i jak reagować

Wprowadzenie do problemu / definicja luki

Ataki typu supply chain (łańcuch dostaw) są jednymi z najtrudniejszych do wykrycia, bo wykorzystują zaufany kanał dystrybucji — np. aktualizacje producenta. W opisywanym incydencie użytkownicy eScan otrzymali złośliwy komponent poprzez legalną infrastrukturę aktualizacji, po tym jak napastnicy uzyskali nieautoryzowany dostęp do regionalnej konfiguracji serwera aktualizacji.

W skrócie

Dystrybucja złośliwego pliku miała miejsce 20 stycznia 2026 i trwała ok. 2 godziny w ramach jednego regionalnego klastra aktualizacji.
Wektorem był podmieniony komponent Reload.exe, uruchamiający wieloetapowy łańcuch infekcji.
Malware modyfikował m.in. plik HOSTS i ustawienia/konfigurację produktu tak, by odciąć ofiarę od aktualizacji (czyli utrudnić samo-naprawę przez update).
Wymagana była ręczna remediacja (manualny patch/narzędzie od producenta), bo automatyczne aktualizacje na zainfekowanych hostach mogły nie zadziałać.

Kontekst / historia / powiązania

Incydent został nagłośniony publicznie 29 stycznia 2026 przez Morphisec, a następnie szerzej opisany przez media branżowe. Producent, MicroWorld Technologies, wydał advisory (ESCAN-2026-001), klasyfikując zdarzenie jako incident infrastrukturalny (nie wada produktu), ograniczony do części klientów korzystających z konkretnego klastra regionalnego.

Warto też odnotować, że temat nadużycia mechanizmu aktualizacji eScan przewijał się już wcześniej: w 2024 r. obserwowano kampanie, w których mechanizm aktualizacji miał zostać wykorzystany do implantowania backdoorów w środowiskach firmowych.

Analiza techniczna / szczegóły luki

1) Wejście: trojanizowana aktualizacja i podmiana komponentu

Wg analiz, atak startował od dostarczenia złośliwej wersji Reload.exe (komponent 32-bit), umieszczonej w ścieżce instalacyjnej produktu (m.in. C:\Program Files (x86)\escan\reload.exe).
Producent potwierdził, że do „ścieżki dystrybucji aktualizacji” trafił nieautoryzowany plik w wyniku dostępu do konfiguracji regionalnego serwera.

2) Co robił malware: odcięcie od aktualizacji + utrzymanie dostępu

Kluczowym elementem była sabotacja aktualizacji: modyfikacje HOSTS i elementów konfiguracji/rejestru miały blokować kontakt z serwerami update i utrudniać automatyczne „samoleczenie” po stronie AV.
Dodatkowo obserwowano mechanizmy persistence (np. zadania Harmonogramu zadań) oraz pobieranie kolejnych etapów/payloadów z infrastruktury C2.

3) Etapy łańcucha infekcji (w uproszczeniu)

Stage 1: podmieniony Reload.exe uruchamia kolejne elementy łańcucha.
Stage 2/3: downloader/backdoor (w raportach pojawia się m.in. CONSCTLX.exe) — utrzymanie dostępu, komunikacja z C2, możliwość dogrywania kolejnych ładunków.
W analizie technicznej wskazano też uruchamianie payloadów PowerShell (z elementami obejścia AMSI) oraz zmiany w rejestrze i wyjątkach AV.

4) Przykładowe IOCs / artefakty

C2 / adresy do blokowania (wskazywane w materiałach producenta i analizach):

vhs.delrosal.net
tumama.hns.to
504e1a42.host.njalla.net
185.241.208.115

Artefakty na hoście:

zmieniony plik HOSTS (mapowanie domen update na „fałszywy” adres/IP),
nietypowe zadania Harmonogramu zadań (np. nazwy typu „CorelDefrag”),
obecność/uruchomienia Reload.exe w podejrzanym oknie czasowym oraz plików downloader/backdoor.

Uwaga praktyczna: część wskaźników (np. hashe) jest wprost podana w biuletynie Morphisec — warto zasilić nimi EDR/SIEM do polowania (threat hunting).

Praktyczne konsekwencje / ryzyko

Utrata zaufania do kanału aktualizacji – użytkownik otrzymuje malware „podpisany autorytetem” aktualizacji. Nawet jeśli podpis był raportowany jako nieprawidłowy w narzędziach, w praktyce wiele środowisk i tak ufa kanałowi update.
Ryzyko backdoora i dogrywania kolejnych payloadów – jeśli końcowy etap działa jako backdoor/persistent downloader, zagrożenie nie kończy się na jednorazowej infekcji.
Blokada aktualizacji = dłuższe okno kompromitacji – modyfikacje HOSTS/konfiguracji mogą uniemożliwić szybkie wypchnięcie poprawki przez producenta i wymuszają działania ręczne.
Koszty operacyjne dla IT/SOC – identyfikacja hostów z „feralnego” klastra i okna czasowego + ręczna remediacja na endpointach (zwłaszcza w enterprise) potrafi być czasochłonna.

Rekomendacje operacyjne / co zrobić teraz

Poniżej podejście „incident response ready” dla organizacji, które mogły korzystać z eScan w tym czasie.

1) Szybka triage: czy jesteś w grupie ryzyka?

Sprawdź, czy 20.01.2026 wystąpiły błędy aktualizacji i/lub komunikaty „update unavailable”.
Zweryfikuj, czy hosty korzystały z regionalnego klastra aktualizacji (jeśli masz takie logi / telemetry). Producent wskazuje, że dotyczyło to ograniczonej grupy klientów i jednego klastra.

2) Detekcja na endpointach (EDR/SIEM)

Poluj na artefakty: modyfikacje HOSTS, podejrzane zadania Harmonogramu, uruchomienia Reload.exe i obecność powiązanych plików (np. CONSCTLX).
Zasil EDR IOC (hashe i domeny) z biuletynu Morphisec oraz danych producenta.

3) Kontrola ruchu sieciowego

Zablokuj domeny/adresy C2 na firewall/DNS (producent podaje listę blokad jako dodatkową ostrożność).

4) Remediacja

Jeśli obserwujesz symptomy (błędy aktualizacji, zmiany HOSTS/konfig), producent rekomenduje kontakt z supportem i użycie narzędzia/patcha remediacyjnego (manualnie).
Po remediacji zweryfikuj: przywrócony update, brak błędów, aktualne definicje, brak podejrzanych zadań i brak połączeń do wskazanej infrastruktury.

5) Wnioski długoterminowe (hardening procesu aktualizacji)

Segmentuj ruch aktualizacji i monitoruj odstępstwa (nietypowe domeny, nieoczekiwane wykonywalne w ścieżkach AV).
Rozważ politykę allow-list dla aktualizacji (tam gdzie to realne) oraz dodatkową walidację podpisów/artefaktów w pipeline wdrożeń.
Ustal playbook „compromised update channel”: odcięcie, triage, hunting, ręczne paczkowanie fixów, komunikacja.

Różnice / porównania z innymi przypadkami

W wielu incydentach supply chain celem jest „cichy” dostęp (backdoor) — tutaj dodatkowym, bardzo praktycznym elementem była sabotacja aktualizacji, która utrudnia automatyczne wypchnięcie naprawy i wydłuża czas ekspozycji.
Producent mocno akcentuje, że nie była to „luka w produkcie”, tylko kompromitacja infrastruktury aktualizacji. Z perspektywy obrony (SOC/IR) efekt jest jednak podobny: zaufany kanał dostarczył nieautoryzowaną treść na endpointy.

Podsumowanie / kluczowe wnioski

To klasyczny (i szczególnie groźny) scenariusz supply chain: update jako nośnik infekcji.
Incydent był ograniczony czasowo (ok. 2h) i infrastrukturalnie (regionalny klaster), ale skutki obejmowały backdoor/pobieranie payloadów oraz blokadę aktualizacji, co wymuszało działania manualne.
Najważniejsze operacyjnie: szybko wyłapać hosty z okna czasowego, wdrożyć IOC hunting, zablokować C2 oraz wykonać remediację narzędziem producenta tam, gdzie wystąpiły symptomy.

Źródła / bibliografia

SecurityWeek – opis incydentu i stanowisk stron. (SecurityWeek)
Morphisec – biuletyn techniczny + IOC i zalecenia. (Morphisec)
Kaspersky / Securelist – analiza techniczna łańcucha infekcji. (Securelist)
eScan Security Advisory (ESCAN-2026-001) – oficjalne informacje producenta, zakres, ryzyko, remediacja i blokady sieciowe.
BleepingComputer – potwierdzenie incydentu, szczegóły dot. okna dystrybucji i obserwowane C2. (BleepingComputer)

Ransomware w mieście New Britain: co wiemy o ataku na systemy urzędu i jak minimalizować ryzyko w samorządach

Wprowadzenie do problemu / definicja luki

W drugiej połowie stycznia 2026 r. samorząd New Britain poinformował o poważnym incydencie cyberbezpieczeństwa, który zakłócił działanie miejskich systemów IT i łączności. Z perspektywy bezpieczeństwa to klasyczny scenariusz „zakłócenia ciągłości działania” wywołanego ransomware: złośliwym oprogramowaniem, które szyfruje zasoby i wymusza okup, często łącząc to z groźbą publikacji danych (tzw. data extortion).

W tym przypadku władze podkreślają, że służby bezpieczeństwa publicznego funkcjonowały, ale część usług urzędu była ograniczona (m.in. telefonia i systemy komputerowe).

W skrócie

Atak ransomware uderzył w systemy miejskie od wczesnej środy (28 stycznia 2026), powodując przestoje w telefonii i systemach komputerowych wielu wydziałów.
Burmistrz Bobby Sanchez informował o pracach naprawczych prowadzonych także w weekend, przy wsparciu organów stanowych i federalnych oraz zewnętrznych specjalistów.
Władze zaznaczają, że zakres szkód i ewentualny wyciek danych wciąż jest ustalany (brak wiążących publicznych informacji o skali eksfiltracji).
W sprawę zaangażowano Federal Bureau of Investigation.

Kontekst / historia / powiązania

Incydenty ransomware w administracji publicznej są trudne z dwóch powodów:

wysoka wrażliwość danych (mieszkańcy, podatki, świadczenia, sprawy urzędowe),
zależność od usług cyfrowych (telefonia, obieg dokumentów, systemy zgłoszeń).

W New Britain komunikacja władz wskazuje na równoległe prowadzenie dwóch strumieni prac: przywracanie usług oraz dochodzenie (ustalenie wektora wejścia, zakresu kompromitacji, ewentualnej kradzieży danych). To standard w dojrzałym IR – odtworzenie „na siłę” bez zrozumienia źródła incydentu często kończy się reinfekcją.

Analiza techniczna / szczegóły luki

Na dziś publicznie dostępne informacje (z komunikacji miasta i relacji medialnych) potwierdzają ransomware oraz zakłócenia usług – bez ujawnienia nazwy grupy, wykorzystanej podatności czy poziomu dostępu napastników.

W takich zdarzeniach w samorządach najczęściej spotyka się kilka wzorców (poniższe punkty to typowe scenariusze, a nie potwierdzone dla New Britain):

Kradzież poświadczeń (phishing, password spraying, wycieki haseł) i wejście przez VPN/RDP lub usługi zdalne.
Eksploatacja podatnych urządzeń brzegowych (firewall/VPN, serwery dostępu, systemy pocztowe).
Ruch boczny i eskalacja uprawnień (np. przejęcie kontrolera domeny), a następnie masowe szyfrowanie.
Coraz częściej: podwójne wymuszenie – szyfrowanie + eksfiltracja, co podnosi presję negocjacyjną. (To powszechny trend opisywany w materiałach rządowych dot. ransomware).

W praktyce, dopóki nie ma publicznego raportu powłamaniowego (albo chociaż IoC/TTP), kluczowe jest podejście „assume breach” podczas przywracania środowiska: odtwarzać usługi warstwowo, z segmentacją i dodatkowymi kontrolami.

Praktyczne konsekwencje / ryzyko

Nawet jeśli „dla mieszkańców” zakłócenia są minimalne, ryzyko operacyjne może być istotne:

Przestoje usług: ograniczona łączność i systemy obsługi spraw wydłużają czas realizacji procesów.
Ryzyko wycieku danych: przy ransomware nie można zakładać, że skończyło się na szyfrowaniu – brak potwierdzenia eksfiltracji to nie to samo co jej brak.
Koszty odtworzeniowe: forensics, wymiana/rekonfiguracja infrastruktury, nadgodziny, komunikacja kryzysowa.
Ryzyko wtórne: oszustwa i phishing „na incydent” (podszywanie się pod urząd, zmianę numerów kont, dopłaty, itp.) – klasyczny efekt uboczny głośnych incydentów w sektorze publicznym.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które wprost wynikają z oficjalnych checklist i zaleceń rządowych dla ransomware – przydatne zarówno w trakcie incydentu, jak i po nim.

1) Natychmiastowe kroki IR (0–72h)

Izolacja zainfekowanych segmentów / hostów, wstrzymanie „niepewnych” kanałów zdalnych, kontrola kont uprzywilejowanych.
Zabezpieczenie dowodów (obrazy dysków, logi, EDR) zanim środowisko zostanie „wyczyszczone”.
Praca według checklisty reakcji na ransomware (#StopRansomware) – to pomaga nie pominąć krytycznych etapów (triage → containment → eradication → recovery → lessons learned).

2) Zgłoszenia i współpraca z organami

Zgłaszanie incydentów do organów właściwych: kontakt z lokalnym biurem FBI Internet Crime Complaint Center i egzekwowaniem prawa jest rekomendowany wprost przez FBI.
W modelu USA często dochodzi też współpraca z Cybersecurity and Infrastructure Security Agency oraz partnerami stanowymi; miasto wskazało wsparcie służb stanowych i federalnych.

3) Odtwarzanie usług „bezpiecznie, nie tylko szybko”

Odtwarzaj z kopii offline/immutable, uprzednio skanowanych pod kątem malware (żeby nie odtworzyć infekcji).
Wymuś reset poświadczeń (priorytet: konta uprzywilejowane), włącz MFA wszędzie, gdzie to możliwe.
Przywracaj krytyczne usługi w odseparowanych strefach (segmentacja), z tymczasowo zaostrzonym monitoringiem.

4) Utwardzenie po incydencie (2–8 tygodni)

Segmentacja sieci (oddzielenie stacji roboczych, serwerów, OT/SCADA, kopii zapasowych).
Minimalizacja uprawnień i twarde zasady dla adminów (PAW, oddzielne konta, JIT/JEA).
Zbieranie i korelacja logów (SIEM), telemetria EDR, retencja logów do celów forensics.
Ćwiczenia tabletop + testy odtwarzania (DR) – w samorządach to często najsłabsze ogniwo, a najszybszy „boost” odporności.

Ważne: FBI konsekwentnie podkreśla, że płacenie okupu nie daje gwarancji odzyskania danych i wzmacnia model przestępczy. W praktyce decyzje są złożone, ale warto opierać je o ryzyko, prawo, ubezpieczenie i twarde dane z forensics – nie o presję czasu.

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

W komunikacji New Britain widać element, który odróżnia część dojrzałych reakcji od „chaotycznego recovery”: nacisk na równoległe dochodzenie i ostrożność w formułowaniu wniosków co do zakresu incydentu.

Typowa różnica między incydentami o małej i dużej skali to:

czy doszło tylko do szyfrowania ograniczonego segmentu,
czy napastnicy osiągnęli domenę/backup i wykonali eksfiltrację,
jak szybko organizacja potrafi odtworzyć usługi z kopii odpornych na modyfikację.

Na dziś – bez publicznych IoC i bez informacji o grupie – nie da się wiarygodnie sklasyfikować zdarzenia w New Britain do konkretnego „klastra” kampanii.

Podsumowanie / kluczowe wnioski

Incydent w New Britain to potwierdzony przypadek ransomware z zauważalnym wpływem na systemy urzędu, przy deklarowanym utrzymaniu działania usług bezpieczeństwa publicznego.
Kluczowa niewiadoma to zakres kompromitacji i ewentualna kradzież danych – miasto sygnalizuje, że ustalenia trwają.
Dla samorządów najważniejsze „lekcje” są powtarzalne: odporne kopie (offline/immutable), segmentacja, MFA, monitoring oraz ćwiczenia IR/DR zgodnie z checklistami CISA/FBI.

Źródła / bibliografia

CT Insider – informacje o incydencie i działaniach miasta. (CT Insider)
WFSB – potwierdzenie charakteru ataku i kontekstu operacyjnego. (https://www.wfsb.com)
Cybersecurity and Infrastructure Security Agency – #StopRansomware Guide / checklisty reakcji. (cisa.gov)
Federal Bureau of Investigation – strona informacyjna o ransomware i raportowaniu. (Federal Bureau of Investigation)
FBI Internet Crime Complaint Center – zalecenia dot. reakcji (w tym stanowisko ws. płacenia okupu). (Internet Crime Complaint Center)

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:

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.
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

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.
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.
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

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

Łotwa: Rosja nadal największym zagrożeniem cybernetycznym — rekord ataków i rosnące ryzyko dla OT/ICS

Wprowadzenie do problemu / definicja luki

Łotewskie służby i zespoły reagowania na incydenty sygnalizują, że presja ze strony Rosji w cyberprzestrzeni nie słabnie, a 2025 r. przyniósł rekordowy poziom zarejestrowanych zagrożeń. Problem nie dotyczy „jednej luki CVE”, lecz systematycznej kampanii łączącej cyberataki (DDoS, włamania, malware), działania o charakterze sabotażowym oraz presję psychologiczną i polityczną — szczególnie w okresach „wrażliwych” decyzji publicznych.

Istotnym elementem ostrzeżeń jest rosnąca ekspozycja systemów OT/ICS (Operational Technology / Industrial Control Systems) w sektorach energii, wody i transportu — środowisk, w których zaległości w segmentacji, monitoringu i zarządzaniu poprawkami bywają normą, a skutki incydentu mogą wyjść poza IT i uderzyć w usługi krytyczne.

W skrócie

Rosja pozostaje głównym źródłem ryzyka dla Łotwy; aktywność ma związek z geopolityką i wsparciem dla Ukrainy.
Większość incydentów to cyberprzestępczość i oszustwa, ale występują też poważniejsze zdarzenia: włamania, dystrybucja malware, kompromitacje urządzeń i DDoS.
CERT.LV utrzymuje, że od 2022 r. Łotwa obserwuje stały wysoki poziom incydentów (ok. 500–700 kwartalnie); w Q3 2025 odnotowano 671 incydentów.
Widać wzrost znaczenia botnetów/IoT i automatycznej eksploatacji podatności, co przekłada się na rosnącą liczbę „skompromitowanych urządzeń”.
W tle europejskim utrzymuje się trend, w którym hacktywiści i DDoS stanowią dużą część wolumenu ataków na administrację publiczną (m.in. NoName057(16)).

Kontekst / historia / powiązania

Z perspektywy Łotwy kluczowym punktem odniesienia jest okres po pełnoskalowej inwazji Rosji na Ukrainę (2022), po którym — według CERT.LV — „niska intensywność” przestała być normą, a ryzyko utrzymuje się stale na wysokim poziomie.

SAB (łotewski Constitution Protection Bureau) wskazuje, że Rosja postrzega konfrontację z Zachodem szeroko (globalnie i ideologicznie) i utrzymuje wachlarz narzędzi wpływu, w tym gotowość do działań w cyberprzestrzeni oraz działań sabotażowych. W tym ujęciu cyberataki mają funkcję nie tylko „techniczną”, ale także strategiczno-psychologiczną: testowanie odporności, zastraszanie, karanie za decyzje polityczne.

Analiza techniczna / szczegóły luki

1) Dominujące techniki: od DDoS po kompromitacje i malware

SAB w podsumowaniach (na bazie 2025 r.) wymienia jako najpoważniejsze zdarzenia m.in. intrusion attempts, malware distribution, equipment compromise oraz DDoS.
CERT.LV w Q1 2025 pokazuje strukturę incydentów, gdzie ilościowo dominują oszustwa (fraud), ale w TOP5 pojawiają się też próby włamań, złośliwy kod, skompromitowane urządzenia oraz incydenty dostępności usług.

2) Botnety, IoT i automatyzacja eksploatacji

CERT.LV raportuje, że rośnie liczba skompromitowanych urządzeń i wskazuje na wejście w „nową fazę” zagrożeń: botnety/IoT, malware oraz automatyczne skanowanie i eksploatację podatności. W Q3 2025 zarejestrowano 671 incydentów, a dynamika kompromitacji urządzeń była wyraźnie wzrostowa.

3) Eksploatacja podatności w popularnych produktach

W Q3 2025 CERT.LV odnotowuje aktywne wykorzystywanie krytycznych podatności m.in. w Microsoft SharePoint i WinRAR, a co szczególnie istotne — przynajmniej jeden przypadek kompromitacji wykryto w sektorze infrastruktury krytycznej.

4) OT/ICS jako najbardziej ryzykowny wektor

SAB oraz CERT.LV podkreślają ryzyko dla systemów OT/ICS w sektorach takich jak energia i woda. W praktyce takie środowiska bywają trudniejsze do aktualizacji, słabiej monitorowane, a zarządzanie tożsamością i segmentacją jest często historycznie „długiem technicznym”.

Praktyczne konsekwencje / ryzyko

Zdarzenia masowe bez spektakularnego skutku ≠ brak ryzyka. SAB zaznacza, że wiele incydentów nie powodowało poważnych zakłóceń, ale to nie unieważnia trendu wzrostowego i gotowości przeciwnika do eskalacji.
„Polityczne kalendarze” jako wyzwalacze ataków. Według SAB rosyjskie DDoS-y na instytucje rządowe i samorządy często zgrywają się z wrażliwymi datami/decyzjami; jako przykład podano silny atak po ogłoszeniu wyniku międzynarodowego kontraktu dronowego (lipiec).
Ryzyko ciągłości działania w administracji i usługach publicznych. ENISA dla sektora administracji publicznej w UE opisuje krajobraz, w którym DDoS stanowi znaczną część incydentów, a aktywność hacktywistów (napędzana m.in. wojną) utrzymuje się na wysokim poziomie — co dobrze „skaluje się” do doświadczeń Łotwy jako państwa frontowego w domenie hybrydowej.
Najgroźniejszy scenariusz: OT/ICS. Krótkotrwałe zakłócenia w OT (energia/woda/transport) mogą mieć efekt kaskadowy: przerwy w usługach, koszty operacyjne, presja polityczna i spadek zaufania społecznego. SAB wprost wskazuje gotowość rosyjskich aktorów do ataków na systemy przemysłowe, co zwiększa wagę prewencji.

Rekomendacje operacyjne / co zrobić teraz

Dla IT (administracja, samorządy, instytucje publiczne)

Higiena podatności i aktualizacji: twarde SLA na łatki dla systemów wystawionych do Internetu (szczególnie platformy współdzielenia treści/portale).
Odporność na DDoS: CDN/WAF, rate-limiting, geofencing tam, gdzie uzasadnione, scenariusze przełączeń i testy „na zimno”.
MFA i twarde zasady dostępu: warunkowy dostęp, ograniczenie kont uprzywilejowanych, rozdział ról, logowanie i alertowanie na anomalie.
Kopie zapasowe + test odtwarzania: szczególnie pod kątem ransomware i kompromitacji usług krytycznych w administracji.

Dla OT/ICS (energia, woda, ciepłownictwo, transport)

Segmentacja IT/OT i minimalizacja ekspozycji: separacja stref, brak „płaskich” sieci, kontrola zdalnego dostępu (jump host, MFA, rejestrowanie sesji).
Monitorowanie specyficzne dla OT: detekcja anomalii protokołów przemysłowych, widoczność zasobów i zależności.
Zarządzanie podatnościami w OT: tam, gdzie nie da się łatkować szybko — kompensacje (reguły firewall, allow-listing, izolacja usług).
Ćwiczenia IR „end-to-end”: scenariusze DDoS + próba wejścia + incydent w OT (wspólny playbook IT/OT).

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

Łotwa wyróżnia się ciągłym, wysokim tłem zagrożeń oraz naciskiem na komponent państwowo-geopolityczny (Rosja jako główne źródło ryzyka).
Jednocześnie wektor „wolumenowy” (DDoS/hacktywizm) wpisuje się w obserwacje ENISA dla administracji publicznej w UE: duży udział ataków zakłócających dostępność i kampanii napędzanych wydarzeniami geopolitycznymi, z rozpoznawalnymi grupami pokroju NoName057(16).

Podsumowanie / kluczowe wnioski

2025 r. to dla Łotwy rekord zarejestrowanych zagrożeń, a Rosja pozostaje głównym źródłem presji w cyberprzestrzeni.
Statystyki CERT.LV pokazują stabilnie wysoki poziom incydentów od 2022 r. i rosnącą wagę botnetów/IoT oraz automatycznej eksploatacji podatności.
Kluczowe ryzyko strategiczne przesuwa się w stronę OT/ICS, gdzie „krótkie zakłócenie” może stać się realnym problemem dla usług krytycznych.
Dla organizacji publicznych i operatorów infrastruktury krytycznej priorytetem powinny być: patching, odporność na DDoS, segmentacja IT/OT oraz dojrzały IR.

Źródła / bibliografia

The Record (Recorded Future News): materiał o ostrzeżeniach SAB i rekordzie zagrożeń w 2025 r. (The Record from Recorded Future)
SAB — Annual Report 2025 (ENG), unclassified part.
CERT.LV: Latvian Cyberspace Situation Q3 2025.
CERT.LV: The situation in Latvian cyberspace Q1 2025. (cert.lv)
ENISA: Sectorial Threat Landscape – Public Administration (2024 data). (ENISA)

eScan: przejęty serwer aktualizacji posłużył do dystrybucji złośliwego „update” (supply chain) – co wiemy i jak reagować

Wprowadzenie do problemu / definicja luki

Incydenty typu supply chain (kompromitacja łańcucha dostaw) należą do najgroźniejszych, bo nadużywają mechanizmu, któremu organizacje ufają najbardziej: legalnych aktualizacji. W przypadku eScan (MicroWorld Technologies) potwierdzono, że nieautoryzowany plik trafił do ścieżki dystrybucji aktualizacji w obrębie jednego z regionalnych klastrów serwerów, a następnie został pobrany przez część klientów w ograniczonym oknie czasowym 20 stycznia 2026 r.

W skrócie

eScan potwierdził nieautoryzowany dostęp do konfiguracji regionalnego serwera aktualizacji i dystrybucję błędnego/złośliwego pliku w kanale update w dniu 20.01.2026 (wąskie okno czasowe, wybrany klaster).
Morphisec opisał kampanię jako wieloetapową infekcję opartą o podmieniony komponent aktualizacji (m.in. Reload.exe) oraz dalsze payloady (m.in. CONSCTLX.exe), z naciskiem na „anti-remediation” (blokowanie przyszłych aktualizacji).
Kluczowy problem operacyjny: na systemach dotkniętych incydentem automatyczna naprawa/aktualizacja może nie działać, bo malware celowo psuje mechanikę aktualizacji.

Kontekst / historia / powiązania

To nie pierwszy raz, gdy eScan pojawia się w kontekście nadużyć aktualizacji. W 2024 r. opisywano operację przypisywaną aktorom powiązanym z Koreą Płn., gdzie mechanizm aktualizacji eScan miał zostać wykorzystany do dostarczania backdoorów i minerów (kampania określana m.in. jako GuptiMiner) – tam scenariusz obejmował manipulację ruchem/aktualizacją (MitM) i podmianę paczki.
Różnica w 2026 r. jest zasadnicza: tym razem mówimy o dystrybucji przez legalną infrastrukturę aktualizacji (zaufany kanał vendorowy), co zwykle zwiększa „skuteczność” kampanii i utrudnia wczesne wykrycie.

Analiza techniczna / szczegóły luki

Z perspektywy TTP (tactics/techniques/procedures) w opisie Morphisec przewijają się trzy szczególnie niebezpieczne elementy:

1) Trojanizacja komponentu aktualizacji (Stage 1)
Atak miał zacząć się od podmiany 32-bitowego komponentu związanego z aktualizacją – wskazywany jest Reload.exe – który następnie realizował persistence, wykonywanie poleceń i przygotowanie gruntu pod kolejne etapy.

2) „Anti-remediation”: blokowanie przyszłych aktualizacji i naprawy
Złośliwy kod miał modyfikować m.in. plik HOSTS oraz elementy konfiguracji/rejestru eScan tak, aby utrudnić komunikację z serwerami aktualizacji i uniemożliwić pobieranie kolejnych definicji/patche’y. To klasyczny wzorzec: utrzymać foothold i „odciąć” ofiarę od leczenia.

3) Persistence przez Scheduled Tasks + artefakty w rejestrze (Stage 2/3)
Morphisec opisuje m.in. tworzenie zadań harmonogramu podszywających się pod defragmentację (np. nazwy w stylu Windows\Defrag\…Defrag, przykładowo „CorelDefrag”) oraz podejrzane klucze w HKLM\Software\{GUID} z danymi w formie tablicy bajtów (PowerShell payload).

C2 / infrastruktura
Wskazano też przykładowe adresy C2 i zasoby pobierania kolejnych payloadów (w publikacjach zwykle podawane w formie zanonimizowanej typu hxxps://… i [.]). W praktyce SOC powinien dodać je do blokad na brzegu sieci i w DNS/Proxy, a następnie skorelować z logami. (

Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyka dla organizacji korzystających z eScan:

Utrata zaufania do kanału aktualizacji: nawet poprawnie zarządzany endpoint może zostać zainfekowany „legalnym” update’em.
Zablokowanie aktualizacji definicji AV/EDR: jeśli mechanizm aktualizacji zostanie uszkodzony, stacja robocza może pozostać w stanie „ślepoty” na nowe próbki i IOC.
Trwała obecność (persistence) i możliwość dalszej eskalacji: opisywane backdoory/downloader’y (np. CONSCTLX.exe) sugerują gotowość do dogrywania kolejnych modułów (kradzież danych, lateral movement, ransomware).
Ryzyko wtórnych kompromitacji: Morphisec rekomenduje także reset poświadczeń, jeśli zainfekowane hosty mogły uzyskać dostęp do kont/zasobów (typowy następny krok po supply chain).

Rekomendacje operacyjne / co zrobić teraz

Jeśli macie eScan w środowisku (enterprise lub consumer), sensowny playbook „tu i teraz”:

Ustal ekspozycję na okno 20.01.2026
- Przejrzyj logi aktualizacji eScan oraz ruch sieciowy z tego dnia, zwłaszcza jeśli endpointy korzystały z regionalnych serwerów/CDN.
Traktuj dotknięte hosty jak potencjalnie skompromitowane
- Izoluj z sieci systemy, na których wystąpiły symptomy: błędy aktualizacji, komunikaty o niedostępności update, zmiany w HOSTS, brak nowych definicji.
Polowanie na IOC (endpoint + AD + sieć)
- Szukaj: Reload.exe (nietypowe hashe/ścieżki), CONSCTLX.exe, zadań w Windows\Defrag\, podejrzanych kluczy HKLM\Software\{GUID} z danymi binarnymi, katalogów-znaczników (np. opisywany efirst w ProgramData).
Zablokuj infrastrukturę C2
- Dodaj domeny/IP z raportu do blokad (DNS sinkhole, proxy, firewall) i sprawdź historię połączeń.
Naprawa eScan może wymagać działania manualnego
- Morphisec podkreśla, że na zainfekowanych systemach automatyczne „doleczenie” może nie zadziałać, bo mechanizm aktualizacji został celowo uszkodzony — wymagany jest kontakt z vendorem i ręczne zastosowanie patcha/narzędzia naprawczego.
Forensics i higiena poświadczeń
- Zweryfikuj, czy doszło do uruchomienia Stage 3/backdoora; w razie potwierdzenia – pełne IR: timeline, triage pamięci, przegląd kont uprzywilejowanych, rotacja haseł/tokenów.

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

2024 (GuptiMiner) vs 2026 (kompromitacja serwera/klastra aktualizacji):

2024: opisywano scenariusz, w którym atakujący podmieniają paczkę aktualizacji w trakcie dostarczania (MitM / słabe zabezpieczenia kanału).
2026: według potwierdzenia eScan i analizy Morphisec, złośliwy plik był dystrybuowany przez legalną infrastrukturę aktualizacji (co zwykle bardziej przypomina klasyczne supply chain w stylu „zaufany update staje się wektorem ataku”).

Wniosek praktyczny: nawet jeśli organizacja „nie klika w linki” i ma twarde polityki, update pipeline dostawcy pozostaje krytycznym punktem ryzyka, który warto obejmować monitoringiem (np. allowlisting hash/certyfikatów + anomalia w zachowaniu procesu aktualizacji).

Podsumowanie / kluczowe wnioski

Incydent eScan to klasyczny atak na łańcuch dostaw, gdzie legalny kanał aktualizacji posłużył do dystrybucji malware w dniu 20 stycznia 2026 r.
Kluczową cechą kampanii jest blokowanie mechanizmu naprawy/aktualizacji (HOSTS + konfiguracja/rejestr eScan), co podnosi koszt i czas reakcji.
Najrozsądniejsze podejście: szybko ustalić ekspozycję, izolować podejrzane hosty, wykonać threat hunting po IOC, zablokować C2 i wdrożyć manualną ścieżkę remediation rekomendowaną przez vendor/partnerów badawczych.

Źródła / bibliografia

BleepingComputer – potwierdzenie incydentu przez MicroWorld/eScan, symptomy, kontekst i odniesienia do analizy Morphisec. (BleepingComputer)
Morphisec Threat Labs – „Threat Bulletin: Critical eScan Supply Chain Compromise” (łańcuch infekcji, IOC, persistence, remediation). (Morphisec)
SC Media (SCWorld) – streszczenie incydentu i rekomendacje działań operacyjnych (threat hunting, blokady C2, ostrożność wobec certyfikatu). (SC Media)
SecurityWeek – tło historyczne: kampania 2024 wykorzystująca mechanizm aktualizacji eScan (GuptiMiner, MitM). (SecurityWeek)

Krytyczna luka „sandbox escape” w vm2 dla Node.js (CVE-2026-22709) – jak działa i co zrobić natychmiast

Wprowadzenie do problemu / definicja luki

vm2 to popularna biblioteka do uruchamiania niezaufanego JavaScriptu w „piaskownicy” (sandboxie) w środowisku Node.js. Jej typowy cel to umożliwienie wykonywania kodu użytkownika bez dostępu do systemu plików czy API hosta.

W praktyce okazało się, że w vm2 wykryto krytyczną podatność typu sandbox escape oznaczoną jako CVE-2026-22709. Pozwala ona napastnikowi uciec z izolacji i wykonać dowolny kod na hoście (RCE) – czyli dokładnie złamać fundamentalne założenie „bezpiecznej piaskownicy”.

W skrócie

Identyfikator: CVE-2026-22709
Wektor: obejście mechanizmu sanitizacji callbacków dla Promise.then() / Promise.catch()
Skutek: sandbox escape → RCE na hoście
Wersje podatne: vm2 przed 3.10.2
Naprawa: aktualizacja do ≥ 3.10.2 (w praktyce najlepiej do najnowszej wersji z gałęzi 3.10.x)
Ocena ryzyka: CVSS 9.8 (Critical) wg CNA (GitHub)

Kontekst / historia / powiązania

vm2 jest szeroko używane m.in. w platformach SaaS pozwalających użytkownikom uruchamiać własne skrypty, runnerach kodu online czy botach/czatbotach. BleepingComputer podaje skalę użycia rzędu 200k+ projektów na GitHub oraz około ~1 mln pobrań tygodniowo w npm.

Jednocześnie vm2 ma historię kolejnych ucieczek z sandboxa. W 2023 r. głośne były m.in. CVE-2023-29017 oraz CVE-2023-30547 – obie klasy „sandbox escape”.
Według BleepingComputer projekt był nawet wstrzymany w 2023 r. z powodu powtarzających się problemów, a później „wskrzeszony” (powrót rozwoju i wersji 3.10.x).

Analiza techniczna / szczegóły luki

Sedno problemu to niekonsekwentna sanitizacja callbacków przypinanych do obietnic (Promises):

vm2 sanitizuje callbacki dla swojej „lokalnej” implementacji obietnic (w uproszczeniu: localPromise.prototype.then),
ale nie obejmuje tym samym mechanizmem „globalnych” Promise (tj. globalPromise.prototype.then),
a ponieważ wartości zwracane z async funkcji są oparte o globalny Promise, atakujący może doprowadzić do wykonania callbacka w sposób umożliwiający wyrwanie się do kontekstu hosta.

W praktyce publicznie pokazano PoC, w którym poprzez manipulację obsługą błędu i uzyskanie dostępu do konstruktorów (np. Function) da się finalnie doprowadzić do uruchomienia polecenia systemowego na hoście (np. przez child_process).

Status poprawek (ważne operacyjnie):

wg maintenera podatność była częściowo zaadresowana w 3.10.1,
a 3.10.2 „domknęło” fix tak, aby uniknąć możliwego obejścia.

Praktyczne konsekwencje / ryzyko

Jeśli Twoja aplikacja używa vm2 do uruchamiania jakiegokolwiek kodu pochodzącego od użytkownika lub z nie w pełni zaufanego źródła, konsekwencje mogą obejmować:

przejęcie serwera/aplikacji (RCE),
kradzież sekretów (zmienne środowiskowe, tokeny CI/CD, klucze API),
pivot do sieci wewnętrznej,
modyfikację danych i łańcuchy ataków supply chain (np. modyfikacja artefaktów build).

Co istotne: wektor CVSS wskazuje m.in. AV:N oraz brak wymogu uprawnień i interakcji użytkownika (wg CNA/GitHub), co w praktyce oznacza, że scenariusze zdalne są realne w wielu wdrożeniach.

Rekomendacje operacyjne / co zrobić teraz

Zrób szybki inventory zależności
- Sprawdź, czy vm2 jest zależnością bezpośrednią lub transytywną (np. npm ls vm2, SBOM, skan SCA).
Zaktualizuj vm2 do wersji bezpiecznej
- Minimum ≥ 3.10.2 (a najlepiej do najnowszej wersji w 3.10.x).
Jeśli nie możesz zaktualizować „tu i teraz” – załóż, że sandbox jest zawodny
- Uruchamiaj niezaufany kod w oddzielnym procesie/serwisie z twardą izolacją (kontener/VM), bez dostępu do sekretów i z minimalnymi uprawnieniami.
- Ogranicz egress (firewall), włącz profile typu AppArmor/SELinux/seccomp tam, gdzie to możliwe.
Wdróż detekcję i kontrolę ryzyka
- Monitoruj anomalie procesów (uruchomienia node, sh, bash, child_process), nietypowe połączenia sieciowe, zmiany plików.
Rozważ alternatywę architektoniczną
- Jeśli Twoim wymaganiem jest uruchamianie niezaufanego kodu, traktuj vm2 jako element wysokiego ryzyka i preferuj podejścia „defense-in-depth” (izolacja na poziomie OS, osobny worker pool, sandboxing poza jednym procesem Node). Kontekst „wracających ucieczek” w vm2 jest dobrze udokumentowany.

Różnice / porównania z innymi przypadkami

CVE-2026-22709 dotyczy wprost Promises i sanitizacji callbacków (then/catch) oraz różnicy między promise „lokalnym” a „globalnym” w kontekście async.
Wcześniejsze głośne podatności (np. CVE-2023-29017, CVE-2023-30547) również prowadziły do sandbox escape, ale wynikały z innych mechanizmów (np. obsługa wyjątków / sanitizacja wyjątków).

Wniosek praktyczny: nawet jeśli „załataliście” jedną klasę bypassu, model zagrożeń dla vm2 powinien zakładać kolejne obejścia, dlatego izolacja warstwowa (process/container/VM) jest kluczowa.

Podsumowanie / kluczowe wnioski

CVE-2026-22709 to krytyczny sandbox escape w vm2, umożliwiający RCE na hoście.
Podatne są wersje przed 3.10.2; fix został domknięty w 3.10.2.
Jeśli vm2 obsługuje kod użytkownika lub dane, które mogą zostać „przemycone” do wykonywanego JS, priorytetem jest natychmiastowy upgrade i izolacja defense-in-depth.

Źródła / bibliografia

BleepingComputer – opis podatności, kontekst popularności i historia vm2 (BleepingComputer)
NVD (NIST) – rekord CVE-2026-22709 i opis mechanizmu podatności (NVD)
GitHub Advisory Database – GHSA-99p7-6v5w-7xg8, metryki i techniczne detale/PoC (GitHub)
Semgrep Blog – omówienie ryzyka i rekomendacja aktualizacji do 3.10.2 (semgrep.dev)
Snyk Vulnerability Database – widok wersji i statusu podatności w najnowszych wydaniach (VulnInfo Guide)

FG-IR-26-060 / CVE-2026-24858: krytyczne obejście uwierzytelniania FortiCloud SSO w FortiOS, FortiManager i FortiAnalyzer

Wprowadzenie do problemu / definicja luki

Fortinet opublikował advisory PSIRT o numerze FG-IR-26-060 (data publikacji: 27 stycznia 2026) dotyczący krytycznej podatności w mechanizmie FortiCloud Single Sign-On (SSO), umożliwiającej obejście uwierzytelniania administracyjnego w produktach FortiOS, FortiManager oraz FortiAnalyzer.

Podatność ma identyfikator CVE-2026-24858 i jest klasyfikowana jako Authentication Bypass Using an Alternate Path or Channel (CWE-288) — czyli sytuacja, w której produkt „wymaga logowania”, ale istnieje alternatywna ścieżka prowadząca do skutecznego uwierzytelnienia bez prawidłowej weryfikacji.

W skrócie

CVE: CVE-2026-24858 (krytyczna; Fortinet/CNA: CVSS 9.8)
Dotknięte produkty: FortiOS / FortiManager / FortiAnalyzer (w określonych zakresach wersji) (
Warunek ataku: włączone FortiCloud SSO (logowanie admina przez FortiCloud); atakujący musi posiadać konto FortiCloud i zarejestrowane urządzenie
Status: obserwowano aktywne wykorzystanie w środowiskach produkcyjnych; Fortinet czasowo ograniczał działanie FortiCloud SSO, a następnie przywrócił je z blokadą logowań z podatnych wersji firmware

Kontekst / historia / powiązania

W grudniu 2025 Fortinet opisywał wcześniejsze problemy związane z omijaniem FortiCloud SSO (m.in. CVE-2025-59718 i CVE-2025-59719). Nowy incydent był początkowo postrzegany jako „powrót” tamtego wektora, jednak Fortinet wskazał przypadki naruszeń na urządzeniach, które były już zaktualizowane zgodnie z wcześniejszym advisory — co zasugerowało istnienie nowej ścieżki ataku (alternate path).

Z perspektywy IR ważna jest też oś czasu działań dostawcy: Fortinet wskazał m.in. blokowanie nadużywanych kont i czasowe wyłączenie FortiCloud SSO po stronie chmury, a następnie przywrócenie usługi z ograniczeniem dla podatnych wersji.

Analiza techniczna / szczegóły luki

Na czym polega problem

Opis CVE sprowadza się do ryzyka naruszenia izolacji między tenantami/klientami w przepływie FortiCloud SSO: atakujący z kontem FortiCloud i zarejestrowanym urządzeniem może w pewnych warunkach zalogować się administracyjnie do urządzeń zarejestrowanych na inne konta, jeśli na tych urządzeniach włączono FortiCloud SSO dla admina.

Co widać w telemetrii

Fortinet opublikował przykładowe wskaźniki i logi, które pomagają odróżnić „normalne” SSO od nadużycia:

obserwowane konta użyte do logowań SSO: cloud-noc@mail.io, cloud-init@mail.io
przykładowe adresy IP (część ukrywana za Cloudflare): m.in. 104[.]28.244.115, 104[.]28.212.114 oraz dodatkowe IP raportowane przez strony trzecie
typowy ciąg zdarzeń po udanym logowaniu: utworzenie lokalnego konta admin (np. audit, backup, itadmin, secadmin, support i inne) jako mechanizm persystencji

Fortinet pokazał również przykład wpisu logu „Admin login successful” z method="sso" oraz kolejny log wskazujący dodanie obiektu w system.admin (tworzenie nowego admina).

Zakres wersji narażonych

W opisie NVD wskazano zakresy wersji, dla których ryzyko dotyczy m.in.:

FortiOS: 7.0.0–7.0.18, 7.2.0–7.2.12, 7.4.0–7.4.10, 7.6.0–7.6.5
analogicznie dla FortiManager i FortiAnalyzer w odpowiadających gałęziach 7.0/7.2/7.4/7.6

(Uwaga operacyjna: „zakres dotknięty” ≠ „zakres wdrożony w Twojej organizacji”. Jeśli masz mieszane wersje i centralne zarządzanie, traktuj temat jako kampanię obejmującą całą flotę.)

Praktyczne konsekwencje / ryzyko

Skuteczne obejście uwierzytelnienia administracyjnego na urządzeniu brzegowym/zarządzającym oznacza w praktyce „pełne przejęcie”:

modyfikacja polityk firewall/VPN, tworzenie tuneli i kont zdalnego dostępu
eksfiltracja konfiguracji (często zawierającej informacje o topologii, adresacji, integracjach, kontach i certyfikatach)
przygotowanie persystencji (lokalne konta admin) i pivot do sieci wewnętrznej

Dodatkowy wątek: Fortinet podkreślił, że choć obserwowana eksploatacja dotyczyła FortiCloud SSO, to problem klasy „SAML SSO alternate path” może mieć szerszy kontekst w organizacjach, które wdrażają SSO także z innymi dostawcami.

Rekomendacje operacyjne / co zrobić teraz

1) Ogranicz powierzchnię ataku na interfejs zarządzania (natychmiast)

Fortinet rekomenduje twarde ograniczenie dostępu administracyjnego (najlepiej out-of-band; alternatywnie allowlista IP przez local-in policy).

2) Rozważ czasowe wyłączenie FortiCloud SSO dla logowań admina

Jeśli Twoje procesy na to pozwalają, wyłącz „Allow administrative login using FortiCloud SSO” i przejdź na kontrolowane metody dostępu. Fortinet podaje też komendę CLI:
set admin-forticloud-sso-login disable

(W części środowisk Fortinet wdrożył dodatkowo blokowanie logowań SSO z podatnych wersji po stronie chmury — ale to nie zwalnia z higieny zarządzania i kontroli dostępu.)

3) Threat hunting / detekcja

Sprawdź:

logowania admin method="sso" i nietypowe ui="sso(...)"
wystąpienia kont cloud-init@mail.io / cloud-noc@mail.io (oraz inne nieoczekiwane tożsamości SSO)
nowe konta admin o podejrzanych nazwach (lista w sekcji IOC)

4) Jeżeli widzisz IOC — traktuj system jako skompromitowany

Fortinet zaleca m.in.: przywrócenie konfiguracji z „known good”, audyt zmian, rotację haseł/sekretów (w tym integracji LDAP/AD) i pełny przegląd kont administracyjnych.

5) Patch management

Kieruj się zasadą: zaktualizuj do najnowszego dostępnego wydania w danej gałęzi (lub wykonaj upgrade międzygałęziowy zgodny z polityką Twojej organizacji) i monitoruj komunikaty PSIRT/CVE. Zakresy wersji dotkniętych masz w NVD, a status/zmiany mitigacji Fortinet aktualizował w komunikacji PSIRT/blogu.

Różnice / porównania z innymi przypadkami

Podobieństwo do CVE-2025-59718/59719 (grudzień 2025): ten sam „obszar funkcjonalny” (FortiCloud SSO) i podobne symptomy (logowanie SSO, tworzenie lokalnych adminów).
Różnica kluczowa: według Fortinet/BleepingComputer ataki występowały również tam, gdzie wcześniejsze poprawki były już wdrożone — co wskazuje na inną ścieżkę obejścia (alternate path), a nie prosty „patch bypass” jednego CVE.

Podsumowanie / kluczowe wnioski

CVE-2026-24858 (FG-IR-26-060) to krytyczne obejście uwierzytelniania w przepływie FortiCloud SSO z realnymi przypadkami nadużyć.
Największe ryzyko dotyczy środowisk z włączonym logowaniem administracyjnym przez FortiCloud SSO oraz wystawionym/nieograniczonym dostępem do panelu zarządzania.
Priorytet „tu i teraz”: ograniczenie dostępu admin, monitoring IOC, oraz gotowość do pełnych działań IR (rotacje, rollback konfiguracji) w razie wykrycia śladów ataku.

Źródła / bibliografia

Fortinet PSIRT Blog: Analysis of Single Sign-On Abuse on FortiOS (22 stycznia 2026) (fortinet.com)
NIST NVD: CVE-2026-24858 (NVD)
BleepingComputer: Fortinet blocks exploited FortiCloud SSO zero day until patch is ready (27 stycznia 2026) (BleepingComputer)
FortiGuard PSIRT (metadane advisory w wynikach wyszukiwania): FG-IR-26-060 Administrative FortiCloud SSO authentication bypass (fortiguard.fortinet.com)