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)
DNS poisoning (zatrucie odpowiedzi DNS) to technika, w której atakujący powoduje, że ofiara rozwiązuje prawidłową domenę do nieprawidłowego (atakującego) adresu IP. W efekcie użytkownik może łączyć się „z właściwym adresem w pasku przeglądarki”, ale faktycznie trafia na serwer kontrolowany przez napastnika — a to idealny punkt wyjścia do cichej dystrybucji malware, zwłaszcza przez mechanizmy aktualizacji o słabej walidacji.
W grudniu 2025 Kaspersky opisał kampanię przypisaną do chińskojęzycznego APT Evasive Panda (alias m.in. Daggerfly/BRONZE HIGHLAND/StormBamboo), w której DNS poisoning posłużył do dostarczania backdoora MgBot w wysoce ukierunkowanych atakach obserwowanych między listopadem 2022 a listopadem 2024.
W skrócie
Kto: Evasive Panda / Daggerfly (G1034 w MITRE ATT&CK), powiązany z Chinami i znany z ekskluzywnego użycia MgBot.
Co: ukierunkowana dystrybucja MgBot przez DNS poisoning + fałszywe aktualizacje popularnych aplikacji.
Gdzie: ofiary wykryte w Türkiye, Chinach i Indiach; część hostów utrzymywana w kompromitacji ponad rok.
Jak: wieloetapowy łańcuch loaderów i shellcode’u, pobieranie kolejnego etapu jako „PNG” z domeny dictionary[.]com po uprzedniej manipulacji DNS, a następnie szyfrowanie hybrydowe DPAPI+RC5 wiążące payload z konkretną maszyną.
Kontekst / historia / powiązania
Evasive Panda jest aktywny co najmniej od 2012 r., a MITRE wskazuje na jego profil ofiar (m.in. podmioty rządowe/NGO/telekomy) oraz powiązanie z kampaniami o charakterze supply-chain.
To nie pierwsza historia, w której ta grupa „wchodzi w ścieżkę zaufania” użytkownika:
ESET (kwiecień 2023) opisał przypadek, gdzie kanały aktualizacji legalnych aplikacji zostały przejęte/hijackowane, aby podsunąć instalator MgBot — z rozważanymi hipotezami supply-chain lub ataku typu adversary-in-the-middle.
Volexity (sierpień 2024) pokazał scenariusz jeszcze cięższego kalibru: DNS poisoning na poziomie ISP, gdzie podmieniano odpowiedzi DNS dla domen mechanizmów aktualizacji, szczególnie gdy aktualizacje szły po HTTP i bez weryfikacji podpisu.
W kampanii opisanej przez Kaspersky, startem infekcji był plik udający update do aplikacji (np. SohuVA). Telemetria wskazała pobieranie z zasobu pod domeną p2p.hd.sohu.com[.]cn, a badacze ocenili, że mogło dojść do DNS poisoning, które kierowało ofiarę na serwer atakującego mimo użycia „prawidłowej” domeny. Kaspersky dopisał też analogiczny schemat z „fałszywym updaterem” m.in. dla iQIYI, uruchamianym przez legalny qiyiservice.exe, oraz podobne podejście wobec IObit Smart Defrag i Tencent QQ.
2) Loader i etap shellcode: podszycie pod legalny projekt
Loader był napisany w C++ (WTL) i miał przypominać przykładową aplikację (sample) — co utrudnia szybkie odróżnienie „zwykłego” binarium od złośliwego.
3) DNS poisoning jako kanał dostarczania kolejnego etapu (dictionary[.]com)
Istotny fragment łańcucha: jeśli lokalny plik z danymi nie był obecny, shellcode przechodził do pobrania zaszyfrowanych danych z „web source” kontrolowanego przez atakującego, ale realizowanego poprzez DNS poisoning — w telemetrii wyglądało to jak pobranie „PNG” z legalnego dictionary[.]com. Co ważne, manipulacja miała być selektywna: ofiary rozwiązywały dictionary[.]com do różnych adresów IP w zależności od geolokalizacji i ISP.
4) „Sprytna” kryptografia: DPAPI + RC5, czyli payload związany z hostem
Kaspersky opisał hybrydę, w której klucz RC5 jest zaszyfrowany DPAPI i zapisany w pierwszych bajtach pliku (perf.dat), a reszta zawartości to payload szyfrowany RC5. Taki zabieg utrudnia analizę, bo DPAPI wiąże odszyfrowanie z konkretną maszyną.
5) In-memory execution i wstrzyknięcie MgBot
Po odszyfrowaniu kolejnego etapu secondary loader inicjuje uruchomienie/iniekcję (m.in. wskazano wstrzyknięcie wariantu MgBot do legalnego svchost.exe). Konfiguracja (m.in. nazwa kampanii, adresy C2) miała być odszyfrowywana prostym XOR, a część infrastruktury C2 wygląda na używaną wieloletnio.
Praktyczne konsekwencje / ryzyko
Zaufanie do DNS i update’ów jako punkt pojedynczej porażki. Jeśli DNS zostanie „skręcony” (na ISP, w sieci firmowej, na routerze), to nawet rozsądne zachowania użytkownika mogą nie wystarczyć — bo ofiara pobiera „aktualizację” spod znanej domeny.
Długotrwała, cicha kompromitacja. W tej kampanii część hostów pozostawała zainfekowana ponad rok, a całość (według telemetrii) trwała ok. 2 lata: XI 2022 – XI 2024.
Trudniejsza analiza i detekcja. Unikalne, per-ofiara elementy (np. dobór odpowiedzi po nagłówkach/wersji Windows) oraz szyfrowanie powiązane z hostem utrudniają triage, sandboxing i „łatwe” IOC-driven hunting.
Rekomendacje operacyjne / co zrobić teraz
Priorytet 1: uszczelnij aktualizacje (software supply chain w skali mikro)
Wymuszaj aktualizacje po HTTPS i z weryfikacją podpisów (oraz blokuj aktualizatory, które tego nie robią). Volexity wskazywał, że atakujący wybierali oprogramowanie z niepewnymi mechanizmami update (np. HTTP, brak walidacji podpisu).
W środowiskach firmowych rozważ allowlistę dla updaterów i repozytoriów aktualizacji oraz kontrolę uruchamiania binariów (AppLocker/WDAC).
Priorytet 2: zredukuj ryzyko manipulacji DNS
Przestaw stacje/serwery na zaufane resolvery i rozważ DoH/DoT (tam, gdzie to zgodne z polityką), aby utrudnić podmianę odpowiedzi po drodze na poziomie dostawcy. Uwaga: to nie „magiczna tarcza”, jeśli atakujący siedzi na brzegu sieci lub na urządzeniu końcowym — ale ogranicza klasę ataków na trasie. (W omawianej kampanii mechanizm poisoning pozostaje nie w pełni wyjaśniony).
Monitoruj rozbieżności DNS (np. porównanie odpowiedzi z kilku resolverów, alerty na nagłe zmiany A/AAAA dla popularnych domen).
Priorytet 3: hunting/IR pod kątem tej kampanii
Sprawdź artefakty ścieżek i plików wskazywanych w analizie (m.in. %ProgramData%\Microsoft\MF, status.dat, perf.dat) oraz nietypowe biblioteki/dropy związane z loaderem.
Poluj na podejrzane połączenia do znanych adresów C2 i anomalie w ruchu HTTP związane z pobieraniem „obrazów PNG” z domen, które normalnie nie służą do dystrybucji binariów.
Różnice / porównania z innymi przypadkami
ESET 2023: fokus na „przejęte aktualizacje” i rozważane scenariusze supply-chain/AitM przy dystrybucji MgBot.
Volexity 2024: twardy dowód na poisoning na poziomie ISP i wykorzystywanie słabych mechanizmów aktualizacji (HTTP, brak weryfikacji).
Kaspersky 2025: nacisk na selektywną dystrybucję kolejnych etapów (np. dictionary[.]com rozwiązywany do różnych IP zależnie od ISP/geo) oraz na utrudnianie analizy poprzez DPAPI+RC5 i in-memory injection.
Wspólny mianownik: atakowanie „zaufanych ścieżek” (DNS + aktualizacje), gdzie klasyczne „nie klikaj w linki” ma ograniczoną wartość, bo użytkownik i system robią to, co zwykle.
Podsumowanie / kluczowe wnioski
Kampania Evasive Panda opisana pod koniec grudnia 2025 r. to podręcznikowy przykład, jak DNS poisoning może stać się „niewidzialnym przewodem” do dystrybucji backdoora MgBot: ofiara widzi legalne domeny, a mimo to pobiera złośliwy kod. Dodatkowo, hybrydowe szyfrowanie (DPAPI+RC5) oraz selektywne odpowiedzi po DNS/HTTP podnoszą koszt obrony i analizy.
Jeśli chcesz zmniejszyć ekspozycję na tę klasę operacji, najwięcej „zysku za wysiłek” dają: twarda polityka bezpiecznych aktualizacji, sensowne zarządzanie DNS (i jego monitoring) oraz przygotowane playbooki huntingowe pod MgBot/Evasive Panda.
Źródła / bibliografia
The Hacker News — China-Linked Evasive Panda Ran DNS Poisoning Campaign to Deliver MgBot Malware (26.12.2025) (The Hacker News)
Kaspersky Securelist — Evasive Panda APT poisons DNS requests to deliver MgBot (24.12.2025) (Securelist)
CVE-2025-14847 to podatność w MongoDB Server związana z obsługą zlib w kompresji sieciowej protokołu MongoDB: niespójne pola długości w nagłówkach skompresowanych wiadomości mogą doprowadzić do zwrócenia fragmentów niezainicjalizowanej pamięci heap do klienta bez uwierzytelnienia. Dla SOC oznacza to: jeśli instancja MongoDB jest wystawiona na Internet, atakujący może „wyciągać” z odpowiedzi wrażliwe fragmenty pamięci procesu (potencjalnie dane aplikacyjne/sekrety zależnie od tego, co akurat było w RAM). Priorytet: patch do wersji naprawionych lub czasowo usuń zlib z kompresorów.
Krótka definicja techniczna (1 akapit)
CVE-2025-14847 to błąd klasy CWE-130 polegający na niewłaściwej obsłudze niespójnych parametrów długości w zlib-compressed protocol headers MongoDB, co umożliwia zdalnemu, nieautoryzowanemu klientowi odczyt niezainicjalizowanej pamięci heap poprzez odpowiedzi serwera.
Gdzie występuje / przykłady platform (Windows, AD, AWS, Azure, GCP, K8s, ESXi, M365)
Windows (self-hosted):
mongod.exe/mongos.exe uruchomione jako usługa (często port 27017) — ryzyko rośnie, gdy bind/listen jest „na świat” i gdy zlib pozostaje włączony (domyślnie jest).
AD (Active Directory):
Bezpośrednio „nie dotyczy” (to nie jest podatność AD), ale realnie MongoDB bywa konsumowane przez aplikacje domenowe; wyciek pamięci może pośrednio ujawnić np. tokeny/sekrety aplikacyjne trzymane w RAM.
AWS (EC2 / EKS / self-managed):
EC2 z Security Group otwierającą 27017/27018 do 0.0.0.0/0 → klasyczny scenariusz T1190.
EKS: MongoDB jako StatefulSet; ekspozycja przez Service type=LoadBalancer/Ingress/NodePort zwiększa ryzyko.
Azure (VM / AKS):
VM z publicznym IP + NSG pozwalający na 27017; AKS analogicznie jak EKS.
GCP (Compute Engine / GKE):
Publiczny endpoint + reguły FW do 27017; w GKE ekspozycja przez Service LB.
Kubernetes (K8s):
Szczególnie ryzykowne: publiczny LoadBalancer dla MongoDB lub brak NetworkPolicy dla namespace z bazą.
ESXi:
Pośrednio: gdy MongoDB stoi na VM — liczą się zasady ekspozycji/segmentacji sieci, snapshoty do IR itp.
M365:
Zwykle „nie dotyczy” (chyba że logi/alerty spływają do Sentinel/MDE; sama podatność jest po stronie serwera MongoDB).
Ważne operacyjnie: MongoDB informował, że Atlas fleet został spatchowany i „nie ma dowodów” na wykorzystanie ani kompromitację danych klientów; dotyczy to jednak usług zarządzanych — self-hosted musi być zaktualizowany osobno.
Szczegółowy opis techniki (jak działa, cele, dlaczego jest skuteczna)
Negocjacja kompresji i dlaczego zlib ma znaczenie
MongoDB wspiera kompresję ruchu między klientem a serwerem (OP_COMPRESSED). Domyślnie zarówno mongod, jak i mongos mają ustawione kompresory sieciowe na snappy,zstd,zlib (w tej kolejności). CVE-2025-14847 dotyczy ścieżki obsługi zlib: spreparowane (niepoprawne) nagłówki skompresowanych wiadomości z niespójnymi długościami mogą doprowadzić do sytuacji, w której serwer zwraca w odpowiedzi fragmenty niezainicjalizowanej pamięci heap.
Co realnie wycieka z heap i jak to eskaluje ryzyko
Ponieważ mowa o pamięci procesu, w praktyce „to, co wycieknie”, zależy od:
obciążenia bazy (zapytania/odpowiedzi, BSON, bufory),
bibliotek i alokacji w danym buildzie,
tego, co aplikacje trzymają w pamięci (np. fragmenty dokumentów, metadane sesji, czasem sekrety).
Oficjalny wektor CVSS od CNA wskazuje wysoki wpływ na poufność i brak wpływu na integralność/dostępność (C:H / I:N / A:N).
Dlaczego to pasuje do ATT&CK T1190
Jeżeli MongoDB jest publicznie wystawione (Internet-facing), to atakujący wykorzystuje błąd w usłudze nasłuchującej na gnieździe TCP — to klasyczny model Exploit Public-Facing Application (T1190) w taktyce Initial Access (nawet jeśli „efektem” jest wyciek informacji, a nie RCE).
Czy net.compression.compressors nadal zawiera zlib (domyślnie zawiera)
„Skany” i bursty połączeń do MongoDB
Sysmon EID 3 + firewall
(opcjonalnie) GuardDuty/VPC Flow Logs poza CloudTrail
N/A
N/A
Wysoka liczba krótkich połączeń, nietypowe geolokacje/ASN, brak auth events (bo pre-auth)
Działania IR/patch
EID 1/4688 (restart usługi), systemd logs
StartInstances/StopInstances (jeśli robisz)
rollout restart, delete pod
N/A
Okno zmian + walidacja, że wersja/kompresja jest zgodna z polityką
Detekcja (praktyczne reguły)
Sigma (gotowa reguła)
Cel: wykryć hosty, na których MongoDB jest uruchamiane w sposób zwiększający ekspozycję na CVE-2025-14847 (publiczny bind i/lub jawnie włączone zlib). Uwaga: to jest detekcja „posture / hardening”, nie sygnatura exploit payload.
title: MongoDB Server Risky Startup Options (CVE-2025-14847 / zlib / public bind)
id: 3f7f2c2e-5b5c-4a6c-9b5e-6b7f9e3a8a21
status: experimental
description: >
Detects mongod/mongos started with zlib network compression enabled and/or bound to all interfaces,
increasing exposure to CVE-2025-14847 (unauth heap memory read via zlib compressed protocol).
references:
- https://nvd.nist.gov/vuln/detail/CVE-2025-14847
- https://jira.mongodb.org/browse/SERVER-115508
- https://www.mongodb.com/docs/manual/reference/configuration-options/
author: Badacz CVE
date: 2025/12/25
tags:
- attack.initial_access
- attack.t1190
logsource:
category: process_creation
product: windows
detection:
selection_image:
Image|endswith:
- '\mongod.exe'
- '\mongos.exe'
selection_public_bind:
CommandLine|contains:
- '--bind_ip_all'
- '--bind_ip 0.0.0.0'
- 'bindIpAll'
- 'bindIp: 0.0.0.0'
selection_zlib_cli:
CommandLine|contains|all:
- 'networkMessageCompressors'
- 'zlib'
selection_zlib_cfg_hint:
CommandLine|contains|all:
- 'net.compression.compressors'
- 'zlib'
condition: selection_image and (selection_public_bind or selection_zlib_cli or selection_zlib_cfg_hint)
fields:
- Image
- CommandLine
falsepositives:
- MongoDB za reverse-proxy / w prywatnej sieci, gdzie bind na 0.0.0.0 jest akceptowalny
- Środowiska, gdzie zlib jest wymagany (wydajność/kompatybilność), ale port nie jest publiczny
level: medium
Dlaczego to ma sens:zlib jest domyślnie włączony w mongod/mongos (snappy,zstd,zlib), więc realna mitigacja często polega na jego usunięciu/wyłączeniu.
Splunk (SPL)
A) Wykrywanie nieautoryzowanych źródeł łączących się do MongoDB (logi MongoDB):
index=mongodb sourcetype=mongodb:log ("connection accepted" OR "Connection accepted")
| rex field=_raw "from (?<src_ip>\d{1,3}(\.\d{1,3}){3}):(?<src_port>\d+)"
| stats count as connections dc(src_port) as uniq_src_ports by src_ip
| sort - connections
B) Bursty krótkich połączeń (sygnał skanowania / prób exploitacji pre-auth):
index=mongodb sourcetype=mongodb:log ("connection accepted" OR "end connection")
| rex field=_raw "connection accepted from (?<src_ip>\d{1,3}(\.\d{1,3}){3})"
| timechart span=5m count by src_ip limit=20
C) (Jeśli masz VPC/NSG/Firewall w Splunku) — inbound na 27017 z Internetu:
index=netflow (dest_port=27017 OR dest_port=27018) action=allowed
| stats sum(bytes) as bytes count as flows by src_ip dest_ip dest_port
| sort - flows
KQL (Azure / Microsoft Sentinel)
A) Azure Firewall (NetworkRule) — ruch do 27017/27018:
AzureDiagnostics
| where Category == "AzureFirewallNetworkRule"
| where msg_s has "Dport: 27017" or msg_s has "Dport: 27018"
| summarize flows=count() by SourceIP=src_ip_s, DestinationIP=dst_ip_s, bin(TimeGenerated, 5m)
| order by flows desc
B) Wykrywanie publicznej ekspozycji przez zmiany NSG (Activity Log):
AzureActivity
| where OperationNameValue has_any ("MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/SECURITYRULES/WRITE",
"MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/WRITE")
| where ActivityStatusValue == "Succeeded"
| where Properties has "27017" or Properties has "27018"
| project TimeGenerated, Caller, OperationNameValue, ResourceGroup, Resource, Properties
| order by TimeGenerated desc
CloudTrail query (AWS CLI/CloudWatch)
A) CloudTrail Lake (SQL) — kto otworzył MongoDB na świat:
SELECT eventTime, userIdentity.arn, sourceIPAddress, eventName, requestParameters
FROM <your_cloudtrail_lake_table>
WHERE eventName IN ('AuthorizeSecurityGroupIngress','ModifySecurityGroupRules','RevokeSecurityGroupIngress')
AND requestParameters LIKE '%27017%'
ORDER BY eventTime DESC;
B) AWS CLI (lookup-events) + filtr portów (przykład z jq):
A) Inbound connections do MongoDB z adresów publicznych (Elastic Defend / endpoint network events):
network
where event.type == "start"
and destination.port in (27017, 27018)
and network.direction == "inbound"
and not cidrMatch(source.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")
B) Start mongod/mongos z parametrami wysokiego ryzyka:
process
where event.type == "start"
and process.name in ("mongod", "mongos", "mongod.exe", "mongos.exe")
and (
process.command_line like "*bind_ip_all*" or
process.command_line like "*bind_ip 0.0.0.0*" or
process.command_line like "*networkMessageCompressors*" and process.command_line like "*zlib*"
)
Heurystyki / korelacje (co łączyć)
Asset + posture: lista instancji MongoDB + wersja + czy port publiczny + czy zlib wyłączony.
zlib jest domyślnie włączony → jeśli nie zrobiłeś hardeningu, traktuj jak „włączone”.
Netflow/VPC Flow Logs/NSG Flow Logs: wzrost liczby połączeń do 27017 z nietypowych ASN/geo + krótkie sesje.
MongoDB logs: dużo connection accepted bez towarzyszących zdarzeń auth/audit (pre-auth).
Change management: korelacja w czasie z rolloutem poprawek (upgrade/konfig) i spadkiem prób połączeń.
False positives / tuning
Typowe FP:
skanowanie wewnętrzne (CMDB, monitoring, VA tools),
load balancer / NAT pokazuje jeden adres źródłowy,
legalne aplikacje o wysokiej częstotliwości połączeń.
Tuning:
allowlist znanych CIDR aplikacji/ETL/backup,
alertuj tylko dla źródeł spoza prywatnych zakresów,
progi: np. >N nowych IP w 10 minut lub >X połączeń/IP/5 min.
Playbook reagowania
Triage ekspozycji
Sprawdź, czy MongoDB jest Internet-facing (SG/NSG/Firewall/Ingress).
Natychmiastowa mitigacja (jeśli nie możesz patchować „teraz”)
Wyłącz zlib w kompresji sieciowej, ustawiając kompresory na snappy,zstd albo disabled.
Przykład (wariant uruchomieniowy):mongod --networkMessageCompressors snappy,zstd # albo całkowicie: mongod --networkMessageCompressors disabled
Remediacja docelowa
Upgrade do wersji naprawionej (jw.).
Hunting / impact assessment
Przejrzyj logi połączeń do 27017 (źródła, wolumeny, okna czasowe).
Jeśli DB była publiczna: potraktuj to jak incydent „potential data exposure”.
Rotacja sekretów (jeśli ekspozycja była realna)
Rotuj hasła użytkowników DB, klucze aplikacyjne, tokeny (w zależności od tego, co mogło znaleźć się w pamięci procesu).
Wymuś TLS + auth + segmentację sieci (minimalny blast radius).
Przykłady z kampanii / case studies
Brak publicznie potwierdzonych kampanii APT/ransomware wykorzystujących CVE-2025-14847 „w dziczy” na moment publikacji źródeł; MongoDB wskazywał, że w Atlas „nie ma dowodów” na wykorzystanie ani kompromitację danych i że flota została spatchowana.
Ten CVE jest jednak modelowym przykładem ryzyka T1190 dla baz danych (public-facing socket + bug w parserze/protokole).
Lab (bezpieczne testy) — przykładowe komendy
Sprawdź, czy serwer nadal pozwala na zlib
Ponieważ pole hello.compression pojawia się tylko, gdy kompresja jest używana, wymuś po stronie klienta zlib i zobacz, czy serwer je negocjuje.
Dlaczego nie „RCE” w mapowaniu? Opis CNA/NVD mówi o odczycie niezainicjalizowanej pamięci (information disclosure), a wektor CVSS v3.1 ma I:N/A:N — to nie jest opis skutku typu „arbitrary code execution”.
Mitigations (praktycznie):
Patch management / szybka aktualizacja wersji naprawionych
Ograniczenie ekspozycji (SG/NSG/Firewall/NetworkPolicy), zasada „DB nie jest publiczna”
Wyłączenie zlib (czasowo lub polityką) — snappy,zstd albo disabled
Powiązane techniki (łańcuchowo, zależnie od tego co wycieknie):
Potencjalnie: nadużycie ujawnionych sekretów → Valid Accounts (T1078) (jeśli wyciek umożliwi logowanie innymi kanałami). (To zależne od środowiska; sam CVE nie gwarantuje przejęcia kont.)
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
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):
