Archiwa: SIEM - Strona 23 z 46 - Security Bez Tabu

FortiGuard AntiVirus Updates: co mówi feed aktualizacji i dlaczego to krytyczne dla ochrony FortiGate/FortiClient

Wprowadzenie do problemu / definicja „luki”

W świecie bezpieczeństwa „luka” nie zawsze oznacza CVE. Bardzo często realną luką operacyjną jest opóźniona lub nieskuteczna dystrybucja aktualizacji sygnatur antywirusowych. W praktyce: urządzenie może działać poprawnie, polityki są przypięte, a mimo to ochrona jest osłabiona, bo baza detekcji nie nadąża za kampaniami malware.


W skrócie

  • Feed aktualizacji pokazuje numer wersji bazy AV oraz tempo zmian (ile definicji dodano/zmodyfikowano).
  • FortiGuard AntiVirus to usługa subskrypcyjna dostarczająca sygnatury + mechanizmy heurystyczne/behawioralne oraz elementy AI/ML, zintegrowana z wieloma produktami Fortinet (m.in. FortiGate, FortiClient, FortiMail, FortiWeb).
  • W FortiOS (co najmniej od linii 7.2.x) istotnym elementem łańcucha zaufania jest weryfikacja paczek aktualizacji – m.in. AV/IPS są cyfrowo podpisywane i mogą być walidowane pod kątem autentyczności/integralności.
  • Harmonogram aktualizacji (scheduled updates) oraz scenariusze „manual update” to kluczowe mechanizmy zapewnienia ciągłości ochrony.

Kontekst / historia / powiązania

FortiGuard Antivirus Service jest zaprojektowany jako ciągła usługa aktualizacji ochrony przed malware – nie tylko klasyczne sygnatury, ale też techniki heurystyczne, behawioralne oraz analityka wsparta AI/ML. Fortinet podkreśla też własny mechanizm CPRL (Content Pattern Recognition Language) jako element zwiększający pokrycie detekcji, także dla wariantów, które nie mają „klasycznej” sygnatury.

W tym modelu aktualność bazy (oraz sprawny kanał dystrybucji) jest krytyczna, bo:

  • kampanie malware zmieniają próbki i ładunki w godzinach, nie tygodniach,
  • wiele detekcji „z pola” trafia do usług TI i wraca jako aktualizacja,
  • a urządzenia w edge (FortiGate) i na endpointach (FortiClient) są często pierwszą linią obrony.

Analiza techniczna / szczegóły „feedu” aktualizacji

1) Co faktycznie oznacza „Version” w FortiGuard AntiVirus Updates

Publiczny feed aktualizacji wskazuje wersję pakietu definicji (np. 93.06391) oraz datę publikacji. Do tego dochodzi liczba rekordów New i Modified, co jest praktycznym sygnałem: czy to była „cisza” (mało zmian), czy duży rzut aktualizacji. (

To ważne w diagnostyce:

  • jeśli Twoje urządzenia „stoją” na wersji sprzed kilku dni, a feed idzie do przodu – masz problem z pobieraniem,
  • jeśli feed też „stoi” (brak świeżych wydań), to raczej problem po stronie publikacji (rzadkie, ale możliwe).

2) Scheduled vs manual updates

W środowiskach produkcyjnych standardem powinny być scheduled updates (automatyczne odświeżanie baz przez FortiGuard). Dokumentacja Fortinet opisuje konfigurację harmonogramów aktualizacji w sekcji FortiGuard (GUI) jako element administracji urządzeniem.

Równolegle istnieją procedury manual updates – przydatne w scenariuszach:

  • środowiska odseparowane (air-gapped / ograniczony egress),
  • awaria lub filtracja DNS/HTTP(S) po drodze,
  • polityki proxy/SSL inspection blokujące ruch aktualizacyjny.

3) Zaufanie do paczek: podpisy cyfrowe i walidacja

Ryzyko „update channel compromise” (lub podstawienia paczki) to klasyczny problem bezpieczeństwa. Dlatego Fortinet wdraża mechanizmy weryfikacji:

  • społeczność Fortinet opisuje, że od v7.2.0 pakiety AV/IPS są podpisywane przez CA Fortinet w celu zapewnienia autentyczności i integralności.
  • w dokumentacji FortiOS pojawia się też koncepcja BIOS-level signature and file integrity checking (m.in. dla firmware oraz plików silników AV/IPS), jako dodatkowa warstwa kontroli podpisu i integralności.

To nie jest „miły dodatek” – to realna redukcja ryzyka supply-chain w kanałach aktualizacji.


Praktyczne konsekwencje / ryzyko

  1. Okno podatności na kampanie i warianty malware
    Jeżeli definicje są nieaktualne, wzrasta prawdopodobieństwo przepuszczenia:
  • świeżych loaderów,
  • nowych wariantów ransomware,
  • phishingowych załączników z nowymi packerami.
  1. Fałszywe poczucie bezpieczeństwa
    Polityka AV włączona ≠ skuteczna ochrona. W SOC to częsty „cichy” problem: urządzenie raportuje aktywną usługę, ale baza ma stare wydanie.
  2. Niespójność ochrony w Security Fabric
    Fortinet podkreśla integracje usługi AV w wielu produktach (FortiGate, FortiClient, FortiMail, FortiWeb…). Jeśli część komponentów ma opóźnione aktualizacje, pojawiają się luki w pokryciu i różnice w detekcji.
  3. Ryzyko operacyjne przy incydencie
    Podczas aktywnej kampanii malware pierwsze pytanie IR często brzmi: „jakie wersje sygnatur były na brzegu i endpointach w chwili zdarzenia?”. Feed pomaga ustalić punkt odniesienia.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które zwykle dają największy zwrot w stabilności aktualizacji i jakości ochrony:

1) Ustal „golden baseline” wersji

  • Sprawdź w feedzie, jaka jest najnowsza wersja (obecnie: 93.06391 z 4 stycznia 2026, 06:45).
  • Porównaj z wersjami na FortiGate/FortiClient (dashboard/licensing/fortiguard).
  • Wprowadź alert (np. w SIEM): „urządzenie odstaje o >24h od wersji referencyjnej”.

2) Zadbaj o poprawną strategię aktualizacji (scheduled + fallback)

  • Włącz i zweryfikuj scheduled updates zgodnie z możliwościami sprzętu i polityką okien serwisowych.
  • Zaplanuj awaryjny tryb manual update (procedura, dostęp, odpowiedzialności).

3) Sprawdź łączność i pośredników (DNS/Proxy/SSL inspection)

Najczęstsze przyczyny „nie aktualizuje się” to:

  • restrykcje egress (firewall upstream),
  • filtracja DNS,
  • proxy z inspekcją TLS, które psuje łańcuch zaufania,
  • nietypowe trasy/VDOM-y.

4) Waliduj paczki i twardo trzymaj łańcuch zaufania

Jeżeli Twoja wersja FortiOS to obsługuje, korzystaj z mechanizmów weryfikacji podpisów paczek (AV/IPS) oraz ogólnej kontroli integralności. To ogranicza ryzyko podstawienia aktualizacji.

5) Raportuj do biznesu prostym wskaźnikiem

Dla kierownictwa najlepiej działa KPI:

  • „% urządzeń z bazą AV młodszą niż 24h”
  • „median age of signatures”
  • „liczba urządzeń z błędami aktualizacji”

Różnice / porównania z innymi przypadkami

  • Model sygnaturowy vs wielowarstwowy: Fortinet jawnie opisuje miks sygnatur, heurystyki, zachowań i AI/ML, plus integracje w Security Fabric. To podejście jest bliższe „usłudze ochrony” niż samemu plikowi definicji.
  • Publiczny wskaźnik świeżości: feed aktualizacji jest praktyczny w troubleshooting (łatwo odróżnić problem lokalny od globalnego).
  • Supply-chain hardening: podpisywanie paczek AV/IPS i mechanizmy weryfikacji integralności to ważny element, którego brak lub słaba implementacja bywa bolesna u różnych dostawców.

Podsumowanie / kluczowe wnioski

Feed FortiGuard AntiVirus Updates to nie ciekawostka, tylko narzędzie operacyjne: pozwala szybko ocenić, czy Twoja infrastruktura nadąża z aktualizacjami definicji AV, a w razie problemów – czy winny jest lokalny kanał aktualizacji czy brak nowych wydań po stronie dostawcy.

Jeżeli zarządzasz FortiGate/FortiClient na większą skalę, potraktuj aktualność AV jak parametr SLO: mierz, alarmuj odchylenia, miej fallback manualny i dbaj o łańcuch zaufania (podpisy/walidacja).


Źródła / bibliografia

  1. FortiGuard AntiVirus Updates (wersja i data publikacji paczki AV). (fortiguard.com)
  2. Fortinet – opis FortiGuard Antivirus Service (zakres, CPRL, AI/ML, integracje z produktami). (Fortinet)
  3. Fortinet Docs – Scheduled updates (FortiGuard). (Fortinet Docs)
  4. Fortinet Docs – Manual updates (ręczne wgrywanie aktualizacji z FDN). (Fortinet Docs)
  5. Fortinet Community – walidacja paczek aktualizacji FortiGuard (podpisy AV/IPS od v7.2.0) + FortiOS integrity checking. (community.fortinet.com)

Dlaczego Hakerzy 'Kochają’ Święta

Jak sezon urlopowy tworzy lukę operacyjną w cyberobronie (i co z tym zrobić)

Święta – dla większości z nas czas odpoczynku i wyciszenia. Dla hakerów? Wręcz przeciwnie – to okres żniw. Cyberprzestępcy dosłownie „kochają” długie weekendy i przerwy świąteczne, bo wtedy czujność obrony jest najniższa. Zespoły bezpieczeństwa (SOC, blue team) pracują często w okrojonym składzie albo pełnią dyżury zdalnie, podczas gdy atakujący nie biorą urlopu. Rezultat?

Czytaj dalej „Dlaczego Hakerzy 'Kochają’ Święta”

Atak ransomware na rumuńską Administrację „Apele Române”: ok. 1000 systemów zaszyfrowanych BitLockerem, infrastruktura OT bez zakłóceń

Wprowadzenie do problemu / definicja luki

W weekend 20–22 grudnia 2025 r. rumuńska państwowa instytucja odpowiedzialna za zarządzanie zasobami wodnymi – Administrația Națională „Apele Române” (Romanian Waters) – potwierdziła incydent typu ransomware, który objął ok. 1000 systemów IT. Mimo dużej skali zakłóceń w warstwie IT, władze podkreślają, że operacyjne technologie (OT) sterujące infrastrukturą wodną nie zostały naruszone, a kluczowe operacje hydrotechniczne są realizowane w trybie ciągłym.

W praktyce to klasyczny przykład kryzysu w infrastrukturze krytycznej, gdzie atak na IT (poczta, serwery, domena, aplikacje) może nie zatrzymać „fizycznego” procesu, ale znacząco utrudnić koordynację, logistykę i odzyskiwanie sprawności.


W skrócie

  • Co się stało: ransomware zaszyfrował ok. 1000 stacji i serwerów w centrali oraz 10 z 11 biur regionalnych.
  • Co ucierpiało: m.in. serwery GIS, bazy danych, poczta, usługi webowe, kontrolery domeny/DNS oraz stacje Windows.
  • Co nie ucierpiało: systemy OT i bieżące działania hydrotechniczne (zapory, zabezpieczenia przeciwpowodziowe, dyspozytornie).
  • Nietypowy element techniczny: sprawcy wykorzystali wbudowany mechanizm Windows BitLocker do szyfrowania („living off the land”), zamiast klasycznego droppera ransomware.
  • Stan na dziś (28.12.2025): śledztwo trwa, brak publicznej atrybucji i brak ujawnionego wektora wejścia.

Kontekst / historia / powiązania

Ataki na podmioty wodno-kanalizacyjne i zarządzające zasobami wodnymi to trend, który w ostatnich latach dotykał wiele państw (zwłaszcza w Europie i USA). Rumuński incydent wyróżnia się jednak dwoma czynnikami:

  1. Skala w warstwie IT (ok. 1000 urządzeń) przy jednoczesnym utrzymaniu procesów fizycznych dzięki procedurom operacyjnym i pracy „w terenie”.
  2. Użycie BitLockera jako narzędzia szyfrującego, co wpisuje się w szerszy wzorzec nadużyć legalnych komponentów systemu (LOLbins), utrudniających wykrycie ataku klasycznymi sygnaturami.

Analiza techniczna / szczegóły incydentu

Co wiemy o zakresie i środowisku

Z komunikatów wynika, że zaszyfrowane/objęte zakłóceniami zostały m.in.:

  • serwery aplikacyjne GIS,
  • serwery bazodanowe,
  • serwery pocztowe i WWW,
  • stacje robocze i serwery Windows,
  • elementy związane z domeną i DNS.

Z punktu widzenia odporności organizacji na incydenty w infrastrukturze krytycznej, szczególnie istotne jest to, że awaria IT wymusiła przejście na kanały alternatywne (np. telefon/radio) w koordynacji działań.

BitLocker jako „ransomware” (LOLbins) – dlaczego to ma znaczenie

Według wstępnych ustaleń śledczych, sprawcy nie musieli wdrażać klasycznego binarnego ransomware, tylko wykorzystali legalny mechanizm szyfrowania dysków BitLocker dostępny w Windows.

To podejście bywa skuteczne, bo:

  • uruchamiane są legalne procesy/narzędzia systemowe (mniej „podejrzanych” artefaktów),
  • część telemetrii może wyglądać jak działania administracyjne,
  • organizacje często mają niejednorodne polityki dot. BitLockera (kto może włączać, gdzie trafiają klucze odzyskiwania, jak wygląda monitoring).

W sprawie pojawiła się też informacja o nocie okupu i żądaniu kontaktu w ciągu 7 dni – standardowy mechanizm presji czasowej w cyberwymuszeniach.

Czego oficjalnie nie ujawniono

Na moment publikacji znanych informacji:

  • brak potwierdzonego wektora wejścia (phishing, VPN, RDP, nadużycie kont uprzywilejowanych itd. – to na razie tylko hipotezy),
  • brak atrybucji do konkretnej grupy.

Praktyczne konsekwencje / ryzyko

Nawet jeśli OT jest nietknięte, incydent tej klasy generuje realne ryzyka operacyjne:

  • Degradacja „układu nerwowego” organizacji: poczta, domena, systemy ewidencyjne, GIS i bazy danych wspierają decyzje operacyjne. Ich niedostępność spowalnia reakcję na zdarzenia (np. gwałtowne opady, wezbrania, awarie).
  • Ryzyko wtórne dla OT: w wielu środowiskach to IT jest „mostem” (tożsamość, zdalny dostęp, aktualizacje). Nawet jeśli dziś OT nie ucierpiało, to słaba segmentacja lub wspólne konta mogą tworzyć ścieżkę eskalacji.
  • Koszt i czas przywracania: użycie BitLockera komplikuje odtwarzanie, jeśli organizacja nie ma spójnego zarządzania kluczami odzyskiwania i procedur wycofania szyfrowania.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „z pola walki”, które mają sens przy scenariuszu szyfrowania BitLockerem w dużej organizacji (zwłaszcza krytycznej):

1) Kontrola szkód i triage

  • Odizoluj zainfekowane segmenty (zwłaszcza tożsamość: AD/AAD), zatrzymaj rozprzestrzenianie (blokady kont, wyłączenie podejrzanych sesji).
  • Zabezpiecz logi i artefakty (kontrolery domeny, EDR, SIEM, serwery zarządzające, urządzenia adminów).

2) BitLocker: odzyskiwanie i prewencja nadużyć

  • Zweryfikuj gdzie są klucze odzyskiwania (AD DS/Azure AD/Intune/MBAM) i czy proces ich wydawania jest kontrolowany.
  • Ogranicz możliwość włączania/zarządzania BitLockerem do wąskiej grupy (GPO/role), monitoruj użycie narzędzi administracyjnych związanych z szyfrowaniem.
  • Wprowadź alerty na nietypowe działania administracyjne (masowe operacje na dyskach, „hurtowe” zmiany polityk, aktywność z kont serwisowych).

3) Odtwarzanie usług IT bez „wciągania” infekcji z powrotem

  • Przywracaj krytyczne usługi warstwowo: tożsamość → DNS/DHCP → komunikacja → aplikacje biznesowe (GIS/bazy).
  • Waliduj backupy (integralność i brak mechanizmu ponownej aktywacji szyfrowania).

4) Długofalowo dla infrastruktury krytycznej

  • Wymuś twardą segmentację IT/OT i kontrolowany, monitorowany dostęp z IT do OT.
  • Opracuj i przetestuj procedury działania „na radiu i telefonie” (jak w tym przypadku) jako formalny tryb degradacji usług.

Różnice / porównania z innymi przypadkami

W porównaniu do „klasycznego” ransomware (gdzie atakujący wdraża własny szyfrator), ten incydent pokazuje rosnącą popularność podejścia LOLBins:

  • Mniej malware, więcej nadużyć narzędzi systemowych (np. BitLocker) → trudniejsze wykrycie oparte na sygnaturach.
  • Potencjalnie szybsze masowe szyfrowanie w środowisku Windows, jeśli napastnik uzyskał uprawnienia domenowe/administracyjne.
  • W literaturze branżowej pojawiały się już opisy kampanii i narzędzi nadużywających BitLockera (np. mechanizmy podobne do „ShrinkLocker”), co sugeruje, że to kierunek, do którego obrońcy muszą dopasować detekcję i polityki.

Podsumowanie / kluczowe wnioski

  • Rumuńska administracja wodna została dotknięta dużym incydentem ransomware w IT (ok. 1000 systemów), ale bez bezpośredniego wpływu na OT i krytyczne operacje.
  • Incydent jest ważnym sygnałem dla sektora infrastruktury krytycznej: utrzymanie procesów fizycznych nie oznacza braku ryzyka – IT bywa kluczowe dla koordynacji i bezpieczeństwa.
  • Użycie BitLockera jako narzędzia wymuszenia wzmacnia potrzebę: twardych polityk uprawnień, monitoringu działań administracyjnych oraz dojrzałego zarządzania kluczami odzyskiwania.

Źródła / bibliografia

  1. Security Affairs – Romanian Waters confirms cyberattack, critical water operations unaffected (22.12.2025). (Security Affairs)
  2. BleepingComputer – Romanian water authority hit by ransomware attack over weekend (22.12.2025). (BleepingComputer)
  3. The Record (Recorded Future News) – Romanian national water agency hit by BitLocker ransomware attack (ok. 22.12.2025). (The Record from Recorded Future)
  4. DNSC (Directoratul Național de Securitate Cibernetică) – komunikat prasowy nt. incydentu ransomware w „Apele Române” (notyfikacja 20.12.2025). (DNSc)
  5. Tom’s Hardware – 1,000 computers taken offline in Romanian water management authority hack… (ok. 23.12.2025). (Tom’s Hardware)

CVE-2025-3232 — Mitsubishi Electric Europe B.V. smartRTU

TL;DR

  • CVE-2025-3232 dotyczy Mitsubishi Electric Europe B.V. smartRTU (≤ 3.37) i polega na braku uwierzytelnienia dla krytycznej funkcji (CWE-306) – w praktyce zdalny, nieuwierzytelniony atakujący może obejść kontrolę dostępu i przez konkretną trasę API doprowadzić do wykonania poleceń systemu operacyjnego.
  • Ocena ryzyka (CNA/ICS-CERT): CVSS v3.1 7.5 (HIGH); NVD pokazuje też CVSS v4 8.7 (HIGH) (ocena NVD “not yet provided”, widoczna jest ocena CNA).
  • To część pakietu problemów w smartRTU opisanego w ICSA-25-105-09 – obok CVE-2025-3128 (CWE-78, OS Command Injection, CVSS 9.8), który bywa opisywany jako kolejny krok po obejściu uwierzytelnienia.
  • Najważniejsze działania defensywne (kompensacyjne): zdejmij ekspozycję z Internetu, ogranicz dostęp do zaufanych sieci, stosuj VPN / firewall, a jeśli HTTP/HTTPS musi być wystawione – rozważ WAF.
  • W materiałach CISA/CSAF (ICSA-25-105-09) wskazano, że nie było raportów o publicznie znanej exploitacji ukierunkowanej na tę podatność (stan na publikację/rewizję advisory).

Krótka definicja techniczna

CVE-2025-3232 to podatność typu Missing Authentication for Critical Function (CWE-306) w smartRTU (≤ 3.37), umożliwiająca atakującemu z sieci wywołanie wrażliwej funkcji przez określoną trasę API bez poprawnego uwierzytelnienia, co według opisu CVE może skutkować wykonaniem dowolnych poleceń OS (impact wg CVSS: Integrity = High). W kontekście MITRE ATT&CK (ICS) najbliższe mapowanie to T0819 Exploit Public-Facing Application (Initial Access), często w praktyce łączone też z T0866 Exploitation of Remote Services oraz wykonaniem komend po przejęciu kontekstu (np. T0807 Command-Line Interface).


Gdzie występuje / przykłady platform

  • ICS/OT: smartRTU (urządzenie/komponent RTU używany w środowiskach przemysłowych, zwykle z interfejsem web/API do zarządzania).
  • Windows: pośrednio (stacje inżynierskie/HMI/jump hosty, z których administruje się smartRTU) – przydatne do korelacji EDR/SIEM.
  • AD: zwykle nie dotyczy bezpośrednio (chyba że integracja/SSO w warstwie IT).
  • AWS / Azure / GCP: nie dotyczy samej podatności, ale może dotyczyć ekspozycji (np. reverse proxy/WAF w chmurze).
  • K8s: nie dotyczy.
  • ESXi: nie dotyczy.
  • M365: nie dotyczy.

Szczegółowy opis techniki

Jak to działa (perspektywa defensywna)

W smartRTU istnieje funkcjonalność dostępna przez interfejs web/API, która powinna być chroniona uwierzytelnieniem/autoryzacją. W przypadku CVE-2025-3232 mechanizm ten jest niewystarczający: krytyczna funkcja (wywoływana przez “specific API route”) może zostać uruchomiona bez poprawnej autentykacji, co według opisu CVE prowadzi do wykonania poleceń OS.

Cele atakującego

W OT/ICS taki wektor wejścia jest atrakcyjny, bo:

  • daje zdalny foothold na urządzeniu brzegowym (RTU), często stojącym na styku sieci (telemetria, zdalne zarządzanie),
  • może umożliwić manipulację konfiguracją, “tampering” oraz potencjalnie przygotowanie gruntu pod kolejne kroki (ruch boczny, zmiana parametrów, sabotaż).

Dlaczego jest skuteczna

  • Brak wymogu poświadczeń (PR:N) i niska złożoność (AC:L) w CVSS oznacza, że przy złej ekspozycji (Internet / nieufne segmenty) ryzyko operacyjne szybko rośnie.
  • OT często ma ograniczony telemetry/EDR na urządzeniach embedded, więc “signal” detekcyjny bywa głównie sieciowy (FW/WAF/IDS) i z elementów pośredniczących.

Artefakty i logi

Źródło / warstwaEID (Windows)CloudTrail eventsK8s auditM365 operationsCo warto zbierać / na co patrzeć
Dostęp do interfejsu web/API smartRTUN/AN/AN/AN/ALogi HTTP (reverse proxy/WAF), metoda POST/PUT/DELETE, nietypowe URI, skoki 4xx/5xx, nietypowe UA, duże payloady
Firewall / IDS/IPSN/AN/AN/AN/AInbound do panelu zarządzania (80/443 lub inne), źródła spoza allowlist, skanowanie, bursty requestów
Host/EDR na stacji inżynierskiej/jump hoście (jeśli zarządzanie z Windows)4688, 4625/4624 (korelacje logowań)N/AN/AN/ANietypowe procesy uruchomione w kontekście narzędzi admin/remote, “helper tools”, nowe połączenia sieciowe do RTU
Telemetria z urządzenia (jeśli dostępna)N/AN/AN/AN/ASyslog/audit (o ile jest), historia poleceń, zmiany konfiguracji, restarty usług/urządzenia
WAF (jeśli publikujesz web)N/A(raczej) N/AN/AN/AReguły blokujące nietypowe requesty, anomalie w parametrach i nagłówkach; korelacja z ruchem zewnętrznym

Detekcja (praktyczne reguły)

Uwaga praktyczna: w OT często nie masz idealnych logów “z urządzenia”. Dlatego poniżej są reguły, które da się zastosować w warstwie pośredniej (WAF/reverse proxy) albo na hostach, które zbierają procesy (EDR). Nie używam tu żadnych “kroków exploitacji” ani nie podaję konkretnej trasy API – bo publiczne advisory mówi tylko o “specific API route”.

Sigma (gotowa reguła)

title: Possible Web/API Triggered OS Command Execution via Web Server Parent (smartRTU / CVE-2025-3232 context)
id: 3b2b8e3a-3c3d-4d6a-9d7a-1f6b62b8d6c1
status: experimental
description: |
  Detects suspicious shell/process execution spawned by common embedded/web server processes.
  Useful as compensating detection for scenarios where an unauthenticated API route may lead to OS command execution
  (e.g., smartRTU CVE-2025-3232 and related chains).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2025-3232
  - https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/OT/white/2025/icsa-25-105-09.json
author: "Badacz CVE (SOC/Blue Team)"
date: 2025/12/25
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
logsource:
  category: process_creation
  product: linux
detection:
  parent_websrv:
    ParentImage|endswith:
      - /nginx
      - /apache2
      - /httpd
      - /lighttpd
      - /uhttpd
      - /boa
  child_shell:
    Image|endswith:
      - /sh
      - /bash
      - /ash
      - /busybox
  cmd_susp:
    CommandLine|contains:
      - " -c "
      - "wget "
      - "curl "
      - "nc "
      - "mkfifo "
      - "/dev/tcp/"
  condition: parent_websrv and (child_shell or cmd_susp)
falsepositives:
  - Legitimate CGI scripts or admin maintenance jobs that spawn shells from web services
  - Firmware update routines implemented via web backend
level: high

Splunk (SPL)

Wariant A – proxy/WAF access logs (szukamy nieautoryzowanych prób do panelu/API):

index=net* (sourcetype=nginx:access OR sourcetype=apache:access OR sourcetype=waf)
dest_port IN (80,443)
| eval uri=coalesce(uri_path, uri, request)
| search http_method IN ("POST","PUT","DELETE") OR like(uri,"%api%")
| where NOT cidrmatch("10.0.0.0/8", src_ip) AND NOT cidrmatch("192.168.0.0/16", src_ip)
| stats count min(_time) as firstSeen max(_time) as lastSeen values(http_method) values(status) values(uri) by src_ip dest_ip
| sort -count

Wariant B – EDR/host telemetry (webserver → shell):

index=edr* sourcetype=process*
| where (parent_process_name IN ("nginx","httpd","apache2","lighttpd","uhttpd","boa"))
| where (process_name IN ("sh","bash","ash","busybox") OR like(process_command_line,"% -c %"))
| stats count min(_time) max(_time) values(process_command_line) by host user parent_process_name process_name
| sort -count

KQL (Azure)

Defender for Endpoint (jeśli masz DeviceProcessEvents z hostów/jump hostów):

DeviceProcessEvents
| where InitiatingProcessFileName in~ ("nginx","httpd","apache2","lighttpd","uhttpd","boa")
| where FileName in~ ("sh","bash","ash","busybox") or ProcessCommandLine has " -c "
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp desc

Azure WAF / App Gateway (jeśli smartRTU stoi za takim frontem):

AzureDiagnostics
| where Category has "ApplicationGatewayFirewallLog"
| where action_s == "Blocked" or ruleSetType_s =~ "OWASP"
| project TimeGenerated, clientIp_s, requestUri_s, requestMethod_s, message_s, ruleId_s
| order by TimeGenerated desc

CloudTrail query (AWS CLI/CloudWatch)

CloudTrail nie loguje ruchu HTTP do smartRTU (to nie są wywołania AWS API). Jeżeli jednak wystawiasz smartRTU przez AWS WAF/ALB, sensowniejsze jest pytanie CloudWatch Logs Insights na logach WAF:

fields @timestamp, httpRequest.clientIp as srcIp, httpRequest.httpMethod as method, httpRequest.uri as uri, action, terminatingRuleId
| filter method in ["POST","PUT","DELETE"] or uri like /api/
| stats count() as hits, min(@timestamp) as firstSeen, max(@timestamp) as lastSeen by srcIp, method, uri, action
| sort hits desc

Elastic/EQL przykłady

process
where host.os.type == "linux"
  and process.parent.name in ("nginx","httpd","apache2","lighttpd","uhttpd","boa")
  and (
    process.name in ("sh","bash","ash","busybox")
    or process.command_line like "* -c *"
  )

Heurystyki / korelacje

  1. Ruch sieciowy → objaw na hoście: burst requestów HTTP/HTTPS do interfejsu zarządzania + w krótkim oknie czasowym proces potomny typu shell (jeśli masz telemetrię).
  2. Źródło spoza polityki dostępu: jakikolwiek request do panelu/API smartRTU z IP spoza allowlist (VPN/management VLAN).
  3. Zmiany konfiguracyjne / restarty: anomalia w dostępności RTU, restart usług, zmiany parametrów – skorelowane czasowo z nietypowym ruchem do web/API.
  4. Skanowanie: rozproszony ruch do portów zarządczych (80/443) poprzedzający właściwe wywołania.

False positives / tuning

  • Legalna administracja potrafi wyglądać “podejrzanie”, jeśli:
    • admin używa narzędzi automatyzujących (API),
    • są wykonywane update’y/backup/diagnostyka z panelu (może generować wywołania typu POST).
  • Tuning praktyczny:
    • twarda allowlista źródeł (VPN, jump hosty, sieci adminów),
    • baseline “normalnych” URI i metod HTTP,
    • korelacja z oknami serwisowymi (maintenance windows),
    • w EDR: allowlist legalnych skryptów/agentów, które realnie mogą startować shell (jeśli to w ogóle dopuszczalne w Twoim środowisku).

Playbook reagowania (kroki + komendy)

1) Identyfikacja i triage

  • Zrób inventory: gdzie stoi smartRTU i czy wersja jest ≤ 3.37 (to zakres “known affected” w advisory).
  • Sprawdź ekspozycję: czy panel zarządzania jest dostępny z Internetu albo z segmentów nie-OT.

2) Natychmiastowe ograniczenie ekspozycji (kompensacja)

Zgodnie z zaleceniami w advisory:

  • wymuś VPN / firewall przy dostępie zdalnym,
  • ogranicz do LAN i blokuj sieci nieufne,
  • jeśli HTTP/HTTPS musi działać – postaw WAF i ogranicz web client access do zaufanych sieci.

Przykład (Linux firewall na reverse proxy – tylko allowlista):

# tylko przykład – dopasuj interfejs/port
sudo iptables -A INPUT -p tcp --dport 443 -s <TRUSTED_ADMIN_SUBNET_CIDR> -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j DROP

3) Polowanie (hunting)

  • Szukaj anomalii w:
    • logach WAF/proxy: nietypowe metody, częste 4xx/5xx, requesty spoza allowlist,
    • FW/IDS: ruch do portów zarządczych z “dziwnych” źródeł,
    • EDR: webserver → shell (jeśli masz).

4) Jeśli podejrzenie kompromitacji

  • Odizoluj urządzenie od sieci produkcyjnej (w OT zawsze z oceną wpływu na proces).
  • Zabezpiecz logi i artefakty z elementów pośrednich (WAF/FW/jump host).
  • Rotuj hasła/poświadczenia powiązane z dostępem administracyjnym i kanałami zdalnymi.
  • Rozważ kontrolę integralności konfiguracji (co się zmieniło i kiedy).

Przykłady z kampanii / case studies

  • Publiczne materiały dla smartRTU (ICSA-25-105-09 w formacie CSAF) wskazują, że raportującym był Claroty Team82 (w acknowledgments), a w sekcji “Recommended Practices” pada stwierdzenie o braku znanej publicznej exploitacji ukierunkowanej na tę podatność (na moment publikacji/rewizji).

Lab (bezpieczne testy) — przykładowe komendy

Tylko w odseparowanym labie OT (VLAN/lab), za zgodą właściciela środowiska. Celem jest walidacja ekspozycji i detekcji, nie test exploitów.

Test 1: czy urządzenie/panel jest wystawiony tam, gdzie nie powinien

# skan usług (wersje) – tylko własna sieć/lab
nmap -sV -p 80,443 <SMART_RTU_IP>

Test 2: szybka walidacja kontroli dostępu (bez exploitacji)

# sprawdzenie odpowiedzi HTTP nagłówkami (bez “payloadów”)
curl -kI https://<SMART_RTU_IP>/

Test 3: walidacja segmentacji (czy blokuje z nieufnego segmentu)

# próba zestawienia TCP z sieci, która NIE powinna mieć dostępu
nc -vz <SMART_RTU_IP> 443

Test 4: test reguły “webserver → shell” na hostach (symulacja benign)

Na hoście testowym (reverse proxy / lab VM) uruchom kontrolowany łańcuch procesów, żeby sprawdzić czy SIEM/EDR zareaguje:

# benign: tworzy plik, ale generuje charakterystyczny wzorzec "shell -c"
sudo -u www-data /bin/sh -c 'echo healthcheck > /tmp/web-child-test'

Mapowania (Mitigations, Powiązane techniki)

MITRE ATT&CK (ICS) – techniki

  • T0819 – Exploit Public-Facing Application (Initial Access)
  • T0866 – Exploitation of Remote Services (Initial Access, Lateral Movement)
  • T0807 – Command-Line Interface (Execution)

MITRE – przykładowe mitigacje dla T0819 (ICS)

Z karty T0819 jako szczególnie sensowne dla smartRTU:

  • M0950 Exploit Protection (np. WAF)
  • M0930 Network Segmentation (DMZ/segmentacja usług wystawionych)
  • M0948 Application Isolation and Sandboxing (ograniczenie skutków exploitacji)
  • M0926 Privileged Account Management (least privilege, kontrola kont uprzywilejowanych)

Powiązane konteksty podatności

  • CWE-306 (Missing Authentication for Critical Function) dla CVE-2025-3232
  • W tym samym advisory: CVE-2025-3128 (CWE-78, OS Command Injection) – często istotne w analizie łańcucha.

Źródła / dalsza literatura

  • NVD: CVE-2025-3232 (opis, CVSS, CWE, daty publikacji) (NVD)
  • CISA CSAF: ICSA-25-105-09 JSON (zakres wersji ≤3.37, mitigacje, kontekst, “no known public exploitation…”) (GitHub)
  • Mitsubishi Electric Europe: raport PSIRT MEU_PSIRT_2025-3128 (pakiet podatności dla smartRTU) (MITSUBISHI ELECTRIC Europe)
  • Claroty disclosure dashboard dla CVE-2025-3232 (zalecenia mitigacyjne w punktach)
  • MITRE ATT&CK (ICS): T0819, T0866, T0807 (MITRE ATT&CK)

Checklisty dla SOC / CISO

SOC (operacyjnie)

  • Znajdź wszystkie instancje smartRTU i potwierdź wersje (szczególnie ≤ 3.37).
  • Zweryfikuj ekspozycję: czy panel/API nie jest dostępny z Internetu.
  • Włącz logowanie i korelacje na FW/WAF/proxy (źródło IP, URI, metody, statusy).
  • Dodaj reguły “webserver → shell” (jeśli masz telemetrię procesów).
  • Ustal allowlistę źródeł administracyjnych i alertuj na odchylenia.

CISO / właściciel ryzyka

  • Wymuś model dostępu: VPN + jump host + segmentacja (zamiast bezpośredniej ekspozycji).
  • Zdefiniuj kompensacje (WAF, ACL, DMZ) i plan ciągłości działania OT.
  • Oceń ryzyko łańcucha z CVE-2025-3128 (jeśli dotyczy Twojego wdrożenia).
  • Ustal progi eskalacji (kiedy izolujemy RTU, kiedy zatrzymujemy zdalne zarządzanie).

Ransomware u dostawcy NHS England: co wiemy o incydencie DXS International i dlaczego to ważne dla łańcucha dostaw ochrony zdrowia

Wprowadzenie do problemu / definicja luki

Incydent u DXS International – partnera technologicznego współpracującego z NHS England – to kolejny przykład, jak ransomware „obchodzi” dobrze bronione organizacje publiczne, uderzając w ich dostawców. W praktyce nie chodzi wyłącznie o zaszyfrowanie serwerów. Współczesne kampanie ransomware coraz częściej łączą sabotaż dostępności (szyfrowanie) z presją informacyjną (kradzież danych i groźba publikacji), a to w sektorze zdrowia ma szczególną wagę.

W przypadku DXS mowa o „security incident” dotyczącej serwerów biurowych (office servers), a nie – przynajmniej na tym etapie – o systemach klinicznych. To ważne rozróżnienie, bo nawet jeśli „front-line clinical services” pozostają operacyjne, to skutki uboczne mogą dotyczyć danych, tożsamości, procesów i bezpieczeństwa łańcucha dostaw.


W skrócie

  • Kiedy wykryto incydent: we wczesnych godzinach 14 grudnia 2025.
  • Co zaatakowano: serwery biurowe DXS (office servers).
  • Wpływ na usługi: DXS deklaruje „minimal impact”, a usługi kliniczne mają pozostać niezakłócone.
  • Kwestia wycieku danych: DXS nie potwierdza kradzieży, natomiast grupa ransomware DevMan twierdzi, że wykradła ok. 300 GB danych.
  • Działania po incydencie: współpraca z NHS England, powołanie zewnętrznych ekspertów cyber, zgłoszenia do organów (w tym ICO).
  • Aktualizacja (24 grudnia 2025): incydent ma być „contained”, a DXS wdraża dodatkowy monitoring i środki bezpieczeństwa.

Kontekst / historia / powiązania

DXS International dostarcza rozwiązania IT dla środowiska ochrony zdrowia w Anglii. Z perspektywy ryzyka cyber kluczowe są dwa elementy:

  1. Powiązanie operacyjne z NHS – incydenty u dostawców szybko przechodzą w kryzys reputacyjny (i potencjalnie regulacyjny), nawet jeśli nie ma dowodów wpływu na pacjentów.
  2. Ryzyko systemowe łańcucha dostaw – atakujący często wybierają dostawcę, bo ma słabszą „higienę” bezpieczeństwa, a jednocześnie dostęp (bezpośredni lub pośredni) do środowisk o wysokiej wartości.

W tym samym ekosystemie NHS głośnym punktem odniesienia pozostaje sprawa Advanced Computer Software Group (atak ransomware z 2022 r.), która zakończyła się karą finansową ICO w wysokości £3,076,320 za uchybienia w zabezpieczeniach. To tło jest istotne, bo pokazuje, że w UK regulator coraz bardziej „dociąża” odpowiedzialność dostawców przetwarzających dane w imieniu innych podmiotów.


Analiza techniczna / szczegóły luki

1) Co wiemy technicznie (i czego nie wiemy)

Publicznie ujawnione informacje są ograniczone:

  • DXS mówi o incydencie bezpieczeństwa dotykającym serwery biurowe i o tym, że zdarzenie szybko „contained” we współpracy z NHS England.
  • Nie ma informacji o wektorze wejścia (phishing, RDP/VPN, exploit podatności, kompromitacja konta, dostawca zewnętrzny itp.), ani o tym, czy doszło do ruchu lateralnego do innych segmentów sieci.
  • Nie ma potwierdzenia eksfiltracji, ale jest roszczenie grupy DevMan o kradzież 300 GB danych (typowa narracja „double extortion”).

2) Co oznacza „office servers” w realnym ataku ransomware

„Serwery biurowe” to często: domena/AD, pliki, poczta, systemy finansowe/HR, repozytoria dokumentów, narzędzia zdalnego wsparcia, systemy ticketowe i kopie raportów/wyciągów z systemów produkcyjnych. Z punktu widzenia napastnika to idealny zestaw do:

  • przejęcia tożsamości (hasła, tokeny, SSO),
  • przygotowania ataków wtórnych (phishing z wiarygodnej infrastruktury),
  • pozyskania danych do szantażu,
  • „przygotowania gruntu” pod eskalację do bardziej wrażliwych zasobów.

3) Podłoże supply-chain: sieci i integracje

W materiałach o sprawie pojawia się istotny trop: DXS wskazuje (za opisami zewnętrznymi), że część rozwiązań bywa hostowana w Health and Social Care Network (HSCN) – infrastrukturze łączącej organizacje ochrony zdrowia w UK. To nie jest automatyczny dowód kompromitacji HSCN, ale podnosi wagę dochodzenia: trzeba jednoznacznie ustalić granice segmentacji, zaufania i kanałów integracyjnych.


Praktyczne konsekwencje / ryzyko

Nawet jeśli usługi kliniczne nie zostały przerwane, ryzyka praktyczne dzielą się na kilka kategorii:

  1. Ryzyko ujawnienia danych
    Jeśli twierdzenie DevMan o 300 GB eksfiltracji jest prawdziwe, w grę wchodzą: dokumenty wewnętrzne, umowy, dane pracowników, dane klientów/kontrahentów, korespondencja i potencjalnie artefakty zawierające dane wrażliwe (czasem „przypadkowo” zrzucane na share’y biurowe). Na dziś jest to niepotwierdzone – ale w modelu ransomware to standardowy etap presji.
  2. Ryzyko wtórnych kompromitacji (w tym BEC i phishing)
    Atakujący, mając dostęp do skrzynek i dokumentów, mogą prowadzić bardzo wiarygodne oszustwa: podszywanie się pod dostawcę, zmiany numerów kont, „pilne faktury”, prośby o reset haseł, żądania udostępnienia plików. W ochronie zdrowia to szczególnie groźne, bo komunikacja jest szybka i wielokanałowa.
  3. Ryzyko regulacyjne i kontraktowe
    DXS zgłosił sprawę do właściwych organów, w tym do ICO. W UK regulator ma już świeży precedens pokazujący, że konsekwencje finansowe i reputacyjne mogą być realne także dla podmiotów przetwarzających dane w imieniu innych organizacji.
  4. Ryzyko operacyjne (ukryte koszty)
    „Minimal impact” nie oznacza „brak kosztów”. Do standardowych kosztów dochodzą: IR/forensics, odtwarzanie, hardening, monitoring, obsługa prawna, komunikacja, potencjalne zawiadomienia, a czasem przebudowa architektury tożsamości i dostępu. DXS w komunikacie giełdowym wskazuje, że nie spodziewa się „material adverse impact” na finanse, ale to sformułowanie ma charakter rynkowy – nie zastępuje pełnej oceny ryzyka.

Rekomendacje operacyjne / co zrobić teraz

Poniższa lista jest praktyczna zarówno dla dostawców NHS, jak i organizacji korzystających z usług takich firm.

1) Jeśli jesteś dostawcą (vendor) – priorytet „weryfikacja granic”

  • Potwierdź zakres kompromitacji: konta uprzywilejowane, AD, systemy zdalnego dostępu, narzędzia RMM, VPN, IdP/SSO.
  • Odtwórz oś czasu: pierwsze wejście, eskalacja uprawnień, ruch boczny, staging danych, szyfrowanie.
  • Zweryfikuj segmentację między „office IT” a środowiskami dotykającymi integracji z NHS (w tym ewentualnie HSCN).

2) Podwójne wymuszenie: traktuj roszczenie o wyciek poważnie

  • Monitoruj leak-site i ekosystem (ale nie zakładaj automatycznie prawdziwości roszczeń).
  • Przygotuj playbook pod publikację próbek danych (weryfikacja, triage, powiadomienia).
  • Zabezpiecz dowody na potrzeby postępowania i regulatora.

3) Kontrole techniczne „minimum sensowne” w 2025+

  • MFA wszędzie, zwłaszcza do zdalnego dostępu, poczty, paneli administracyjnych i narzędzi wsparcia.
  • PAM / JIT / JEA dla adminów, rozdział ról, rotacja sekretów, ograniczenie stałych uprawnień.
  • Niezmienialne kopie zapasowe (immutable/offline) + testy odtwarzania (nie tylko backup, ale realny RTO/RPO).
  • EDR + centralny logging (SIEM) z detekcjami pod: masowe zmiany plików, archiwizacje, narzędzia do eksfiltracji, anomalie tożsamości.
  • Hardening poczty (DMARC/DKIM/SPF), bo po incydencie rośnie ryzyko BEC i phishingu.

4) Jeśli jesteś klientem (np. jednostką ochrony zdrowia) – ogranicz „blast radius”

  • Wymagaj od dostawcy konkretnych artefaktów: wstępny raport IR, IOC/TTP (w zakresie możliwym), potwierdzenie rotacji kluczy/tokenów, status segmentacji.
  • Oceń, czy istnieją połączenia zaufane (VPN/site-to-site, integracje API, konta serwisowe) i rozważ ich czasowe ograniczenie/rotację.
  • Podnieś czujność SOC/Helpdesk na oszustwa fakturowe i podszycia po stronie dostawcy.

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

DXS (2025) vs. Advanced (2022 → kara w 2025)

  • DXS: na dziś komunikacja mówi o ograniczonym wpływie na usługi kliniczne i incydencie na serwerach biurowych, przy jednoczesnym braku potwierdzenia wycieku (mimo roszczeń napastników).
  • Advanced: sprawa zakończyła się realną karą ICO w 2025 r., co wzmacnia przekaz: dostawcy, którzy „tylko przetwarzają”, również mogą ponosić istotne konsekwencje za niedostateczne środki bezpieczeństwa.

Wniosek praktyczny: w środowisku NHS liczy się nie tylko „czy pacjenci odczuli przerwę”, ale też czy kontrolujesz ryzyko danych i tożsamości w całym łańcuchu.


Podsumowanie / kluczowe wnioski

  • Incydent DXS został wykryty 14 grudnia 2025, zgłoszony rynkowo 18 grudnia, a 24 grudnia spółka podała, że sytuacja jest opanowana i wdraża dodatkowe zabezpieczenia.
  • DXS nie potwierdza kradzieży danych, ale grupa DevMan rości sobie eksfiltrację ~300 GB – klasyczny element presji w ransomware.
  • Nawet przy braku przestoju klinicznego ryzyko pozostaje wysokie: wyciek danych, phishing wtórny, ryzyka kontraktowe i regulator.
  • W tle widać trend: dostawcy usług publicznych (w tym dla ochrony zdrowia) są coraz częściej celem, a regulator ma precedensy egzekwowania odpowiedzialności finansowej.

Źródła / bibliografia

  1. DXS International plc – Notice of Cyber Security Incident (18.12.2025). (GlobeNewswire)
  2. DXS International plc – Update on Cyber Security Incident (24.12.2025). (GlobeNewswire)
  3. TechCrunch – Tech provider for NHS England confirms data breach (18.12.2025). (TechCrunch)
  4. TechRadar – NHS England tech provider reveals data breach – DXS International hit by ransomware (22.12.2025). (TechRadar)
  5. ICO – Software provider fined £3m following 2022 ransomware attack (27.03.2025). (ICO)

Atak ransomware na rumuńską administrację wodną „Apele Române” (ANAR): ~1000 systemów zaszyfrowanych z użyciem BitLockera

Wprowadzenie do problemu / definicja luki

W weekend 20–22 grudnia 2025 rumuńska Administrația Națională „Apele Române” (ANAR) – instytucja odpowiedzialna za zarządzanie zasobami wodnymi i infrastrukturą hydrotechniczną – potwierdziła incydent typu ransomware, który dotknął ok. 1000 systemów IT w centrali i w niemal wszystkich strukturach regionalnych.

Kluczowy element tej sprawy: zamiast „klasycznego” szyfratora przestępcy mieli nadużyć natywnego mechanizmu Windows – BitLockera – aby zablokować dostęp do danych i wymusić kontakt w sprawie okupu.


W skrócie

  • Kiedy: incydent zgłoszony/ujawniony po 20 grudnia 2025 (atak rozpoczął się 20.12).
  • Skala: ok. 1000 zaszyfrowanych/wyłączonych systemów (m.in. serwery GIS, bazy danych, poczta, WWW, stacje robocze, DNS).
  • Wpływ na OT: według komunikatów systemy operacyjne (OT) i obiekty hydrotechniczne nie ucierpiały, a praca dyspozytorska była prowadzona kanałami głosowymi (telefon/radio).
  • Wymuszenie: pozostawiono notę z żądaniem kontaktu w ciągu 7 dni.
  • Śledztwo: rumuńska DIICOT wszczęła postępowanie „in rem” (na czyn, bez wskazania sprawcy).

Kontekst / historia / powiązania

Ataki na podmioty infrastruktury krytycznej mają zwykle dwa cele: szybkie wymuszenie (okup/downtime) oraz długoterminowe podważenie zaufania do państwa i usług publicznych. W tym przypadku dodatkowym „sygnałem ostrzegawczym” jest to, że choć OT miało pozostać nietknięte, paraliż IT uderza w elementy wspierające: mapowanie zasobów (GIS), raportowanie, komunikację, analitykę i zarządzanie incydentami.

W publicznych doniesieniach nie wskazano sprawcy ani wektora wejścia (na moment publikacji materiałów źródłowych).


Analiza techniczna / szczegóły luki

1) „Ransomware” bez typowego szyfratora: BitLocker jako narzędzie wymuszenia

Wg informacji przekazywanych przez media na podstawie ocen technicznych po stronie rumuńskich instytucji, atakujący użyli legalnego składnika Windows (BitLocker), by zaszyfrować zasoby i wymusić okup. To podejście wpisuje się w trend „living-off-the-land” (LOLBins): zamiast wprowadzać własny binarny szyfrator, przestępca wykorzystuje wbudowane narzędzia systemu, co może utrudniać detekcję opartą wyłącznie o sygnatury.

2) Co to implikuje z punktu widzenia uprawnień?

Żeby masowo „odwrócić” BitLockera przeciw organizacji, atakujący zwykle muszą osiągnąć wysoki poziom uprawnień (administrator lokalny/domenowy) oraz kontrolę nad mechanizmami zarządzania stacjami/serwerami (np. domena, polityki, narzędzia dystrybucji). To nie jest dowód na konkretną ścieżkę ataku, ale praktyczna konsekwencja samej metody.

3) Jakie systemy były dotknięte?

W publikowanych opisach pojawiają się m.in.: serwery aplikacji GIS, bazy danych, serwery poczty i WWW, stacje robocze Windows, serwery Windows oraz serwery DNS.
Warto podkreślić, że właśnie GIS w administracji wodnej to „mózg sytuacyjny” (warstwy map, obiekty hydrotechniczne, dane o ryzykach) – jego utrata znacząco komplikuje pracę operacyjną, nawet jeśli urządzenia OT działają lokalnie.


Praktyczne konsekwencje / ryzyko

  1. Długotrwały przestój i praca w trybie degradacji – przejście na telefon/radio to sposób na utrzymanie ciągłości, ale równocześnie obniża „przepustowość” procesów i zwiększa ryzyko błędów.
  2. Ryzyko eskalacji do OT (pośrednio) – nawet jeśli OT nie zostało naruszone, to kompromitacja IT bywa punktem startowym do późniejszych prób wejścia w sieci przemysłowe.
  3. Niepewność dot. wycieku danych – w dostępnych opisach nacisk położono na szyfrowanie i przywracanie usług; brak publicznego potwierdzenia eksfiltracji nie oznacza, że jej nie było (to typowy obszar do weryfikacji w IR).
  4. Presja negocjacyjna – nota z żądaniem kontaktu w 7 dni to standardowy mechanizm eskalacji presji czasowej na ofierze.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „bezpiecznych do wdrożenia” i przydatnych również w organizacjach spoza sektora wodnego:

1) Priorytet: odzyskanie kontroli nad tożsamością i zarządzaniem

  • sprawdź integralność AD / Entra ID, kont uprzywilejowanych i narzędzi zdalnego zarządzania,
  • wymuś rotację haseł/kluczy na kontach admin i serwisowych, zacznij od tych z dostępem do GPO/zarządzania urządzeniami.

2) BitLocker w trybie „defensywnym”

  • upewnij się, że klucze odzyskiwania są centralnie escrowowane (i że dostęp do nich jest ściśle kontrolowany),
  • monitoruj zdarzenia związane z masowymi zmianami stanu szyfrowania oraz „nietypową” aktywnością administracyjną na wielu hostach naraz (korelacja w SIEM).

3) Segmentacja i granice zaufania IT/OT

  • odseparuj stacje biurowe od sieci sterowania,
  • wymuś jednokierunkowe przepływy danych tam, gdzie to możliwe (np. strefy DMZ dla danych raportowych).

4) Backup i odtwarzanie (realne, nie „na papierze”)

  • testuj odtwarzanie całych usług (DB + aplikacja + uprawnienia), nie tylko plików,
  • trzymaj kopie offline/niemodyfikowalne (ochrona przed sabotażem kopii).

5) Gotowość na wariant „double extortion”

  • przygotuj plan komunikacji kryzysowej i analizę danych wrażliwych,
  • traktuj telemetrykę sieciową (proxy, DNS, EDR) jako źródło prawdy o ewentualnym wycieku.

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

W tej sprawie wyróżnia się mechanizm szyfrowania: BitLocker jako „legalny” komponent Windows. Takie podejście bywa postrzegane jako mniej „hałaśliwe” (bo nie wprowadza typowego payloadu ransomware), ale nadal wymaga głębokiej kontroli nad środowiskiem i zwykle zostawia ślady w logach administracyjnych.

Drugi wyróżnik to relatywnie klarowna separacja komunikacyjna: w doniesieniach konsekwentnie podkreślano, że OT/hydrotechnika działa, a instytucja przeszła na tryb pracy dyspozytorskiej przez kanały głosowe.


Podsumowanie / kluczowe wnioski

  • Atak na „Apele Române” pokazuje, że ransomware nie musi oznaczać klasycznego szyfratora – nadużycie BitLockera jest wystarczające, by sparaliżować organizację.
  • Skala (~1000 systemów) i objęcie struktur regionalnych sugerują problem systemowy: tożsamość, uprawnienia i zarządzanie flotą są dziś główną „dźwignią” napastnika.
  • Nawet jeśli OT pozostaje bezpośrednio nietknięte, utrata IT uderza w świadomość sytuacyjną (GIS), komunikację i procesy decyzyjne.

Źródła / bibliografia

  1. TechRadar – opis incydentu, zakres systemów, informacja o BitLocker i nocie okupu (23.12.2025). (TechRadar)
  2. BleepingComputer – dodatkowe szczegóły dot. dotkniętych usług i trybu działania operacyjnego (22.12.2025). (BleepingComputer)
  3. The Record (Recorded Future News) – kontekst „LOLBins” i BitLocker jako metoda wymuszenia (22.12.2025). (The Record from Recorded Future)
  4. The Register – uzupełniające informacje o skali i rekomendacjach dot. negocjacji (22.12.2025). (The Register)
  5. Europa Liberă România (RFE/RL) – informacje o postępowaniu DIICOT i wyjaśnienie roli GIS oraz statusu OT (21–22.12.2025). (Europa Liberă România)

CVE-2025-14733 (WatchGuard Fireware OS / Firebox)

TL;DR

  • Co to jest: krytyczne RCE bez uwierzytelnienia (out-of-bounds write / CWE-787) w procesie iked w WatchGuard Fireware OS.
  • Kiedy boli najbardziej: gdy Firebox ma włączone IKEv2 VPN (Mobile User VPN IKEv2 oraz BOVPN IKEv2 z dynamic gateway peer).
  • Wersje podatne (wg NVD): Fireware OS 11.10.2–11.12.4_Update1, 12.0–12.11.5, 2025.1–2025.1.3.
  • Fixy (wg WatchGuard): 2025.1.4, 12.11.6, 12.5.15 (T15/T35), 12.3.1_Update4 (FIPS); 11.x = EoL.
  • Status operacyjny: WatchGuard potwierdza aktywne próby eksploatacji, a NVD odnotowuje dodanie do KEV (terminy dla FCEB w USA wg wpisu w NVD).
  • Mapowanie ATT&CK: T1190 – Exploit Public-Facing Application (taktika: Initial Access, v2.8, Last Modified 24 Oct 2025).
  • Co robić teraz: patch/upgrade, zawężenie ekspozycji UDP 500/4500 (tylko znane peer’y), hunting po logach iked (CERT > 2000, chain > 8), rotacja sekretów po IoA/IOC.

Krótka definicja techniczna

T1190 (Exploit Public-Facing Application) opisuje scenariusz, w którym atakujący wykorzystuje błąd w usłudze wystawionej do Internetu, aby uzyskać initial access; CVE-2025-14733 to praktyczny przykład tej techniki na urządzeniu brzegowym (WatchGuard Firebox), gdzie podatność w IKEv2 (iked) umożliwia zdalne wykonanie kodu bez logowania, jeśli usługa VPN jest wystawiona i skonfigurowana w określony sposób.


Gdzie występuje / przykłady platform (Windows, AD, AWS, Azure, GCP, K8s, ESXi, M365)

  • Network Devices / Edge (najważniejsze): WatchGuard Firebox (Fireware OS) wystawiony do Internetu na IKEv2.
  • Windows / AD: zwykle kolejny etap po initial access (pivot przez VPN, kradzież poświadczeń, ruch lateralny). [brak danych / do uzupełnienia] dla konkretnej kampanii powiązanej z CVE-2025-14733 (brak publicznie potwierdzonego kill-chain per-actor w źródłach vendorowych).
  • AWS / Azure / GCP: jeśli Firebox działa jako appliance w chmurze (np. Firebox Cloud) — dochodzi warstwa kontroli ekspozycji przez Security Group/NSG i logi cloudowe (CloudTrail/Activity Log) do wykrywania nagle otwartych UDP 500/4500.
  • K8s: nie dotyczy bezpośrednio (to nie jest podatność kontenerowa).
  • ESXi: nie dotyczy bezpośrednio (chyba że Firebox jest elementem segmentacji/DMZ).
  • M365: nie dotyczy bezpośrednio; ewentualnie telemetria logowań po kompromitacji.

Szczegółowy opis techniki (jak działa, cele, dlaczego jest skuteczna)

W praktyce CVE-2025-14733 wpisuje się w T1190, bo:

  • Punkt wejścia to usługa brzegowa: IKEv2 VPN na Fireboxie (Mobile User VPN i/lub Branch Office VPN).
  • Klasa błędu: out-of-bounds write (CWE-787), co typowo daje spektrum skutków od crash/hang po RCE.
  • Warunki podatności (ważne dla SOC): WatchGuard wskazuje zależność od konfiguracji IKEv2 (w tym dynamic gateway peer) oraz fakt, że nawet po usunięciu konfiguracji dynamic peer urządzenie może nadal pozostać podatne w określonych przypadkach (istniejące BOVPN do static peer).
  • Dlaczego skuteczne operacyjnie: edge urządzenia są często wystawione do Internetu i mają ograniczone host-based controls; do tego dochodzi presja “VPN musi działać”, więc okno patchowania bywa realnie dłuższe niż w serwerach aplikacyjnych. To jest dokładnie kontekst, który MITRE opisuje dla T1190 (również w odniesieniu do urządzeń sieciowych).

Artefakty i logi (tabela — EID, CloudTrail events, K8s audit, M365 operations)

Artefakt / sygnałEID (Windows)CloudTrail events (AWS)K8s auditM365 operationsGdzie szukać / komentarz
iked: “Received peer certificate chain is longer than 8…”Syslog/Traffic Monitor z Firebox (domyślny error level). To vendor opisuje jako medium indicator of attack.
iked: “IKE_AUTH request … CERT(sz=3000) …” i CERT > 2000Syslog przy info logging; WatchGuard wskazuje >2000 jako strong indicator.
IKED hang (VPN re-key/negocjacje “stają”)Zachowanie urządzenia: przerwane negocjacje, istniejące tunele mogą działać.
IKED crash + fault reportWatchGuard: crash po udanej/nieudanej próbie (weak indicator).
Ruch outbound z Firebox do wskazanych IP (IoA)WatchGuard: outbound do tych IP to mocny sygnał kompromitacji; inbound może oznaczać recon/attempt.
Nagle otwarte UDP 500/4500 do Internetu (Firebox Cloud)AuthorizeSecurityGroupIngress / zmiany NACLDla wdrożeń w AWS: koreluj zmiany ekspozycji z aktywnością iked. (Detekcja “okołopodatnościowa”, ale praktyczna).

Detekcja (praktyczne reguły)

Sigma (gotowa reguła)

Założenie: logi Firebox (syslog) trafiają do SIEM jako tekst (np. message). Dopasuj logsource do swojego pipeline’u (np. Syslog/CEF).

title: WatchGuard Firebox CVE-2025-14733 - IKEv2 iked Indicators
id: 3f3a8a7c-5b0c-4b56-9c1d-4a5a54f6d2f1
status: experimental
description: |
  Detects WatchGuard Firebox iked log patterns associated with CVE-2025-14733 exploitation attempts:
  - peer certificate chain longer than 8
  - IKE_AUTH requests with abnormally large CERT payload size (>=2000 bytes)
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2025-14733
  - https://www.watchguard.com/wgrd-psirt/advisory/wgsa-2025-00027
author: SOC/Blue Team
date: 2025/12/23
logsource:
  category: firewall
  product: watchguard
detection:
  sel_chain_long:
    message|contains:
      - 'Received peer certificate chain is longer than 8'
      - 'Reject this certificate chain'
  sel_cert_big:
    message|contains:
      - 'IKE_AUTH request'
      - 'CERT(sz='
  sel_cert_big_re:
    message|re: 'CERT\(sz=(2[0-9]{3}|[3-9][0-9]{3,})\)'
  condition: sel_chain_long or (sel_cert_big and sel_cert_big_re)
falsepositives:
  - Unusual but legitimate certificate chains from misconfigured peers
  - Large certificate payloads in rare enterprise PKI setups
level: high
tags:
  - attack.initial_access
  - attack.t1190

Wzorce logów i progi (chain > 8, CERT > 2000) są oparte o wskaźniki opisane przez WatchGuard.

Splunk (SPL)

1) IoA w logach iked (CERT/chain):

index=network (sourcetype=syslog OR sourcetype=watchguard*)
("iked" AND ("Received peer certificate chain is longer than 8" OR "IKE_AUTH request"))
| rex field=_raw "CERT\(sz=(?<cert_sz>\d+)\)"
| eval cert_sz=tonumber(cert_sz)
| where like(_raw,"%Received peer certificate chain is longer than 8%") OR cert_sz>=2000
| stats count earliest(_time) as firstSeen latest(_time) as lastSeen values(host) as devices values(src) as src_ip values(cert_sz) as cert_sizes by dest
| convert ctime(firstSeen) ctime(lastSeen)

2) Ruch do IP z advisory (outbound = silniejszy sygnał):

index=network (sourcetype=pan:traffic OR sourcetype=netflow OR sourcetype=watchguard*)
(dest_ip IN ("45.95.19.50","51.15.17.89","172.93.107.67","199.247.7.82") OR
 src_ip  IN ("45.95.19.50","51.15.17.89","172.93.107.67","199.247.7.82"))
| stats count earliest(_time) as firstSeen latest(_time) as lastSeen values(action) as actions values(dest_port) as ports by src_ip dest_ip
| convert ctime(firstSeen) ctime(lastSeen)

Lista IP i interpretacja inbound/outbound pochodzą z WatchGuard IoA.

KQL (Azure / Microsoft Sentinel)

Syslog (Syslog table) — CERT > 2000 / chain > 8:

Syslog
| where ProcessName has "iked" or SyslogMessage has "iked"
| extend CertSz = toint(extract(@"CERT\(sz=(\d+)\)", 1, SyslogMessage))
| where SyslogMessage has "Received peer certificate chain is longer than 8"
   or (SyslogMessage has "IKE_AUTH request" and CertSz >= 2000)
| project TimeGenerated, Computer, Facility, SeverityLevel, ProcessName, CertSz, SyslogMessage
| order by TimeGenerated desc

CommonSecurityLog / firewall telemetry — IoA IP:

let ioc_ips = dynamic(["45.95.19.50","51.15.17.89","172.93.107.67","199.247.7.82"]);
CommonSecurityLog
| where DestinationIP in (ioc_ips) or SourceIP in (ioc_ips)
| project TimeGenerated, DeviceVendor, DeviceProduct, SourceIP, DestinationIP, DestinationPort, Activity, Message
| order by TimeGenerated desc

IoA IP i log-patterny: WatchGuard advisory.

CloudTrail query (AWS CLI/CloudWatch)

Scenariusz: Firebox Cloud w AWS — polujemy na “nagłe wystawienie” UDP 500/4500 do Internetu.

AWS CLI (CloudTrail LookupEvents) — SG ingress na 500/4500 (wymaga jq):

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AuthorizeSecurityGroupIngress \
  --max-results 50 \
| jq -r '
  .Events[]
  | (.CloudTrailEvent | fromjson)
  | select(.requestParameters.ipPermissions.items[]? | (.fromPort==500 or .fromPort==4500))
  | {eventTime, userIdentity: .userIdentity.arn, groupId: .requestParameters.groupId, ipPermissions: .requestParameters.ipPermissions.items}
'

Jeśli zamiast CloudTrail trzymasz telemetrię w innych źródłach, oznacz to jako [brak danych / do uzupełnienia] w swoim runbooku.

Elastic/EQL przykłady

Kibana KQL (syslog z Firebox):

(event.dataset: syslog OR event.dataset: "watchguard*")
and (message: "*Received peer certificate chain is longer than 8*"
     or (message: "*IKE_AUTH request*" and message: "*CERT(sz=2*")
     or (message: "*IKE_AUTH request*" and message: "*CERT(sz=3*"))

EQL (jeśli masz ustandaryzowane pola):

any where
  event.category == "network" and
  (process.name == "iked" or message like "*iked*") and
  (
    message like "*Received peer certificate chain is longer than 8*"
    or (message like "*IKE_AUTH request*" and message regex "CERT\\(sz=(2[0-9]{3}|[3-9][0-9]{3,})\\)")
  )

Heurystyki / korelacje

Dla SOC sensownie działa korelacja “multi-signal”, zgodna z duchem MITRE (request → error → post-exploit).

Proponowane łańcuchy:

  1. IKE_AUTH (CERT > 2000) lub chain > 8 → w oknie 1–5 min IKED hang/crash → w oknie 5–30 min outbound do podejrzanych IP / nowy egress z urządzenia.
  2. Spike w inbound UDP 500/4500 z AS/geo nietypowego dla Twoich peerów + równoległy wzrost błędów iked.
  3. Dla static BOVPN: obecność “allow from all” na UDP 500 (domyślne polityki) + ruch z Internetu + anomalie iked → priorytet P1 (bo tu “hardening” jest realnym workaroundiem).

False positives / tuning

  • “certificate chain longer than 8” może się zdarzyć przy źle złożonym łańcuchu certów po stronie peera (PKI, błędy klienta) — traktuj jako średni sygnał, dopóki nie ma korelacji z crash/hang lub CERT > 2000.
  • CERT > 2000: vendor opisuje jako strong indicator, ale w dużych środowiskach (długie łańcuchy, nietypowe certy) warto whitelistingować znane peer IP i/lub profile, zamiast obniżać próg.
  • Crash iked: WatchGuard podkreśla, że są inne przyczyny crashy → traktuj jako weak indicator sam w sobie.
  • Tuning praktyczny: ogranicz ekspozycję do znanych peerów (alias) i wyłącz domyślne “allow IKE from all” — wtedy większość FP znika, bo “Internet noise” przestaje docierać do usługi.

Playbook reagowania (kroki + komendy)

Krok 0 — triage (czy jesteśmy w zakresie?)

  1. Sprawdź wersję Fireware i porównaj z listą podatnych/fix.
  2. Sprawdź, czy masz IKEv2 (Mobile VPN IKEv2 / BOVPN IKEv2, dynamic peer).
  3. Hunting po IoA logach (iked) i połączeniach do IP z advisory.

Krok 1 — containment (minimalizuj powierzchnię ataku)

  • Jeśli biznes pozwala: czasowo wyłącz IKEv2 VPN lub ogranicz go do stałych peerów.
  • Jeśli masz tylko static peer BOVPN i nie możesz od razu patchować: zastosuj hardening wg WatchGuard:
    1. wyłącz dynamic peer VPN,
    2. utwórz alias ze stałymi IP peerów,
    3. dodaj polityki dopuszczające UDP 500/4500 tylko z aliasu,
    4. wyłącz domyślne polityki IPSec “allow all”.

Krok 2 — eradication (patch/upgrade)

  • Wgraj wersje naprawione:
    • 2025.1.4+, 12.11.6+, 12.5.15 (T15/T35), 12.3.1_Update4 (FIPS).
  • Jeśli jesteś na 11.x: to gałąź EoL — plan migracji jest obowiązkowy (w praktyce “nie ma co czekać na fix”).

Krok 3 — recovery (po podejrzeniu kompromitacji: rotacja sekretów)

WatchGuard zaleca rotację lokalnie przechowywanych sekretów. Przykładowa lista do odhaczenia:

  • credentials do zarządzania Firebox,
  • Firebox-DB,
  • importowane certyfikaty i klucze prywatne,
  • IPsec PSK (BOVPN/L2TP/mobile IPsec),
  • Log Server PSK,
  • SNMP community / SNMPv3 auth,
  • RADIUS shared secrets,
  • LDAP/AD “searching user” password,
  • DDNS creds, PPPoE creds, itp.

Krok 4 — post-incident hardening

  • Wprowadź stały proces: vuln scanning + szybkie patchowanie dla edge (MITRE mitigation: Update Software, Vulnerability Scanning, Limit Access…).

Przykłady z kampanii / case studies

  • WatchGuard wprost wskazuje, że obserwuje aktywną próbę eksploatacji w środowiskach produkcyjnych.
  • Różne źródła branżowe raportują dużą liczbę wystawionych/podatnych instancji (rzędu ~115k–125k) na podstawie skanów/obserwacji (np. Shadowserver) — to podbija ryzyko “spray-and-pray” na UDP 500/4500.
  • NVD odnotowuje powiązanie z KEV (wpisy dot. “Date Added / Due Date / Required Action” pojawiają się w szczegółach CVE), co w praktyce często koreluje z dojrzałą eksploatacją.

Lab (bezpieczne testy) — przykładowe komendy

A) Test detekcji w SIEM przez “wstrzyknięcie” przykładowego sysloga

Na systemie, który wysyła syslog do SIEM:

logger -p local3.err 'iked[1234]: (203.0.113.1<->203.0.113.2) Received peer certificate chain is longer than 8. Reject this certificate chain'
logger -p local3.info 'iked (203.0.113.1<->203.0.113.2)"IKE_AUTH request" message has 6 payloads [ IDi(sz=21) CERT(sz=3000) SA(sz=44) TSi(sz=24) TSr(sz=24) N(sz=8)]'

Wzorce komunikatów są zgodne z przykładami z advisory.

B) Test “ekspozycji” portów tylko na własnym publicznym IP Firebox

nmap -sU -p 500,4500 -Pn <PUBLIC_IP_FIREBOX>

Cel: potwierdzenie, czy UDP 500/4500 jest wystawione szeroko, czy ograniczone politykami do znanych peerów (hardening).

C) Walidacja hardeningu (bez patcha, doraźnie)

Wykonaj kroki z KB: aliasy + nowe polityki + wyłączenie systemowych “allow IKE”.


Mapowania (Mitigations, Powiązane techniki)

MITRE ATT&CK (technika główna)

  • T1190 — Exploit Public-Facing Application
    • Taktika: Initial Access
    • ATT&CK (strona techniki): Version 2.8, Last Modified 24 Oct 2025

MITRE Mitigations (praktyczne dla CVE-2025-14733)

Z listy mitigacji przypisanych do T1190 (wybrane, najbardziej operacyjne dla Firebox/edge):

  • M1051 Update Software (patch management edge)
  • M1016 Vulnerability Scanning (zewnętrzne skany + szybkie okna patchy)
  • M1035 Limit Access to Resource Over Network (zawężenie UDP 500/4500 do znanych peerów)
  • M1037 Filter Network Traffic (kontrola egress, blokady IoA)
  • M1030 Network Segmentation (DMZ/segmentacja od reszty)

Powiązane techniki (kontekstowe)

  • Exploitation for Defense Evasion (gdy exploit jednocześnie omija kontrolki) oraz Exploitation for Client Execution — MITRE wskazuje, że T1190 może się z tym łączyć zależnie od podatności.

Źródła / dalsza literatura

  • WatchGuard PSIRT Advisory WGSA-2025-00027 (IoA/IoC, wersje naprawione, logi iked). (watchguard.com)
  • WatchGuard blog (lista wydań firmware i nacisk na pilną aktualizację). (watchguard.com)
  • NVD: CVE-2025-14733 (opis, zakres wersji, CWE-787, CVSS). (NVD)
  • CSA Singapore alert (potwierdzenie krytyczności i informacji o eksploatacji). (Cyber Security Agency of Singapore)
  • WatchGuard KB: hardening BOVPN/IKEv2 (aliasy + polityki + wyłączenie systemowych “allow”). (techsearch.watchguard.com)
  • WatchGuard KB: lista sekretów do rotacji po podejrzeniu kompromitacji. (techsearch.watchguard.com)
  • MITRE ATT&CK: T1190 (definicja, platformy, mitigacje, detection strategy). (MITRE ATT&CK)
  • Doniesienia branżowe o skali ekspozycji i atakach: BleepingComputer / SecurityWeek / TheHackerNews. (BleepingComputer)

Checklisty dla SOC / CISO

SOC (operacyjnie)

  • Zidentyfikuj wszystkie Fireboxy i ich wersje Fireware; oznacz EoL 11.x jako P0 do migracji.
  • Sprawdź konfiguracje: Mobile VPN IKEv2 / BOVPN IKEv2 (dynamic peer) + “pozostałości” po konfiguracjach historycznych.
  • Włącz/zbierz logi iked do SIEM; reguły na chain > 8 i CERT > 2000.
  • Koreluj z iked hang/crash oraz ruchem outbound do IoA IP.
  • Po IoA/IOC: uruchom procedurę rotacji sekretów (lista wg KB).

CISO / właściciel ryzyka

  • Wymuś patch/upgrade do wersji naprawionych (SLA “edge”).
  • Zmień standard: IKEv2 nie jest “publiczny dla świata” — tylko znane peer’y (aliasy/polityki).
  • Włącz stałe vulnerability scanning + szybkie okna patchy na urządzeniach brzegowych.