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?
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:
Skala w warstwie IT (ok. 1000 urządzeń) przy jednoczesnym utrzymaniu procesów fizycznych dzięki procedurom operacyjnym i pracy „w terenie”.
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):
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
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
Security Affairs – Romanian Waters confirms cyberattack, critical water operations unaffected (22.12.2025). (Security Affairs)
BleepingComputer – Romanian water authority hit by ransomware attack over weekend (22.12.2025). (BleepingComputer)
The Record (Recorded Future News) – Romanian national water agency hit by BitLocker ransomware attack (ok. 22.12.2025). (The Record from Recorded Future)
DNSC (Directoratul Național de Securitate Cibernetică) – komunikat prasowy nt. incydentu ransomware w „Apele Române” (notyfikacja 20.12.2025). (DNSc)
Tom’s Hardware – 1,000 computers taken offline in Romanian water management authority hack… (ok. 23.12.2025). (Tom’s Hardware)
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 / warstwa
EID (Windows)
CloudTrail events
K8s audit
M365 operations
Co warto zbierać / na co patrzeć
Dostęp do interfejsu web/API smartRTU
N/A
N/A
N/A
N/A
Logi HTTP (reverse proxy/WAF), metoda POST/PUT/DELETE, nietypowe URI, skoki 4xx/5xx, nietypowe UA, duże payloady
Firewall / IDS/IPS
N/A
N/A
N/A
N/A
Inbound 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/A
N/A
N/A
Nietypowe 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/A
N/A
N/A
N/A
Syslog/audit (o ile jest), historia poleceń, zmiany konfiguracji, restarty usług/urządzenia
WAF (jeśli publikujesz web)
N/A
(raczej) N/A
N/A
N/A
Reguł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
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ę).
Źródło spoza polityki dostępu: jakikolwiek request do panelu/API smartRTU z IP spoza allowlist (VPN/management VLAN).
Zmiany konfiguracyjne / restarty: anomalia w dostępności RTU, restart usług, zmiany parametrów – skorelowane czasowo z nietypowym ruchem do web/API.
Skanowanie: rozproszony ruch do portów zarządczych (80/443) poprzedzający właściwe wywołania.
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
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:
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.
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:
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.
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.
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.
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”
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
DXS International plc – Notice of Cyber Security Incident (18.12.2025). (GlobeNewswire)
DXS International plc – Update on Cyber Security Incident (24.12.2025). (GlobeNewswire)
TechCrunch – Tech provider for NHS England confirms data breach (18.12.2025). (TechCrunch)
TechRadar – NHS England tech provider reveals data breach – DXS International hit by ransomware (22.12.2025). (TechRadar)
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
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.
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.
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).
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
TechRadar – opis incydentu, zakres systemów, informacja o BitLocker i nocie okupu (23.12.2025). (TechRadar)
BleepingComputer – dodatkowe szczegóły dot. dotkniętych usług i trybu działania operacyjnego (22.12.2025). (BleepingComputer)
The Record (Recorded Future News) – kontekst „LOLBins” i BitLocker jako metoda wymuszenia (22.12.2025). (The Record from Recorded Future)
The Register – uzupełniające informacje o skali i rekomendacjach dot. negocjacji (22.12.2025). (The Register)
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)
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).
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 > 2000
—
—
—
—
Syslog 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 report
—
—
—
—
WatchGuard: 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 NACL
—
—
Dla 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.
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:
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.
Spike w inbound UDP 500/4500 z AS/geo nietypowego dla Twoich peerów + równoległy wzrost błędów iked.
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?)
Sprawdź wersję Fireware i porównaj z listą podatnych/fix.
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):
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)
CVE-2025-61884 dotyczy Oracle E-Business Suite (EBS) → Oracle Configurator → komponent Runtime UI w wersjach 12.2.3–12.2.14 i jest zdalnie wykorzystywalna bez uwierzytelnienia przez HTTP/HTTPS.
Ocena producenta/NVD wskazuje na wysoki wpływ na poufność (CVSS 3.1: 7.5, C:H / I:N / A:N), czyli przede wszystkim nieautoryzowany dostęp/wyciek danych.
W praktyce jest opisywana jako pre-auth SSRF (nazwa w KEV/NVD oraz alerty branżowe/instytucjonalne), a publiczne raporty łączą ją z aktywnym wykorzystywaniem i publicznie dostępnym PoC.
W ATT&CK najlepiej mapuje się do T1190 – Exploit Public-Facing Application (Initial Access); MITRE wskazuje m.in. WAF, filtrowanie ruchu i patching jako kluczowe mitygacje.
Krótka definicja techniczna (1 akapit)
CVE-2025-61884 to podatność w publicznie wystawionym komponencie webowym (Oracle Configurator Runtime UI), która umożliwia niezalogowanemu atakującemu doprowadzenie aplikacji do zachowań niezamierzonych (w raportach klasyfikowanych jako SSRF) i w konsekwencji uzyskanie dostępu do wrażliwych zasobów/danych; w ATT&CK odpowiada temu T1190 (Initial Access) – wejście przez podatną aplikację dostępną z Internetu.
Gdzie występuje / przykłady platform (Windows, AD, AWS, Azure, GCP, K8s, ESXi, M365)
Windows: rzadziej jako host EBS, ale jeśli front (proxy/WAF) lub komponenty pośrednie są na Windows — interesują logi IIS/reverse proxy oraz EDR na hoście aplikacji. (Rdzeń CVE jest jednak w komponencie EBS/Configurator).
AD: pośrednio — EBS bywa spięty z AD/SSO. Skutkiem może być ekspozycja danych i późniejsza eskalacja (np. kradzież konfiguracji, identyfikatorów, mapowań).
AWS: częsty scenariusz: EBS na EC2 + ALB/WAF + CloudWatch Logs. W kontekście SSRF szczególnie ważne: egress z serwera i ochrona przed dostępem do metadata endpoint (169.254.169.254).
Azure: analogicznie (App Gateway WAF / Front Door + Log Analytics). SSRF → ryzyko dostępu do metadanych instancji i tokenów, jeśli egress nie jest ograniczony.
GCP: podobny model (LB/WAF, logi HTTP LB, kontrola egress).
K8s: rzadziej dla EBS, ale jeśli komponent jest „opakowany” lub stoi za ingress — logi ingress + korelacja z egress kontenera.
ESXi: nie dotyczy bezpośrednio CVE, ale MITRE wskazuje T1190 także dla infrastruktury (gdy aplikacje/zarządzanie są wystawione).
M365: brak bezpośredniego wektora; może być użyte w łańcuchu (np. dalsza eksfiltracja).
Szczegółowy opis techniki (jak działa, cele, dlaczego jest skuteczna)
Kontekst CVE-2025-61884 w łańcuchu Initial Access
W przypadku Oracle EBS/Configurator Runtime UI, atakujący nie potrzebuje konta — wystarczy dostęp sieciowy do HTTP/HTTPS i podatnej wersji. To jest „książkowy” wariant T1190, bo aplikacja publicznie wystawiona staje się bramą do danych/zasobów.
Co realnie daje podatność
Oficjalny opis (Oracle/NVD) wskazuje na dostęp do „sensitive resources” oraz nieautoryzowany dostęp do krytycznych danych w ramach tego, co Oracle Configurator udostępnia.
W metadanych NVD/KEV podatność nazywana jest SSRF, a CISA-ADP przypisało m.in. CWE-918 (SSRF) oraz inne CWE, co sugeruje albo wieloprzymitywowy błąd, albo różne interpretacje łańcucha (ważne: Oracle zwykle nie publikuje pełnych detali technicznych).
Publiczne raporty wskazują, że poprawka wiązała się m.in. z walidacją parametru typu return_url, co jest typowym miejscem dla nadużyć SSRF/redirect/CRLF — dla SOC to cenna wskazówka do polowania w logach.
Dlaczego to jest skuteczne (z perspektywy atakującego)
Pre-auth (brak loginu) + niska złożoność (AC:L) = bardzo szybkie skanowanie Internetu i automatyzacja.
„Systemy biznesowe” (EBS) często zawierają dane finansowe/HR/procesowe, więc nawet „tylko” poufność (C:H) ma wysoki wpływ operacyjny.
MITRE rekomenduje podejście multi-signal (żądanie → błędy → proces/egress), bo same żądania HTTP nie zawsze wystarczą do pewnego potwierdzenia skutecznej eksploatacji.
Jeśli EBS jest za ingress: wzorce exploit-probing + egress z poda
M365
Unified Audit Log
—
—
Zwykle N/A dla samego CVE
Detekcja (praktyczne reguły)
Poniższe przykłady celują w telemetrię HTTP/WAF i klasyczne sygnały SSRF/probing. Wg publicznych raportów aktywność obejmowała m.in. endpointy UiServlet/SyncServlet oraz parametry redirekt/URL.
title: Oracle EBS Configurator Runtime UI - Suspicious SSRF / return_url Patterns (CVE-2025-61884)
id: 2a2c9c6d-6d2b-4b5a-9c86-5b2f7a3f3b7d
status: experimental
description: |
Detects suspicious requests to Oracle E-Business Suite (Oracle Configurator Runtime UI) endpoints
with URL/redirect parameters suggestive of SSRF/probing related to CVE-2025-61884.
author: Badacz CVE
date: 2025/12/23
tags:
- attack.initial_access
- attack.t1190
logsource:
category: webserver
detection:
selection_endpoint:
url.path|contains:
- "/configurator/UiServlet"
- "/OA_HTML/configurator/UiServlet"
- "/OA_HTML/SyncServlet"
selection_param:
url.query|contains:
- "return_url="
selection_ssrf_indicators:
url.query|contains:
- "http://"
- "https://"
- "file://"
- "gopher://"
- "ftp://"
- "169.254.169.254"
- "127.0.0.1"
- "localhost"
- "%0d%0a"
- "%0D%0A"
condition: selection_endpoint and selection_param and selection_ssrf_indicators
falsepositives:
- Rare legitimate redirect flows using absolute URLs (tune by source IP ranges, auth/session cookies, user agents, rate)
level: high
Splunk (SPL)
(index=web OR index=waf OR index=proxy)
| eval path=coalesce(url_path, uri_path, cs_uri_stem, request_path)
| eval query=coalesce(url_query, uri_query, cs_uri_query, query_string)
| where like(path, "%/configurator/UiServlet%")
OR like(path, "%/OA_HTML/configurator/UiServlet%")
OR like(path, "%/OA_HTML/SyncServlet%")
| where isnotnull(query) AND match(lower(query), "return_url=")
| where match(lower(query), "(http://|https://|file://|gopher://|ftp://|169\\.254\\.169\\.254|127\\.0\\.0\\.1|localhost|%0d%0a)")
| stats count as hits min(_time) as first_seen max(_time) as last_seen values(status) as status values(useragent) as ua by src_ip, host, path
| sort - hits
KQL (Azure / Microsoft Sentinel)
WAF / reverse proxy w Log Analytics (przykład ogólny):
let suspiciousPaths = dynamic([
"/configurator/UiServlet",
"/OA_HTML/configurator/UiServlet",
"/OA_HTML/SyncServlet"
]);
AzureDiagnostics
| extend path = tostring(requestUri_s), query = tostring(queryString_s), clientIp = tostring(clientIP_s)
| where path has_any (suspiciousPaths)
| where query has "return_url="
| where query has_any ("http://","https://","file://","gopher://","ftp://","169.254.169.254","127.0.0.1","%0d%0a")
| summarize hits=count(), first_seen=min(TimeGenerated), last_seen=max(TimeGenerated),
ua=makeset(userAgent_s, 5) by clientIp, path
| order by hits desc
CloudTrail query (AWS CLI/CloudWatch)
Dla tej klasy zdarzeń CloudTrail zwykle nie pomoże (to nie są API calls), ale sensowny jest CloudWatch Logs Insights na AWS WAF logs:
fields @timestamp, httpRequest.clientIp, httpRequest.uri, httpRequest.args, action, terminatingRuleId
| filter httpRequest.uri like /\/configurator\/UiServlet|\/OA_HTML\/configurator\/UiServlet|\/OA_HTML\/SyncServlet/
| filter httpRequest.args like /return_url=/
| filter httpRequest.args like /http:\/\/|https:\/\/|169\.254\.169\.254|127\.0\.0\.1|localhost|%0d%0a/i
| stats count() as hits, min(@timestamp) as first_seen, max(@timestamp) as last_seen,
values(action) as actions, values(terminatingRuleId) as rules
by httpRequest.clientIp, httpRequest.uri
| sort hits desc
Elastic/EQL przykłady
Kibana KQL (logi HTTP/WAF w ECS):
url.path : ("/configurator/UiServlet" or "/OA_HTML/configurator/UiServlet" or "/OA_HTML/SyncServlet")
and url.query : ("return_url=" and ("http://" or "https://" or "file://" or "gopher://" or "ftp://" or "169.254.169.254" or "127.0.0.1" or "localhost" or "%0d%0a"))
sequence by host.id with maxspan=5m
[network where network.direction == "inbound"
and url.path in ("/configurator/UiServlet", "/OA_HTML/configurator/UiServlet", "/OA_HTML/SyncServlet")]
[network where network.direction == "outbound"
and destination.ip in ("169.254.169.254","127.0.0.1")]
Heurystyki / korelacje (co łączyć)
Korzystaj z podejścia „multi-signal correlation” (MITRE):
Sygnał 1 — inbound probing: nietypowe żądania do servletów Configurator/Sync, często z zewnętrznych adresów i bez kontekstu sesji.
Sygnał 2 — WAF / error spike: wzrost blokad WAF, 4xx/5xx w krótkim oknie czasu. (Cloudflare dodał nawet dedykowaną detekcję „Oracle EBS – SSRF – CVE-2025-61884”).
Sygnał 3 — egress anomalia: serwer EBS inicjuje połączenia do nietypowych hostów (wewnętrznych, link-local, metadata). To jest kluczowe przy SSRF.
Sygnał 4 — data exfil: duże odpowiedzi HTTP (bytes out) / długie czasy odpowiedzi dla endpointów Runtime UI, szczególnie bez typowego flow aplikacyjnego.
Sygnał 5 — kontekst zagrożenia: CVE zostało dodane do KEV (NVD pokazuje daty dodania i deadline), co zwiększa priorytet i uzasadnia hunting retrospektywny.
False positives / tuning
Typowe FP i jak je ograniczać:
Legalne użycie redirectów: jeśli aplikacja używa parametru return_url do nawigacji — dopuszczalne, ale zwykle:
pochodzi z wewnętrznych adresów IP/VPN,
ma spójny user-agent,
występuje w obecności cookie/sesji. Tuning: ogranicz detekcję do źródeł spoza korporacyjnych CIDR, dodaj warunek braku sesji, dodaj próg częstotliwości (rate).
Skanery podatności w organizacji: wpisz je na allowlistę (IP/UA), ale zachowaj osobny dashboard „security scanning activity”.
WAF sygnatury: jeśli korzystasz z Cloudflare — śledź nową regułę dla CVE-2025-61884 jako sygnał, ale koreluj z ruchem „allowed”, bo część kampanii może próbować obejść WAF przez inne ścieżki (np. bez WAF lub przez inne punkty wejścia).
Playbook reagowania (kroki + komendy)
Natychmiastowe ograniczenie ryzyka (containment)
Odetnij Internet → Runtime UI / EBS (tymczasowo: allowlist VPN/bastion/WAF). MITRE wprost rekomenduje ograniczenie ekspozycji usług oraz segmentację/DMZ.
Włącz/zaostrz WAF (jeśli masz Cloudflare — zweryfikuj, czy działa reguła dla CVE-2025-61884).
Ogranicz egress z serwera EBS (SSRF „żyje” egress’em).
Przykład (Linux, defensywnie – blokada metadata; dopasuj do polityk):
sudo iptables -A OUTPUT -d 169.254.169.254 -j REJECT
sudo iptables -A OUTPUT -d 127.0.0.1 -p tcp --dport 80 -j REJECT
Patching i weryfikacja
Zastosuj Oracle Security Alert z 11 października 2025 (Rev 1); Oracle wskazuje, że wersje spoza wsparcia mogły nie być testowane, ale „prawdopodobnie” wcześniejsze też mogą być dotknięte → jeśli masz starsze EBS, traktuj to jak ryzyko wysokie i planuj upgrade.
Hunting (retrospektywnie 30–90 dni)
Szybkie grepy (ścieżki dopasuj do Oracle HTTP Server / reverse proxy):
Traktuj to jak incydent o możliwym wpływie na dane: identyfikacja zakresu wycieku, powiadomienia, analiza kont/SSO integracji.
Publiczne raporty opisują złożone łańcuchy exploitacji w ekosystemie EBS (różne CVE i różne łańcuchy); nawet jeśli CVE-2025-61884 ma CVSS tylko na poufność, w praktyce SOC powinien sprawdzić, czy nie wystąpiły sygnały „post-exploit”.
Przykłady z kampanii / case studies
Dodanie do KEV (widoczne w NVD) sugeruje dowody aktywnego wykorzystania i podbija priorytet patchowania/huntingu (NVD pokazuje „Date Added: 2025-10-20” oraz deadline).
CSA Singapur opublikowała alert wprost o aktywnej eksploatacji SSRF i podała, że PoC jest publicznie dostępny.
Media branżowe raportowały, że exploit/PoC miał zostać ujawniony publicznie (m.in. w wątku „ShinyHunters”), a Oracle wypuścił poprawkę out-of-band.
Kontekst kampanii extortion wokół Oracle EBS był szeroko opisywany, m.in. przez Reuters (z zastrzeżeniem, że ocena prawdziwości części twierdzeń napastników bywała na tamtym etapie niepewna).
Lab (bezpieczne testy) — przykładowe komendy
Cel labu dla Blue Team: zweryfikować ekspozycję, widoczność w logach i skuteczność detekcji, bez „odtwarzania exploitów”.
Sprawdź ekspozycję portów i usług (host EBS / reverse proxy):
sudo ss -lntp | egrep ':(80|443)\s'
Wygeneruj kontrolowany „ruch testowy” do standardowej strony (bez payloadów CVE), aby upewnić się, że logi trafiają do SIEM:
curl -kI https://twoj-host-ebs.example/ | head
Test parsowania i reguł detekcji na „sztucznych” wpisach logów (bez kontaktu z EBS):
