Archiwa: Firewall - Strona 10 z 24 - Security Bez Tabu

Ł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

  1. 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.
  2. „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).
  3. 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.
  4. 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

  1. The Record (Recorded Future News): materiał o ostrzeżeniach SAB i rekordzie zagrożeń w 2025 r. (The Record from Recorded Future)
  2. SAB — Annual Report 2025 (ENG), unclassified part.
  3. CERT.LV: Latvian Cyberspace Situation Q3 2025.
  4. CERT.LV: The situation in Latvian cyberspace Q1 2025. (cert.lv)
  5. 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”:

  1. 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.
  2. 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.
  3. 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).
  4. Zablokuj infrastrukturę C2
    • Dodaj domeny/IP z raportu do blokad (DNS sinkhole, proxy, firewall) i sprawdź historię połączeń.
  5. 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.
  6. 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

  1. BleepingComputer – potwierdzenie incydentu przez MicroWorld/eScan, symptomy, kontekst i odniesienia do analizy Morphisec. (BleepingComputer)
  2. Morphisec Threat Labs – „Threat Bulletin: Critical eScan Supply Chain Compromise” (łańcuch infekcji, IOC, persistence, remediation). (Morphisec)
  3. SC Media (SCWorld) – streszczenie incydentu i rekomendacje działań operacyjnych (threat hunting, blokady C2, ostrożność wobec certyfikatu). (SC Media)
  4. 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

  1. 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).
  2. Zaktualizuj vm2 do wersji bezpiecznej
    • Minimum ≥ 3.10.2 (a najlepiej do najnowszej wersji w 3.10.x).
  3. 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.
  4. Wdróż detekcję i kontrolę ryzyka
    • Monitoruj anomalie procesów (uruchomienia node, sh, bash, child_process), nietypowe połączenia sieciowe, zmiany plików.
  5. 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

  1. BleepingComputer – opis podatności, kontekst popularności i historia vm2 (BleepingComputer)
  2. NVD (NIST) – rekord CVE-2026-22709 i opis mechanizmu podatności (NVD)
  3. GitHub Advisory Database – GHSA-99p7-6v5w-7xg8, metryki i techniczne detale/PoC (GitHub)
  4. Semgrep Blog – omówienie ryzyka i rekomendacja aktualizacji do 3.10.2 (semgrep.dev)
  5. 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

  1. CVE-2026-24858 (FG-IR-26-060) to krytyczne obejście uwierzytelniania w przepływie FortiCloud SSO z realnymi przypadkami nadużyć.
  2. Największe ryzyko dotyczy środowisk z włączonym logowaniem administracyjnym przez FortiCloud SSO oraz wystawionym/nieograniczonym dostępem do panelu zarządzania.
  3. 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)

Luki w systemach kontroli dostępu dormakaba: jak „cyber” może przełożyć się na otwieranie drzwi w realu

Wprowadzenie do problemu / definicja luki

Systemy PACS (Physical Access Control Systems) – serwery zarządzania, kontrolery przejść, rejestratory/kioski (PIN, RFID, biometria) – są dziś częścią krytycznej infrastruktury organizacji: biur, logistyki, energetyki czy lotnisk. Gdy w takim ekosystemie pojawiają się podatności typu brak uwierzytelnienia, hardcoded credentials/keys, słabe hasła domyślne czy command injection, ryzyko nie kończy się na „danych” – może dotyczyć też fizycznego dostępu do stref chronionych.


W skrócie

  • Badacze SEC Consult opisali ponad 20 podatności w środowisku kontroli dostępu dormakaba (m.in. exos 9300, Access Manager, registration unit).
  • Scenariusze nadużyć obejmują m.in. zdalne otwieranie drzwi, zmianę konfiguracji kontrolerów i pozyskanie wrażliwych danych (np. PIN-ów).
  • Producent wskazuje, że do skutecznej eksploatacji zwykle potrzebny jest dostęp do sieci/infrastruktury klienta, ale SEC Consult zwraca uwagę na przypadki systemów wystawionych do internetu, co zmienia profil zagrożenia.
  • dormakaba opublikowała biuletyny i aktualizacje oraz wytyczne hardeningu (m.in. podniesienie wersji exos 9300 i zabezpieczenie komunikacji z kontrolerami).

Kontekst / historia / powiązania

Opisane podatności dotyczą rozwiązań wdrażanych głównie w dużych organizacjach w Europie (m.in. przemysł, usługi, logistyka, energetyka, operatorzy lotnisk). SEC Consult podkreśla też typowy problem tej klasy systemów: wysoki próg wejścia dla niezależnych badań (koszt, dostępność, złożoność), co często skutkuje niższą „częstotliwością pentestów” niż w przypadku popularnych aplikacji webowych.


Analiza techniczna / szczegóły luki

Poniżej najważniejsze klasy podatności i przykładowe, konkretne wektory opisane w materiałach producenta i badaczy:

1) Brak uwierzytelnienia usług / interfejsów zarządzania

W biuletynie producenta dla exos 9300 pojawia się m.in. problem nieautoryzowanego dostępu do SOAP API (port 8002), które ma umożliwiać m.in. odpytywanie informacji wrażliwych (np. PIN-y 2FA powiązane z kartami) oraz generowanie zdarzeń logów.

2) Hardcoded credentials i możliwość sterowania kontrolerami

W tym samym advisory wskazano wbudowane (hard-coded) poświadczenia dla kont „legacy”, które mogą umożliwiać logowanie do usługi pośredniczącej w komunikacji statusów z Access Managerami (m.in. porty 1004/1005), a w konsekwencji także wysyłanie komend – w tym otwierania drzwi.

3) Słabe mechanizmy ochrony sekretów (klucze/„szyfrowanie” PIN-ów)

W advisory producent opisuje też przypadki hard-coded sekretów oraz słabe podejścia do ochrony danych (np. statyczny klucz / niestandardowe mechanizmy), co przekłada się na ryzyko ujawnienia lub odtworzenia wrażliwych informacji przechowywanych w bazie.

4) Lokalna eskalacja uprawnień i podatności konfiguracyjne

Część problemów ma charakter „post-exploitation” (np. lokalne podbicie uprawnień na serwerze aplikacyjnym), co jest szczególnie groźne w scenariuszach: dostęp gościa do sieci, kompromitacja stacji admina, przeskok z innego segmentu OT/IT.


Praktyczne konsekwencje / ryzyko

W praktyce taki łańcuch podatności może umożliwić:

  • otwieranie wybranych przejść (drzwi/bramki) bez autoryzacji lub z pominięciem standardowych ścieżek,
  • rekonesans i eskalację: podejrzenie konfiguracji, relacji kontrolerów, topologii stref, a także dalsze nadużycia w sieci (pivoting),
  • kompromitację danych uwierzytelniających (PIN-y, informacje o kartach/użytkownikach, logi zdarzeń),
  • atak mieszany cyber–physical: kradzież, sabotaż, wejście do serwerowni, stref OT, magazynów wysokiej wartości.

Istotny niuans z punktu widzenia ryzyka: vendor akcentuje „wymóg dostępu do sieci klienta”, ale badacze wskazali na przypadki internet-exposed instancji, które potencjalnie dają drogę ataku „z zewnątrz” bez wcześniejszego wejścia do sieci.


Rekomendacje operacyjne / co zrobić teraz

Jeżeli w organizacji działa dormakaba / Kaba exos 9300 lub komponenty powiązane (Access Manager, registration unit), sensowny plan „na teraz”:

  1. Inwentaryzacja i ekspozycja
  • Sprawdź, gdzie działa exos 9300 oraz urządzenia peryferyjne (kontrolery/rejestratory).
  • Zweryfikuj, czy cokolwiek jest wystawione do internetu (VPN ≠ internet; sprawdź też NAT/port-forward i „tymczasowe” wyjątki).
  1. Aktualizacje i twarde minimum wersji
  • Producent zaleca aktualizację exos 9300 do nowszych wydań (w advisory pojawia się próg co najmniej 4.4.x / 4.4.1 dla części podatności) oraz wdrożenie zadań mitygacyjnych i hardeningu.
  1. Segmentacja + ograniczenie portów/usług
  • Zablokuj dostęp do usług zarządzania z sieci nieadministracyjnych.
  • Zastosuj zasady „deny by default” na poziomie ACL/Firewall w segmentach PACS.
  1. Zabezpieczenie komunikacji do kontrolerów
  • W biuletynie wskazano m.in. szyfrowanie kanałów do Access Managerów: IPsec (dla określonych generacji) oraz mTLS/HTTPS dla nowszych wdrożeń, a także domyślne HTTPS w nowych instalacjach przy exos 4.4.x (zależnie od scenariusza).
  1. Higiena poświadczeń i monitoring
  • Usuń/wyłącz konta nieużywane, zmień hasła domyślne (tam gdzie dotyczy).
  • Wdróż alerty na nietypowe komendy „door open”, zmiany konfiguracji kontrolerów i anomalie w logach systemu.

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

To zdarzenie wyróżnia się tym, że dotyczy systemu, w którym skutkiem incydentu może być natychmiastowy wpływ fizyczny (otwieranie drzwi/stref). W klasycznych podatnościach IT konsekwencją bywa „tylko” wyciek lub przerwa w działaniu; tutaj ryzyko obejmuje też bezpieczeństwo ludzi, ciągłość operacji i ochronę obiektów.


Podsumowanie / kluczowe wnioski

  • PACS to nie „zwykły IoT” – to infrastruktura, w której błędy w auth/sekretach mogą przełożyć się na realny dostęp do obiektów.
  • Najbardziej krytyczne są scenariusze: brak uwierzytelnienia usług, hardcoded credentials, oraz błędna ekspozycja do internetu.
  • Aktualizacje i hardening od producenta są dostępne – ale kluczowe jest też to, co po stronie klienta: segmentacja, kontrola ekspozycji, szyfrowanie kanałów, monitoring i proces zarządzania poprawkami.

Źródła / bibliografia

  1. SecurityWeek – opis podatności i kontekstu wdrożeń (26 stycznia 2026). (SecurityWeek)
  2. SEC Consult – „Hands-Free Lockpicking…” (26.01.2026) + odnośniki do advisory. (SEC Consult)
  3. dormakaba Group – lista Security Advisories (26 stycznia 2026). (EN – dormakaba Group)
  4. dormakaba – DKSA-26-26-012 (PDF) „Kaba exos 9300” (CVE m.in. 2025-59090…59096). (Contentful Assets)

7 Typowych Pułapek W Procesie Zarządzania Incydentami I Jak Ich Unikać

Dlaczego to ma znaczenie

Gdy dochodzi do cyberincydentu, czas działa na niekorzyść obrony. To, jak zespół zareaguje w pierwszych godzinach, decyduje o tym, czy incydent będzie tylko drobnym potknięciem, czy pełnowymiarową katastrofą. Dobre przygotowanie potrafi zamienić potencjalny paraliż firmy w kontrolowane zdarzenie o minimalnym wpływie. Z kolei brak planu i chaotyczne działania “na gorąco” często tylko pogarszają sytuację.

Czytaj dalej „7 Typowych Pułapek W Procesie Zarządzania Incydentami I Jak Ich Unikać”

Nike bada możliwy incydent bezpieczeństwa. WorldLeaks grozi publikacją danych – co wiemy i jak reagować

Wprowadzenie do problemu / definicja luki

W tego typu sprawach kluczowe jest rozróżnienie: nie zawsze mamy potwierdzone naruszenie (data breach), nawet jeśli grupa przestępcza publikuje wpis na swoim „leak site”. Coraz częściej obserwujemy model wymuszeń oparty wyłącznie o kradzież danych i groźbę ich upublicznienia (bez szyfrowania systemów). Taki „hack & leak” bywa dla ofiary trudniejszy: kopie zapasowe nie rozwiązują problemu, bo presja wynika z ryzyka reputacyjnego, prawnego i konkurencyjnego.

W przypadku Nike publicznie wiadomo przede wszystkim tyle, że firma prowadzi dochodzenie po tym, jak WorldLeaks ogłosił ją jako ofiarę i uruchomił licznik do publikacji danych.


W skrócie

  • 22 stycznia 2026: Nike zostało wymienione jako ofiara na torowym serwisie wyciekowym grupy WorldLeaks; wpis zawierał odliczanie do ujawnienia danych.
  • 24 stycznia 2026: według opisu w mediach branżowych licznik wskazywał publikację na ten dzień, o ile nie dojdzie do zapłaty/porozumienia.
  • Nike potwierdziło, że „bada potencjalny incydent cyberbezpieczeństwa” i „aktywnie ocenia sytuację”.
  • Na moment publikacji informacji grupa nie podała (publicznie) skali ani rodzaju rzekomo wykradzionych danych.

Kontekst / historia / powiązania

WorldLeaks to marka, która jest szeroko opisywana jako pivot/rebrand Hunters International – grupy znanej z działań ransomware, która w 2025 r. ogłaszała zamknięcie operacji i „morfowanie” w kierunku czystej eksfiltracji i szantażu danymi.

Z perspektywy „ekosystemu” to ważne, bo oznacza przejście od klasycznego „zablokuję ci systemy” do „zabiorę ci dane i zrobię z nich broń”. Profile threat-intel wskazują, że WorldLeaks funkcjonuje w modelu Extortion-as-a-Service (platforma/portale do negocjacji i publikacji), a infrastruktura bywa rozbudowana o elementy typowo „PR-owe” dla przestępców (np. kanały ułatwiające nagłośnienie wycieku).


Analiza techniczna / szczegóły incydentu

Co wiemy technicznie o zdarzeniu Nike?

Publicznie nie ma (na ten moment) raportu technicznego: brak IOC, brak potwierdzonego wektora wejścia, brak wskazanych systemów czy usług. Mamy natomiast klasyczny wzorzec dla grup nastawionych na wymuszenie: wpis na leak site + deadline.

Jak zwykle wygląda łańcuch ataku w modelu WorldLeaks

W profilach operacyjnych tej grupy (i podobnych) powtarzają się następujące drogi uzyskania dostępu:

  • skompromitowane konta (valid accounts),
  • zewnętrzne usługi zdalne (external remote services) i braki w MFA,
  • phishing,
  • eksploatacja aplikacji wystawionych do Internetu.

Po wejściu do środowiska priorytetem jest odszukanie wartościowych repozytoriów (projekty, dokumenty prawne/HR, dane partnerów, IP) i eksfiltracja – często „cicho”, bez natychmiastowego szyfrowania. To spójne z trendem, w którym przestępcy redukują „hałas” operacyjny, bo presję na ofiarę buduje groźba ujawnienia danych.


Praktyczne konsekwencje / ryzyko

W scenariuszu, w którym doszło do realnej eksfiltracji, ryzyka zwykle układają się w 4 warstwach:

  1. Ryzyko prawne i regulacyjne – obowiązki notyfikacyjne (w zależności od jurysdykcji i kategorii danych), pozwy zbiorowe, audyty.
  2. Ryzyko konkurencyjne – wyciek IP (projekty, roadmapy, umowy, dane dot. łańcucha dostaw).
  3. Ryzyko dla osób – jeśli w paczce są dane pracowników/klientów, rośnie ryzyko phishingu, podszyć i fraudów.
  4. Ryzyko wtórnej kompromitacji – wykradzione sekrety (tokeny, klucze, hasła w dokumentach) mogą otwierać drogę do kolejnych ataków.

Istotne: nawet jeśli firma szybko „posprząta” dostęp napastnika, wyciek może nastąpić później, bo dźwignią jest już sama kopia danych poza organizacją.


Rekomendacje operacyjne / co zrobić teraz

Poniżej praktyczny, bezpieczny schemat działań (zbieżny z podejściem NIST do reagowania na incydenty: przygotowanie → detekcja/analiza → ograniczenie/usunięcie skutków → odtworzenie → wnioski).

0–24h: ogranicz straty i zabezpiecz dowody

  • Zamroź ryzyko eksfiltracji: ogranicz egress (proxy/firewall), włącz reguły na duże transfery, sprawdź nietypowe kanały (SFTP, Rclone, chmury prywatne).
  • Oceń tożsamość: wymuś reset haseł, rotację tokenów/kluczy, przegląd kont uprzywilejowanych; natychmiastowe MFA wszędzie, gdzie to możliwe.
  • Zabezpiecz dowody: kopie logów (IdP, VPN, EDR, CASB, M365/Google), snapshoty krytycznych hostów – zanim zmiany utrudnią analizę.
  • Ustaw „war room”: jedna ścieżka decyzyjna (SecOps/IR + Legal + PR + zarząd).

24–72h: odpowiedz „pod wyciek”, nie tylko „pod włamanie”

  • Ustal zakres danych: które repozytoria i wolumeny mogły wyjść (DLP, SIEM, logi pobrań, audyty dostępu).
  • Przygotuj komunikację: szablony dla klientów/partnerów/pracowników; scenariusze na publikację fragmentów danych.
  • Wzmocnij monitoring: obserwuj wzmożony spear-phishing (na podstawie tematów i nazw projektów, jeśli wyciek dotyczy dokumentów).
  • Wnioski i hardening: zamknij wektor wejścia (tożsamość, exposed services, podatności), a potem dopiero „poleruj” środowisko.

Uwaga praktyczna: w modelu „hack & leak” krytyczne jest traktowanie sprawy jako incydentu naruszenia poufności, a nie wyłącznie „nieautoryzowanego dostępu”. To inne priorytety i inny zestaw interesariuszy.


Różnice / porównania z innymi przypadkami

Klasyczny ransomware (szyfrowanie) uderza w dostępność i ciągłość działania.
Czysta eksfiltracja i szantaż uderza w poufność, reputację i ryzyko prawne – a przez to potrafi być bardziej „długodystansowa”.

WorldLeaks jest często opisywany jako przykład tej ewolucji: formalnie „odchodzenie od szyfrowania”, nacisk na wykradanie danych i publikacje na leak site.


Podsumowanie / kluczowe wnioski

  • Nike potwierdziło, że bada potencjalny incydent, po wpisie grupy WorldLeaks z odliczaniem do publikacji.
  • Brak twardych danych technicznych oznacza, że na tym etapie należy unikać spekulacji o wektorze wejścia – ale model wymuszenia (deadline + leak site) jest czytelny.
  • Dla organizacji najważniejsze są działania „pod wyciek”: ograniczenie eksfiltracji, kontrola tożsamości, ochrona dowodów i gotowość komunikacyjno-prawna (NIST IR).

Źródła / bibliografia

  1. SecurityWeek – Nike Probing Potential Security Incident as Hackers Threaten to Leak Data (24.01.2026). (SecurityWeek)
  2. SecurityWeek – Hunters International Shuts Down… as It Morphs Into World Leaks (07.07.2025). (SecurityWeek)
  3. Halcyon – Threat Actor Profile: World Leaks (informacje o rebrandzie, infrastrukturze, afiliacjach). (Halcyon)
  4. Blackpoint Cyber – Threat Profile: World Leaks Ransomware (wektory wejścia, mapowania ATT&CK, model data extortion). (Blackpoint)
  5. NIST – SP 800-61r3 (Incident Response Recommendations…) (04.2025, publikacja/wersja robocza – rekomendacje IR). (NIST Publications)