Archiwa: NIST - Strona 59 z 69

CVE-2025-14847 (MongoDB Server) — wyciek pamięci heap przez zlib w protokole MongoDB

TL;DR

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

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

Obszar obserwacji	Windows EID (przykłady)	CloudTrail (AWS)	K8s Audit	M365 operations	Co zbierać / na co patrzeć
Ekspozycja portu MongoDB (27017/27018)	Sysmon EID 3 (NetworkConnect), Windows Filtering Platform 5156	`AuthorizeSecurityGroupIngress`, `ModifySecurityGroupRules`, `RevokeSecurityGroupIngress`	`patch`/`create` `Service` (LoadBalancer/NodePort), `Ingress`, `NetworkPolicy`	N/A	Skoki nowych źródeł łączących się do 27017; ruch z Internetu do DB zamiast z warstwy app
Start procesu MongoDB i parametry ryzyka	Sysmon EID 1 (ProcessCreate), Security 4688	N/A	`create`/`patch` `Deployment/StatefulSet` (args/env/config)	N/A	Czy `mongod/mongos` startuje z `--bind_ip_all` / `0.0.0.0` oraz czy wymuszasz wyłączenie `zlib`
Zmiany konfiguracji kompresji	EID 1/4688 + (opcjonalnie) audyt plików `mongod.conf`	N/A	zmiany ConfigMap/Secret montowanych do poda	N/A	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):

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AuthorizeSecurityGroupIngress \
  --start-time 2025-12-01T00:00:00Z \
  --end-time   2025-12-25T23:59:59Z \
  --max-results 50 \
| jq -r '.Events[]
  | select(.CloudTrailEvent | test("27017|27018"))
  | [.EventTime, .Username, .EventName] | @tsv'

Elastic (EQL) przykłady

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).
- Jeśli tak: priorytet P1 (T1190).
Weryfikacja wersji
- Na hoście:mongod --version mongos --version
- Porównaj z wersjami naprawionymi: 8.2.3 / 8.0.17 / 7.0.28 / 6.0.27 / 5.0.32 / 4.4.30.
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.
- Przykład:mongosh "mongodb://<host>:27017/?compressors=zlib" --eval 'db.hello()'
- Jeśli w wyniku pojawia się "compression": ["zlib"], to zlib jest aktywnie używane (czyli mitigacja nie została wdrożona).
Weryfikacja domyślnej listy kompresorów (dla wiedzy operacyjnej)
- MongoDB domyślnie: snappy,zstd,zlib.
Weryfikacja ustawień w pliku konfiguracyjnymsudo grep -n "compression" -n /etc/mongod.conf sudo grep -n "bindIp" -n /etc/mongod.conf
K8s: sprawdź argumenty/ConfigMapkubectl -n <ns> get sts <mongo-sts> -o yaml | grep -n "networkMessageCompressors" -n kubectl -n <ns> get cm -o yaml | grep -n "net.compression" -n

Mapowania (Mitigations, Powiązane techniki)

ATT&CK (główne):

T1190 Exploit Public-Facing Application → TA0001 Initial Access

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

Źródła / dalsza literatura

NVD: opis, CVSS, wersje podatne, CWE-130 (NVD)
MongoDB JIRA SERVER-115508: fix/upgrade + workaround (wyłączenie zlib) (MongoDB Jira)
MongoDB Alerts (CVE-2025-14847): oficjalny wpis „Zlib … may allow memory read” + zakresy wersji (MongoDB)
MongoDB Docs: domyślne snappy,zstd,zlib (mongod/mongos) (MongoDB)
MongoDB Docs: hello.compression (walidacja negocjacji kompresji) (MongoDB)
MITRE ATT&CK: T1190 (tactic Initial Access, last modified) (MITRE ATT&CK)
MongoDB Community Hub: komunikat o spatchowaniu Atlas + brak dowodów exploitacji (wg MongoDB) (MongoDB)

Checklisty dla SOC / CISO

SOC (operacyjnie, dziś):

Zidentyfikuj wszystkie mongod/mongos i ich wersje.
Sprawdź ekspozycję 27017/27018 (Internet-facing = P1).
Jeśli nie możesz patchować natychmiast: usuń zlib z kompresorów (snappy,zstd lub disabled).
Wdróż detekcje: bursty połączeń, nowe źródła, zmiany SG/NSG.
Jeśli DB była publiczna: threat hunting + ocena ryzyka wycieku danych.

CISO / Risk:

Wymuś politykę: „bazy danych nie mają publicznych endpointów”.
SLA na patchowanie krytycznych/High dla usług publicznych.
Segmentacja sieci + Zero Trust dla dostępu do DB.
Standard hardening MongoDB: auth/TLS, ograniczenia kompresji, monitoring i centralne logowanie.

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

TL;DR

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

Krótka definicja techniczna

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

Gdzie występuje / przykłady platform

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

Szczegółowy opis techniki

Jak to działa (perspektywa defensywna)

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

Cele atakującego

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

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

Dlaczego jest skuteczna

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

Artefakty i logi

Źródło / 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.

False positives / tuning

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

Playbook reagowania (kroki + komendy)

1) Identyfikacja i triage

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

2) Natychmiastowe ograniczenie ekspozycji (kompensacja)

Zgodnie z zaleceniami w advisory:

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

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

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

3) Polowanie (hunting)

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

4) Jeśli podejrzenie kompromitacji

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

Przykłady z kampanii / case studies

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

Lab (bezpieczne testy) — przykładowe komendy

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

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

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

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

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

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

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

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

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

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

Mapowania (Mitigations, Powiązane techniki)

MITRE ATT&CK (ICS) – techniki

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

MITRE – przykładowe mitigacje dla T0819 (ICS)

Z karty T0819 jako szczególnie sensowne dla smartRTU:

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

Powiązane konteksty podatności

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

Źródła / dalsza literatura

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

Checklisty dla SOC / CISO

SOC (operacyjnie)

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

CISO / właściciel ryzyka

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

MongoDB: CVE-2025-14847 (zlib) – pilna łatka, bo luka może posłużyć do ataków zdalnych, także w scenariuszach RCE

Wprowadzenie do problemu / definicja luki

MongoDB opublikowało pilne ostrzeżenie dotyczące podatności CVE-2025-14847, która dotyczy obsługi kompresji zlib w protokole sieciowym MongoDB. Luka umożliwia zdalnemu, nieuwierzytelnionemu klientowi doprowadzenie do odczytu niezainicjalizowanej pamięci sterty (heap), a według komunikacji o ryzyku – może być wykorzystywana także w łańcuchach prowadzących do zdalnego wykonania kodu (RCE).

W skrócie

Identyfikator: CVE-2025-14847
Mechanizm: niespójne pola długości w nagłówkach protokołu dla danych skompresowanych zlib → możliwy odczyt niezainicjalizowanej pamięci heap bez logowania
Wektor: zdalnie przez sieć, bez interakcji użytkownika; ocena producenta CVSS v4: 8.7 (HIGH) oraz CVSS v3.1: 7.5 (HIGH)
Naprawa: aktualizacja do wydań: 8.2.3 / 8.0.17 / 7.0.28 / 6.0.27 / 5.0.32 / 4.4.30
Mitigacja awaryjna: wyłączenie zlib w konfiguracji kompresji (networkMessageCompressors / net.compression.compressors)

Kontekst / historia / powiązania

W krótkim komunikacie MongoDB podkreśla, że Atlas (flota zarządzana) został już załatany, a na moment publikacji nie ma dowodów na wykorzystanie luki ani kompromitację danych klientów. Jednocześnie dla środowisk self-hosted udostępniono poprawki dla wspieranych linii (co najmniej 4.4–8.0) i zalecono szybką aktualizację.

Równolegle advisory w JIRA (SERVER-115508) jest bardzo bezpośrednie: to „critical fix” i rekomendacja brzmi „upgrade immediately”, z awaryjną opcją wyłączenia zlib, jeśli nie da się podnieść wersji od razu.

Analiza techniczna / szczegóły luki

Co dokładnie jest podatne?

Podatność wynika z błędnej obsługi niespójności parametrów długości (CWE-130) w kontekście nagłówków protokołu MongoDB dla komunikatów skompresowanych zlib. W praktyce „mismatched length fields” mogą spowodować, że serwer zwróci do klienta fragmenty niezainicjalizowanej pamięci heap.

Dlaczego to jest niebezpieczne, skoro opis mówi o „read”?

Opis CVE wprost wskazuje na wyciek pamięci (wysoki wpływ na poufność, brak wpływu na integralność/dostępność w wektorach CVSS).
Natomiast komunikacja do administratorów akcentuje, że jest to podatność, którą można wykorzystać w atakach zdalnych na serwery – a w relacjach i ostrzeżeniach podkreślono potencjał użycia jej w scenariuszach RCE (np. jako element łańcucha eksploatacji).

Jakie wersje są dotknięte?

Zakres wersji obejmuje wiele gałęzi MongoDB, w tym także stare linie „MongoDB Server” (3.6/4.0/4.2). W skrócie: podatne są m.in. 4.4.0–4.4.29, 5.0.0–5.0.31, 6.0.0–6.0.26, 7.0.0–7.0.26, 8.0.0–8.0.16, 8.2.0–8.2.3 oraz wszystkie wydania gałęzi 3.6/4.0/4.2.

Praktyczne konsekwencje / ryzyko

Wyciek wrażliwych danych z pamięci procesu
Niezainicjalizowana pamięć heap potrafi zawierać „resztki” danych przetwarzanych przez proces: fragmenty dokumentów, metadane zapytań, elementy buforów sieciowych itp. To klasyczny wektor pod podniesienie skuteczności dalszych ataków (rozpoznanie, omijanie mechanizmów losowania/ochron, wycieki danych).
Ryzyko eskalacji do bardziej destrukcyjnych scenariuszy
Choć rdzeń CVE opisuje wyciek pamięci, komunikaty o „patch now” podkreślają, że podatność jest atrakcyjna operacyjnie (zdalnie, bez auth, niska złożoność) i może być łączona w łańcuchy prowadzące do przejęcia serwera. Z perspektywy obrony – to wystarczający powód, by traktować ją jak incydent „priorytet P1”.
Najbardziej narażone środowiska
- self-hosted MongoDB wystawione do Internetu (albo dostępne z sieci o niskim zaufaniu),
- klastry z włączoną kompresją i dopuszczające zewnętrznych klientów,
- środowiska legacy (3.6/4.0/4.2), gdzie sama modernizacja bywa trudna, ale ryzyko – największe.

Rekomendacje operacyjne / co zrobić teraz

1) Patch – docelowa i najlepsza ścieżka

Zaktualizuj do wersji naprawionych (zgodnie z linią wydaniową):

8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, 4.4.30

2) Mitigacja awaryjna, gdy nie możesz patchować „tu i teraz”

MongoDB zaleca wyłączenie zlib poprzez konfigurację kompresji i pozostawienie np. snappy,zstd albo całkowite wyłączenie kompresji.
Przykładowo (konceptualnie): ustaw networkMessageCompressors / net.compression.compressors tak, aby nie zawierało zlib.

3) Szybkie twardnienie ekspozycji (równolegle)

Nawet po aktualizacji (albo do czasu okna serwisowego) warto:

odciąć dostęp do mongod/mongos od Internetu (firewall / security groups / allowlist),
ograniczyć dostęp wyłącznie do sieci aplikacyjnych (zasada minimalnej ekspozycji),
zweryfikować, czy nie utrzymujesz produkcyjnie niewspieranych gałęzi 3.6/4.0/4.2 – one są wprost oznaczone jako dotknięte.

4) Detekcja i IR – minimum sensowne w 24h

zinwentaryzuj wersje i sprawdź, czy kompresja zlib jest używana,
przejrzyj logi pod kątem nietypowych połączeń z nieznanych ASN/IP i skoków błędów/protokołu,
jeśli masz audyt/telemetrię na hostach DB: zwróć uwagę na anomalie w procesie mongod (nietypowe zużycie CPU/RAM, restarty, crashe), choć sam CVE nie jest opisany jako DoS. (To bardziej „higiena operacyjna” niż gwarantowana sygnatura).

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

To nie jest „klasyczny RCE” w opisie CVE. Wektory CVSS od MongoDB wskazują przede wszystkim na wysoki wpływ na poufność (wyciek pamięci).
Mimo to komunikacja do administratorów jest w tonie „patch natychmiast”, bo wycieki pamięci bywają paliwem dla dalszej eksploatacji (np. do stabilizacji kolejnych etapów ataku). Dlatego w praktyce SOC/IT powinny traktować to jak podatność o wysokim priorytecie – szczególnie przy ekspozycji zdalnej i braku uwierzytelnienia.

Podsumowanie / kluczowe wnioski

CVE-2025-14847 uderza w sam „transport” danych MongoDB (kompresja zlib), umożliwiając zdalny, nieuwierzytelniony wyciek pamięci heap. Skala dotyczy wielu wersji, w tym gałęzi legacy. Najbezpieczniejsza strategia to natychmiastowy upgrade do wersji naprawionych, a jeśli to niemożliwe – wyłączenie zlib jako środek doraźny i ograniczenie ekspozycji sieciowej.

Źródła / bibliografia

BleepingComputer – „MongoDB warns admins to patch severe RCE flaw immediately” (24.12.2025). (BleepingComputer)
MongoDB Community Hub – „Important MongoDB patch available” (24.12.2025). (MongoDB)
NVD (NIST) – CVE-2025-14847 (opis, zakres wersji, CVSS). (NVD)
CVE AWG (MITRE API) – rekord CVE-2025-14847 (metadane, CVSS, affected). (CVE Advocacy)
MongoDB JIRA – SERVER-115508 (advisory, workaround, wersje naprawione). (MongoDB Jira)

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

TL;DR

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

Krótka definicja techniczna

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

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

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

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

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

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

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

Artefakt / sygnał	EID (Windows)	CloudTrail events (AWS)	K8s audit	M365 operations	Gdzie szukać / komentarz
`iked`: “Received peer certificate chain is longer than 8…”	—	—	—	—	Syslog/Traffic Monitor z Firebox (domyślny error level). To vendor opisuje jako medium indicator of attack.
`iked`: “IKE_AUTH request … CERT(sz=3000) …” i CERT > 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.

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

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

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

Elastic/EQL przykłady

Kibana KQL (syslog z Firebox):

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

EQL (jeśli masz ustandaryzowane pola):

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

Heurystyki / korelacje

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

Proponowane łańcuchy:

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.
Sprawdź, czy masz IKEv2 (Mobile VPN IKEv2 / BOVPN IKEv2, dynamic peer).
Hunting po IoA logach (iked) i połączeniach do IP z advisory.

Krok 1 — containment (minimalizuj powierzchnię ataku)

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

Krok 2 — eradication (patch/upgrade)

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

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

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

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

Krok 4 — post-incident hardening

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

Przykłady z kampanii / case studies

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

Lab (bezpieczne testy) — przykładowe komendy

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

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

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

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

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

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

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

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

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

Mapowania (Mitigations, Powiązane techniki)

MITRE ATT&CK (technika główna)

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

MITRE Mitigations (praktyczne dla CVE-2025-14733)

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

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

Powiązane techniki (kontekstowe)

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

Źródła / dalsza literatura

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

Checklisty dla SOC / CISO

SOC (operacyjnie)

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

CISO / właściciel ryzyka

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

CVE-2025-68613 (n8n)

TL;DR

CVE: CVE-2025-68613 — krytyczne RCE w platformie automatyzacji workflow n8n (expression evaluation / expression injection), wymagające uwierzytelnienia użytkownika (PR:L).
Wpływ: wykonanie dowolnego kodu z uprawnieniami procesu n8n → potencjalne przejęcie instancji, modyfikacje workflow, dostęp do danych/sekretów.
Wersje podatne: >= 0.211.0 oraz < 1.120.4 (oraz osobna gałąź >= 1.121.0 i < 1.121.1)`.
Wersje naprawione: 1.120.4, 1.121.1, 1.122.0; rekomendacja maintainerów: upgrade do 1.122.0+ (dodatkowe zabezpieczenia).
CVSS (CNA/GitHub): 9.9 CRITICAL, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.
MITRE ATT&CK mapowanie (główne): T1190 Exploit Public-Facing Application (takt. Initial Access). ATT&CK v18, technika T1190 v2.8, Last Modified: 24 Oct 2025.
Ryzyko „skali Internetu”: Censys raportował ~103,476 potencjalnie podatnych instancji (stan na 22 grudnia 2025) oraz „no known exploitation at time of writing”.

Krótka definicja techniczna

T1190 (Exploit Public-Facing Application) to technika Initial Access, w której atakujący wykorzystuje lukę w aplikacji/usłudze wystawionej na Internet (lub szerzej: osiągalnej z sieci), aby uzyskać dostęp i uruchomić kod w kontekście tej aplikacji. W przypadku CVE-2025-68613 wektor jest sieciowy, a „wejściem” są workflow expressions w n8n oceniane w kontekście niedostatecznie odizolowanym od runtime, co daje RCE z uprawnieniami procesu n8n.

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

Typowe środowiska dla n8n + ryzyko T1190/CVE-2025-68613:

Windows: n8n jako proces node.exe/usługa; detekcja głównie po process creation (4688/Sysmon EID 1) i anomaliach w ruchu wychodzącym.
Linux: najczęściej spotykane wdrożenie (bare metal/VM/containers); detekcja po execve (auditd) i potomkach procesu node.
K8s (EKS/AKS/GKE): n8n jako Deployment/StatefulSet; ślady w K8s audit, logach Ingress (nginx/traefik), oraz w telemetrii runtime (Falco/eBPF).
AWS: n8n na EC2/ECS/EKS; ryzyko wzrasta, jeśli instancja ma rolę IAM (po RCE możliwa kradzież tokenów z metadata). T1190 wspiera platformy IaaS/Containers.
Azure: n8n na VM/AKS; analogicznie — MDE/AMA/Defender for Cloud do korelacji procesu i sieci.
GCP: n8n na GCE/GKE; analogicznie — Cloud Logging + VPC Flow Logs + GKE audit.
ESXi: n8n uruchomione jako VM; kontekst T1190 obejmuje również ESXi jako platformę (ogólnie dla public-facing usług).
AD: sama luka nie jest „AD-specific”, ale dostęp uwierzytelniony bywa pochodną kompromitacji tożsamości/SSO. W praktyce koreluj: logowanie do n8n ↔ zmiany workflow ↔ zdarzenia na hostach domenowych, jeśli n8n ma integracje.
M365: jeśli n8n przechowuje tokeny do M365 (Graph/Exchange/SharePoint), po przejęciu instancji ryzykujesz nadużycie tych tokenów; szukaj anomalii w M365 Unified Audit Log (operacje administracyjne, nietypowe OAuth usage).

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

Mechanika (na przykładzie n8n i CVE-2025-68613)

Warunek wstępny: atakujący posiada dostęp uwierzytelniony do n8n (PR:L).
Punkt wejścia: podczas konfiguracji workflow wprowadzane są expressions (np. w polach korzystających z expression engine).
Błąd izolacji: w podatnych wersjach expression evaluation może odbywać się w kontekście niewystarczająco odizolowanym od runtime (CWE-913).
Efekt: możliwość uruchomienia dowolnego kodu z uprawnieniami procesu n8n → odczyt/zmiana workflow, dostęp do danych, potencjalne operacje systemowe.

Dlaczego to jest skuteczne w realnym środowisku

n8n bywa wystawiane na Internet (panel edycji, webhooki, API), a workflow często przechowują sekrety i integracje (SaaS, chmury).
Wymóg uwierzytelnienia nie „ratuje” sytuacji, jeśli:
- konta są współdzielone,
- brak MFA,
- jest SSO z podatnym IdP,
- dochodzi do przejęcia sesji/tokenów.
Skuteczność rośnie, gdy proces n8n działa z szerokimi uprawnieniami (np. root w kontenerze, dostęp do socketa Dockera, dostęp do metadata/roli IAM, szeroki egress).

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

Warstwa	Źródło logów / artefakt	ID / typ zdarzenia	Co polować (IOA)
Aplikacja	n8n logs (console/file, najlepiej `json`)	[brak EID]	Nagłe błędy evaluatora, nietypowe pola expressions, wzrost błędów 5xx w UI/API; ustaw `N8N_LOG_FORMAT=json` dla parsowalności.
Aplikacja	n8n “Security audit” (`n8n audit`, `/audit`)	[raport]	Wykrycie ryzykownych node’ów, niechronionych webhooków, brakujących ustawień, „outdated instance”.
Reverse proxy/WAF	Nginx/Traefik/ALB/Ingress access logs	HTTP access	Sekwencja: logowanie → edycja workflow/API → błędy 5xx/4xx → chwilę później anomalie procesowe/egress (korelacja).
Windows	Security	4688	`node.exe`/`n8n` uruchamia `cmd.exe`, `powershell.exe` lub narzędzia sieciowe (nietypowe dla automatyzacji).
Windows	Sysmon	EID 1, 3, 11	Process create + network connect + file create w krótkim oknie czasu po zmianie workflow.
Linux	auditd	`execve`, `connect`	Proces `node` (n8n) spawn’uje `/bin/sh`, interpretery, pobiera pliki, tworzy cron/systemd.
K8s	K8s audit log	`create`/`patch`/`exec`	Niespodziewane `pods/exec`, zmiany w Deployment/Secret/ConfigMap po incydencie (jeśli atak eskaluje do K8s API).
AWS	CloudTrail	`AssumeRole`, `GetCallerIdentity`, `List`, `Get`, `Put*`	Nietypowe użycie roli/kluczy przypisanych do n8n/instancji po symptomach RCE (szczególnie STS).
M365	Unified Audit Log	Operacje Exchange/SharePoint/Entra	Skok w aktywności aplikacji/OAuth (jeśli w n8n były tokeny do M365) — koreluj czasowo z przejęciem instancji.

Uwaga: część wpisów (CloudTrail/M365/K8s) jest warunkowa — zależy od tego, jakie integracje i uprawnienia ma n8n w Twoim środowisku.

Detekcja (praktyczne reguły)

Sigma (gotowa reguła)

title: Suspicious child process spawned by n8n / Node.js (possible n8n RCE - CVE-2025-68613)
id: 3e7b6d6a-3a33-4a23-9a9a-2c7e3b6f4c11
status: experimental
description: >
  Detects suspicious process spawning patterns where a Node.js-based n8n service spawns shells
  or common system utilities. Useful as a post-exploitation signal for CVE-2025-68613.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2025-68613
author: Badacz CVE (SOC/Blue Team)
date: 2025/12/24
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\node.exe'
      - '\n8n.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\bitsadmin.exe'
      - '\certutil.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate automation that intentionally executes OS commands from workflows (high-risk design).
  - Maintenance scripts launched by the n8n service account.
level: high

Splunk (SPL)

Przykład dla Sysmon (EID 1) lub równoważnych zdarzeń procesu:

index=endpoint (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1)
(
  ParentImage="*\\node.exe" OR ParentImage="*\\n8n.exe" OR ParentCommandLine="* n8n *"
)
(
  Image="*\\cmd.exe" OR Image="*\\powershell.exe" OR Image="*\\pwsh.exe" OR Image="*\\wscript.exe" OR Image="*\\cscript.exe"
  OR Image="*\\bitsadmin.exe" OR Image="*\\certutil.exe" OR Image="*\\mshta.exe" OR Image="*\\rundll32.exe"
)
| stats count min(_time) as first_seen max(_time) as last_seen values(Computer) values(User) values(ParentCommandLine) values(CommandLine) by Image, ParentImage
| convert ctime(first_seen) ctime(last_seen)

KQL (Azure / Microsoft Defender for Endpoint)

Wariant oparty o DeviceProcessEvents:

DeviceProcessEvents
| where InitiatingProcessFileName in~ ("node.exe", "node", "n8n.exe", "n8n")
| where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe","wscript.exe","cscript.exe","bash","sh")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, FolderPath, SHA256
| order by Timestamp desc

CloudTrail query (AWS CLI/CloudWatch)

CloudWatch Logs Insights (przykład “polowania” na nietypowe STS/Identity po objawach kompromitacji aplikacji):

fields @timestamp, eventSource, eventName, userIdentity.type, userIdentity.arn, sourceIPAddress, userAgent
| filter eventSource in ("sts.amazonaws.com","iam.amazonaws.com")
| filter eventName in ("AssumeRole","GetCallerIdentity","CreateAccessKey","PutUserPolicy","AttachRolePolicy")
| sort @timestamp desc
| limit 200

AWS CLI (jeśli trzymasz CloudTrail w S3 i masz Athena/Glue — tutaj tylko “szkielet”; dostosuj do swojego źródła logów):

# Wyszukaj zdarzenia STS dla roli/ARN powiązanej z n8n (uzupełnij <ROLE_ARN_FRAGMENT>)
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=sts.amazonaws.com \
  --max-results 50 \
| jq '.Events[] | select(.CloudTrailEvent | contains("<ROLE_ARN_FRAGMENT>"))'

Elastic/EQL przykłady

EQL dla Elastic Endpoint / logs-*:

process
where event.type == "start"
  and process.parent.name in ("node","node.exe","n8n","n8n.exe")
  and process.name in ("cmd.exe","powershell.exe","pwsh.exe","bash","sh","wscript.exe","cscript.exe")

Heurystyki / korelacje (co łączyć)

Najlepiej działa korelacja „multi-sygnał” (T1190), zgodna z ideą: request → error → post-exploit behavior:

Ingress/WAF/Reverse proxy: nietypowe żądania do n8n + skok 4xx/5xx.
Aplikacja: logi n8n (w JSON) pokazują wzmożoną aktywność edycji/uruchomień workflow albo błędy w evaluacji.
Host/Container: proces node zaczyna tworzyć nietypowe potomki (shell/interpretery) w krótkim oknie czasu po anomaliach HTTP.
Egress: nowe połączenia wychodzące (szczególnie do Internetu lub do usług typu metadata 169.254.169.254 w chmurach — jeśli środowisko to umożliwia).
MITRE opisuje taki łańcuch korelacyjny jako skuteczną strategię detekcji dla T1190 (również dla aplikacji kontenerowych i chmurowych).

False positives / tuning

Najczęstsze źródła FP:

Środowiska, w których n8n z założenia uruchamia polecenia systemowe (workflow jako „orchestrator” hosta).
Zadania administracyjne (backup, eksport, maintenance) wykonywane przez konto serwisowe n8n.

Tuning praktyczny:

Dodaj warunek kontekstu: alertuj tylko, jeśli parent=Node/n8n uruchamia shell i jednocześnie:
- jest „nowy” zewnętrzny kierunek egress,
- wystąpił spike 5xx,
- zaszła zmiana workflow/aktywacja workflow w nietypowych godzinach.
Wykorzystaj n8n audit do identyfikacji “risky nodes”/niechronionych webhooków i potraktuj je jako wskaźnik podwyższonego ryzyka (priorytetyzacja instancji do hardeningu).

Playbook reagowania (kroki + komendy)

Krok 1 — identyfikacja narażenia (scoping)

Sprawdź wersję n8n i porównaj z zakresem podatności oraz wersjami naprawionymi.
Jeśli korzystasz z logów plikowych/JSON — upewnij się, że logowanie jest włączone i parsowalne (np. N8N_LOG_FORMAT=json, N8N_LOG_OUTPUT=file).

Przykładowe komendy (Linux/Docker, defensywne):

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
docker inspect <n8n_container> --format '{{.Config.Image}}'
docker logs <n8n_container> --since 24h | tail -n 200

Krok 2 — natychmiastowe ograniczenie ryzyka (containment)

Zalecenia workarounds od maintainerów (tymczasowe, gdy nie możesz patchować od razu):

Ogranicz prawa do tworzenia/edycji workflow wyłącznie do w pełni zaufanych użytkowników.
Uruchom n8n w środowisku utwardzonym: najmniejsze uprawnienia OS, segmentacja, ograniczony egress.

Krok 3 — zebranie materiału dowodowego

Zbierz: logi reverse proxy/WAF, logi n8n (najlepiej JSON), zdarzenia procesów na hoście, listę aktywnych połączeń, listę zmienionych plików w ostatnich 24–72h.

Przykładowe komendy (Linux):

# połączenia i procesy (triage)
ss -tpn
ps -eo pid,ppid,user,cmd --sort=-%cpu | head

# szybkie polowanie na świeże pliki (dostosuj ścieżki do wdrożenia)
find / -xdev -mtime -2 -type f 2>/dev/null | head

Krok 4 — eradication i recovery

Upgrade do wersji naprawionej: 1.120.4 / 1.121.1 / 1.122.0, preferencyjnie 1.122.0+.
Jeśli podejrzewasz przejęcie: potraktuj instancję jak „burned”:
- rotuj sekrety/tokenu API używane w workflow,
- wymuś reset sesji/kont,
- rozważ redeploy z czystego obrazu + odtworzenie workflow z zaufanego backupu.

Krok 5 — działania po incydencie (hardening)

Odnieś się do mitigations dla T1190:

Update Software (M1051) + procedury szybkiego patchowania,
Network Segmentation (M1030) / DMZ,
Filter Network Traffic (M1037) (szczególnie outbound),
Application Isolation and Sandboxing (M1048).

Przykłady z kampanii / case studies

Skala ekspozycji: Censys raportował 103,476 potencjalnie podatnych instancji (stan na 22 grudnia 2025), co typowo napędza skanowanie oportunistyczne po publikacji krytycznego RCE.
Status exploitacji: według Censys (22 grudnia 2025) „No known exploitation at time of writing” — to nie jest gwarancja bezpieczeństwa, ale ważny punkt odniesienia w komunikacji ryzyka.
Disclosure: advisory na GitHub opublikowano 19 grudnia 2025, jako krytyczne, z przypisaniem CWE-913 i wskazaniem patched versions.

Lab (bezpieczne testy) — przykładowe komendy

Poniżej bezpieczne testy dla zespołu SOC/Blue Team (bez payloadów i bez instrukcji exploitacji):

Weryfikacja konfiguracji logowania (parsowalność pod SIEM)
Zgodnie z dokumentacją n8n ustaw logi na JSON i wyjście do pliku/console (w zależności od wdrożenia).

export N8N_LOG_FORMAT=json
export N8N_LOG_OUTPUT=console,file
export N8N_LOG_LEVEL=info

Uruchomienie security audytu n8n
To test „higieny” instancji (risky nodes, niechronione webhooki, outdated instance).

# w środowisku testowym / na kopii instancji
n8n audit

Test detekcji post-exploit (symulacja TTP bez exploita)

W labie sprawdź, czy Twoje EDR/SIEM podnosi alert, gdy proces node uruchamia nieoczekiwany interpreter/shell (symulacja kontrolowana przez administratora labu).
Celem jest walidacja reguł Sigma/SPL/KQL/EQL z sekcji 7.

Mapowania (Mitigations, Powiązane techniki)

Mitigations dla T1190 (MITRE)

Z techniki T1190 wynikają szczególnie praktyczne mitygacje:

M1048 Application Isolation and Sandboxing
M1050 Exploit Protection (np. WAF)
M1037 Filter Network Traffic (zwłaszcza outbound z serwera aplikacji)
M1035 Limit Access to Resource Over Network
M1030 Network Segmentation
M1026 Privileged Account Management (least privilege konta usługi)
M1051 Update Software
M1016 Vulnerability Scanning

Powiązane techniki (praktyczne mapowanie łańcucha zdarzeń)

T1190 Exploit Public-Facing Application (główne; wejście przez podatną instancję n8n).
T1078 Valid Accounts (wymóg uwierzytelnienia w CVE sugeruje nadużycie kont/poświadczeń jako warunek).
T1059 Command and Scripting Interpreter (częsty etap po RCE: uruchamianie poleceń/interpreterów).
Dalsze (zależne od scenariusza): credential access, lateral movement, collection — zależnie od tego, jakie integracje i sekrety przechowuje n8n.

Źródła / dalsza literatura

MITRE ATT&CK: T1190 Exploit Public-Facing Application (ATT&CK v18; Last Modified 24 Oct 2025). (MITRE ATT&CK)
NVD: CVE-2025-68613 (opis, CVSS z CNA/GitHub, wektor). (NVD)
GitHub Security Advisory (n8n): GHSA-v98v-ff95-f3cp (affected/patched, workarounds, CWE-913). (GitHub)
Censys advisory: ekspozycja i status exploitacji (stan na 22 Dec 2025). (Censys)
n8n Docs: Logging oraz zmienne środowiskowe logów (N8N_LOG_FORMAT, N8N_LOG_LEVEL, itp.). (n8n Docs)
n8n Docs: Security audit (n8n audit, /audit). (n8n Docs)

Checklisty dla SOC / CISO

SOC (operacyjnie)

Zidentyfikuj instancje n8n wystawione na Internet (ASM/CMDB) i sprawdź wersje vs zakres podatności.
Włącz/utwardź logowanie n8n (JSON + centralizacja do SIEM).
Wdróż reguły na process spawning (node→shell) + korelacje request→error→post-exploit.
Przejrzyj uprawnienia użytkowników: kto może tworzyć/edytować workflow; ogranicz do zaufanych ról.
Po patchu: retrospektywnie przeszukaj logi od 2025-12-19 (data disclosure) pod kątem anomalii.

CISO (zarządczo)

Egzekwuj patch management dla internet-facing apps (SLA dla CRITICAL).
Wymuś segmentację i ograniczenie egress dla usług automatyzacji (n8n jako high-risk).
Zdefiniuj standard: workflow automation nie działa jako root i nie ma szerokich uprawnień do chmury bez potrzeby.
Włącz okresowy security audit instancji (w tym “risky nodes”/webhook exposure).

CISA dopisuje DigiEver DS-2105 Pro do KEV: CVE-2023-52163 aktywnie wykorzystywana, a sprzęt jest EOL

Wprowadzenie do problemu / definicja luki

CVE-2023-52163 to podatność w rejestratorach wideo NVR/DVR DigiEver DS-2105 Pro, którą CISA uznała za aktywnie wykorzystywaną w atakach i dodała do katalogu Known Exploited Vulnerabilities (KEV) 22 grudnia 2025 r. (z federalnym terminem działań do 12 stycznia 2026 r.).

Problem jest szczególnie niebezpieczny, bo dotyczy urządzeń z obszaru fizycznego bezpieczeństwa (monitoring IP) — a te często stoją „na uboczu” procesów patch managementu.

W skrócie

Co to jest? Luka umożliwiająca wykonanie poleceń systemu (command injection) powiązana z brakami w autoryzacji (CWE-862) w DS-2105 Pro.
Identyfikator: CVE-2023-52163, CVSS 3.1: 8.8 (High) wg danych CISA-ADP w NVD.
Wektor/warunki: sieć, niska złożoność, zwykle wymagane „niskie uprawnienia” (np. zalogowanie / ważna sesja), co w praktyce bywa osiągane przez domyślne hasła lub przejęte konta.
Status naprawy: urządzenie/linia jest EOL; sygnalizowany brak wsparcia i poprawek od producenta.
Dlaczego teraz głośno? Bo KEV = „to nie jest teoria” — jest dowód realnej eksploatacji, a kampanie IoT/botnetowe już wcześniej celowały w te klasy urządzeń.

Kontekst / historia / powiązania

Geneza tematu sięga badań i obserwacji ruchu botnetowego. Akamai opisało, że ich zespół SIRT zauważył próby wykorzystania podatności przeciw urządzeniom DigiEver w honeypotach już 18 listopada 2024 r., łącząc je z kampanią Mirai oraz modyfikacjami malware (m.in. nowsze algorytmy szyfrowania).

TXOne (autor badań Ta-Lun Yen) wskazywał, że błędy były raportowane wcześniej (2023), a odpowiedź producenta miała sprowadzać się do stwierdzenia, że produkt jest „off the shelf” od lat, co utrudnia liczenie na oficjalny fix.

W grudniu 2025 r. temat wraca na czołówki, bo CISA dopisuje CVE-2023-52163 do KEV, formalnie podbijając priorytet usuwania/mitigacji w organizacjach.

Analiza techniczna / szczegóły luki

Co psuje się w praktyce?
Opis podatności wskazuje na możliwość command injection w kontekście CGI — w szczególności w komponencie/akcji powiązanej z time_tzsetup.cgi (konfiguracja czasu/strefy/NTP).

Dlaczego „Missing Authorization”, skoro mówimy o command injection?
W danych NVD/CISA-ADP podatność ma nazwę „Missing Authorization” oraz klasyfikację CWE-862, co sugeruje, że istotnym elementem jest kontrola dostępu do funkcji/endpointu (kto może wywołać daną akcję), a dopiero potem wchodzi warstwa walidacji danych wejściowych, która umożliwia wstrzyknięcie poleceń. W skrócie: nie tylko da się wstrzyknąć komendę — jest jeszcze problem „kto i kiedy” może w ogóle dotknąć tej funkcji.

Warunki ataku (praktycznie):

Wektor sieciowy, niska złożoność.
Wymóg „low privileges” pasuje do scenariusza: atakujący zdobywa dostęp do panelu (np. hasła domyślne, wyciek, brute-force) i wykonuje spreparowane żądania do CGI.

Praktyczne konsekwencje / ryzyko

Skuteczna eksploatacja może prowadzić do:

Przejęcia rejestratora (wykonanie poleceń systemu z uprawnieniami procesu web/CGI).
Utraty poufności i integralności: podmiana konfiguracji, dostęp do nagrań, manipulacja ustawieniami kamer, potencjalny dostęp do sieci, w której stoi NVR.
Wciągnięcia do botnetu IoT (Mirai i pochodne), co oznacza ryzyko DDoS, skanowania, dalszej propagacji oraz „pivotu” do innych zasobów.
Ryzyka trwałego, bo mówimy o sprzęcie EOL: brak łatki oznacza, że luka nie „zniknie” wraz z kolejną aktualizacją — trzeba ją „odciąć” kontrolami kompensującymi albo wymienić urządzenie.

Rekomendacje operacyjne / co zrobić teraz

Jeśli masz (lub podejrzewasz, że masz) DS-2105 Pro w środowisku:

Inwentaryzacja i ekspozycja

Znajdź urządzenia w CMDB/scanach, sprawdź, czy interfejs WWW/zarządzania nie jest wystawiony do Internetu (to najczęstszy „game over” w IoT).

Redukcja powierzchni ataku (najważniejsze, gdy brak patchy)

Usuń publiczną ekspozycję, wymuś dostęp wyłącznie z sieci zaufanej/VPN, odseparuj VLAN-em, postaw reverse proxy/gateway przed panelem zarządzania. To dokładnie ten typ mitigacji rekomendowany przez badaczy, gdy producent nie dostarcza poprawek.

Higiena dostępu

Zmień domyślne loginy/hasła, wyłącz zbędne konta, ogranicz liczbę administratorów, rozważ IP allowlist do panelu.

Detekcja na brzegu

Jeżeli używasz IPS/NGFW, sprawdź dostępność sygnatur pod CVE-2023-52163 (np. Check Point publikuje informację o ochronie IPS i konieczności aktualizacji pakietów IPS).

Decyzja strategiczna: wymiana

Ponieważ to EOL i KEV (aktywnie wykorzystywane), w wielu środowiskach sensowną decyzją jest wycofanie urządzeń lub zastąpienie ich modelem z aktywnym wsparciem. Wprost w danych KEV/NVD pojawia się zalecenie „zastosuj mitigacje albo zakończ używanie produktu, jeśli mitigacje są niedostępne”.

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

Ten przypadek jest „podręcznikowy” dla IoT:

Botnety w stylu Mirai rutynowo polują na urządzenia brzegowe (routery, DVR/NVR, kamery), bo są masowe, często źle zarządzane i długo żyją bez aktualizacji. Akamai opisało kampanię, w której obok DigiEver celem były też inne urządzenia IoT (np. znane CVE w sprzęcie sieciowym).
Różnica w porównaniu do klasycznych podatności serwerowych jest taka, że tu cykl życia sprzętu (EOL) jest kluczową częścią ryzyka: nawet świetny zespół SOC nie „załata” produktu, którego producent już nie wspiera.

Podsumowanie / kluczowe wnioski

CVE-2023-52163 (DS-2105 Pro) trafiła do CISA KEV 22.12.2025, co potwierdza realną eksploatację w atakach; termin dla agencji federalnych to 12.01.2026.
Luka łączy problem kontroli dostępu (Missing Authorization / CWE-862) z możliwością command injection w funkcjach CGI (m.in. time_tzsetup.cgi).
To sprzęt klasy IoT/NVR, często EOL — dlatego priorytetem są odcięcie ekspozycji, segmentacja, twarde restrykcje dostępu i plan wymiany.

Źródła / bibliografia

Security Affairs – informacja o dopisaniu do KEV i opis wpływu na DS-2105 Pro. (Security Affairs)
NVD (NIST) – CVE-2023-52163, metryki CVSS, wpis o KEV (date added, due date, required action), CWE-862. (NVD)
Akamai SIRT – obserwacje eksploatacji w honeypotach i kontekst botnetowy (Mirai). (Akamai)
TXOne Research – tło odkrycia, zakres, odniesienia do CVE-2023-52163/52164 i mitigacje operacyjne (bez wystawiania do Internetu, zmiana haseł). (txone.com)
Check Point Advisory – potwierdzenie charakteru command injection i informacje o ochronie IPS. (Check Point Software)

Wyciek danych University of Phoenix: ok. 3,5 mln osób dotkniętych atakiem na Oracle E-Business Suite (EBS)

Wprowadzenie do problemu / definicja luki

University of Phoenix potwierdził incydent bezpieczeństwa związany z kompromitacją instancji Oracle E-Business Suite (EBS) — popularnej platformy ERP wykorzystywanej m.in. do procesów finansowych, HR i zakupowych. W wyniku ataku wykradziono dane osobowe i finansowe, a skala zdarzenia (raportowana regulatorowi) sięga niemal 3,5 mln osób.

Kluczowe w tym przypadku jest to, że nie mówimy o „zwykłym” phishingu czy błędzie konfiguracji, ale o kampanii wymierzonej w klientów Oracle EBS, w której wykorzystywano luki typu pre-auth (bez uwierzytelnienia) w komponentach aplikacji.

W skrócie

Skala: niemal 3,5 mln osób (studenci, pracownicy, dostawcy) — według danych przekazanych regulatorowi.
Okno eksfiltracji: 13–22 sierpnia 2025 (ustalone w toku dochodzenia).
Wykorzystany wektor: kampania ataków na Oracle EBS, wiązana z ekosystemem grupy Cl0p.
Zakres danych: m.in. imiona i nazwiska, daty urodzenia, numery SSN oraz dane bankowe (nr kont i routing).
Działania naprawcze: uczelnia informuje o współpracy z organami ścigania i oferuje usługi ochrony tożsamości (IDX) z terminem zapisu do 22 marca 2026.

Kontekst / historia / powiązania

SecurityWeek opisuje ten incydent jako element szerszej fali ataków na klientów Oracle EBS, przypisywanej Cl0p (w tle pojawia się też wątek klastra FIN11). W kampanii ucierpieć miało ponad 100 organizacji, w tym uczelnie.

To istotne z perspektywy obrony: ataki na ERP/finanse i systemy dostawców to „złota żyła” dla cyberprzestępców. Po pierwsze — takie systemy przechowują dane wrażliwe (PII, płatności, rozliczenia). Po drugie — często są wystawione do internetu lub dostępne z szerokich sieci partnerskich, co zwiększa powierzchnię ataku.

BleepingComputer wprost wiąże zdarzenie z Cl0p i wskazuje, że ofiarami byli nie tylko studenci i pracownicy, ale też dostawcy (supply chain w praktyce).

Analiza techniczna / szczegóły luki

1) CVE-2025-61882 — pre-auth RCE w Oracle EBS

Oracle opublikował alert bezpieczeństwa dla CVE-2025-61882, opisując podatność jako zdalnie wykorzystywalną bez uwierzytelnienia i potencjalnie prowadzącą do remote code execution. Wskazano wpływ na Oracle EBS w wersjach 12.2.3–12.2.14 oraz CVSS 9.8 (krytyczne).

Z perspektywy atakującego pre-auth RCE w systemie klasy ERP zwykle oznacza:

możliwość uruchomienia kodu w kontekście serwera aplikacyjnego,
dalszą eskalację (np. dostęp do plików konfiguracyjnych, połączeń DB, sekretów integracyjnych),
w efekcie: hurtową eksfiltrację danych.

2) CVE-2025-61884 — luka w Oracle Configurator (SSRF) i status KEV

Dodatkowo, w ekosystemie Oracle EBS pojawia się CVE-2025-61884 dotycząca Oracle Configurator (Runtime UI). NVD opisuje ją jako podatność pozwalającą nieautoryzowanemu atakującemu z dostępem sieciowym przez HTTP na kompromitację komponentu i nieautoryzowany dostęp do danych; CVSS 3.1: 7.5. Co kluczowe: CVE jest oznaczone jako znajdujące się w CISA Known Exploited Vulnerabilities (KEV) wraz z terminem działań naprawczych.

3) Oś czasu w przypadku University of Phoenix

Z korespondencji notyfikacyjnej wynika, że:

21 listopada 2025 wykryto problem i rozpoczęto działania IR z udziałem zewnętrznych firm,
atakujący wykorzystał nieznaną wcześniej podatność w Oracle EBS,
eksfiltracja miała miejsce 13–22 sierpnia 2025.

SecurityWeek doprecyzowuje zakres danych (PII + dane bankowe) i zaznacza, że uczelnia podkreśliła brak „środków dostępu” do kont (np. brak haseł/credentiali do bankowości).

Praktyczne konsekwencje / ryzyko

Jeżeli w incydencie uciekły kombinacje (imię i nazwisko + data urodzenia + SSN) oraz elementy danych finansowych, to realne scenariusze nadużyć obejmują:

Kradzież tożsamości i otwieranie produktów finansowych (kredyty, pożyczki, karty) na dane ofiary.
Phishing i spear-phishing: przestępcy mogą tworzyć wiadomości „idealnie dopasowane” (uczelnia, rekrutacja, rozliczenia, zwroty).
Próby oszustw finansowych (np. podszycia pod dział księgowości/dostawców), zwłaszcza jeśli ucierpieli również kontrahenci.

Dla organizacji skutki są równie poważne: koszty notyfikacji i obsługi incydentu, ryzyko pozwów, presja reputacyjna oraz potencjalne konsekwencje regulacyjne.

Rekomendacje operacyjne / co zrobić teraz

Dla organizacji korzystających z Oracle EBS

Patch management w trybie „out-of-band”
- Zweryfikuj wdrożenie aktualizacji dla CVE-2025-61882 (Oracle zaleca pilne zastosowanie poprawek; wskazuje też wymagania dot. zależności patchy).
Redukcja ekspozycji EBS
- Jeżeli to możliwe: zdejmij publiczną ekspozycję, ogranicz dostęp (VPN/ZTNA), wprowadź allowlistę źródeł, segmentuj ruch do komponentów webowych.
Hunting i detekcja
- Przejrzyj logi reverse proxy/WAF i serwera aplikacyjnego pod kątem nietypowych żądań HTTP oraz anomalii w komponentach EBS.
- Wykorzystaj opublikowane przez Oracle informacje pomocnicze (w tym IOC) do polowań i weryfikacji kompromitacji.
Kontrola danych i minimalizacja skutków
- Sprawdź, jakie tabele/raporty/załączniki mogły zostać pobrane.
- Włącz dodatkowe monitorowanie egress (nietypowe transfery, kompresje archiwów, ruch do rzadkich ASN).

Dla osób, których dane mogły wyciec

Zapisz się na ochronę tożsamości oferowaną przez uczelnię (IDX) — notyfikacja wskazuje m.in. monitoring kredytowy i dark web oraz deadline 22 marca 2026.
Ustaw alerty / blokady kredytowe (fraud alert / security freeze) i monitoruj raporty kredytowe oraz konta bankowe.
Traktuj podejrzane kontakty „z uczelni” lub „od Oracle/IT” jako potencjalnie złośliwe (szczególnie jeśli proszą o dopłatę, weryfikację danych lub instalację aplikacji).

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

1) „Masowa kampania” vs incydent punktowy
Ten przypadek jest częścią większej fali ataków na Oracle EBS — to oznacza, że techniki TTP (wektory HTTP, łańcuchy exploitów, scenariusz wymuszeń) mogą być zbliżone między ofiarami.

2) CVE-2025-61882 vs CVE-2025-61884

CVE-2025-61882: krytyczny pre-auth RCE (najgorszy możliwy scenariusz dla serwera aplikacji).
CVE-2025-61884: „wysokie” ryzyko w Oracle Configurator, z podkreślonym wpływem na poufność i statusem KEV (czyli „aktywnie wykorzystywane”).

3) Publikacja danych
SecurityWeek zaznacza, że — w przeciwieństwie do części innych ofiar, u których wypływały setki GB/TB — w momencie publikacji nie było sygnałów, by dane University of Phoenix zostały upublicznione na stronach przestępców.

Podsumowanie / kluczowe wnioski

Incydent University of Phoenix to przykład, jak luki pre-auth w systemach ERP przekładają się na masową eksfiltrację danych.
Skala ~3,5 mln osób wynika z raportowania regulatorowi; w praktyce oznacza to długotrwałe ryzyko nadużyć tożsamościowych.
Dla organizacji priorytetem jest: natychmiastowe łatanie, ograniczenie ekspozycji EBS, hunting pod kątem IOC oraz przegląd ścieżek eksfiltracji.
Dla osób poszkodowanych: monitoring kredytowy, blokady kredytowe i ostrożność wobec phishingu to minimum, a skorzystanie z usług ochrony tożsamości może realnie ograniczyć skutki.

Źródła / bibliografia

SecurityWeek — „3.5 Million Affected by University of Phoenix Data Breach” (SecurityWeek)
BleepingComputer — „University of Phoenix data breach impacts nearly 3.5 million individuals” (BleepingComputer)
California DOJ (sample notice PDF) — „University of Phoenix – Regulatory Notice Letter – CA”
Oracle — „Oracle Security Alert Advisory – CVE-2025-61882” (Oracle)
NIST NVD — „CVE-2025-61884 Detail (KEV status)” (NVD)

TL;DR

Krótka definicja techniczna (1 akapit)

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

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

Negocjacja kompresji i dlaczego zlib ma znaczenie

Co realnie wycieka z heap i jak to eskaluje ryzyko

Dlaczego to pasuje do ATT&CK T1190

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

Detekcja (praktyczne reguły)

Sigma (gotowa reguła)

Splunk (SPL)

KQL (Azure / Microsoft Sentinel)

CloudTrail query (AWS CLI/CloudWatch)

Elastic (EQL) przykłady

Heurystyki / korelacje (co łączyć)

False positives / tuning

Playbook reagowania

Przykłady z kampanii / case studies

Lab (bezpieczne testy) — przykładowe komendy

Mapowania (Mitigations, Powiązane techniki)

Źródła / dalsza literatura

Checklisty dla SOC / CISO

TL;DR

Krótka definicja techniczna

Gdzie występuje / przykłady platform

Szczegółowy opis techniki

Jak to działa (perspektywa defensywna)

Cele atakującego

Dlaczego jest skuteczna

Artefakty i logi

Detekcja (praktyczne reguły)

Sigma (gotowa reguła)

Splunk (SPL)

KQL (Azure)

CloudTrail query (AWS CLI/CloudWatch)

Elastic/EQL przykłady

Heurystyki / korelacje

False positives / tuning

Playbook reagowania (kroki + komendy)

1) Identyfikacja i triage

2) Natychmiastowe ograniczenie ekspozycji (kompensacja)

3) Polowanie (hunting)

4) Jeśli podejrzenie kompromitacji

Przykłady z kampanii / case studies

Lab (bezpieczne testy) — przykładowe komendy

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

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

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

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

Mapowania (Mitigations, Powiązane techniki)

MITRE ATT&CK (ICS) – techniki

MITRE – przykładowe mitigacje dla T0819 (ICS)

Powiązane konteksty podatności

Źródła / dalsza literatura

Checklisty dla SOC / CISO

SOC (operacyjnie)

CISO / właściciel ryzyka

Wprowadzenie do problemu / definicja luki

W skrócie

Kontekst / historia / powiązania

Analiza techniczna / szczegóły luki

Co dokładnie jest podatne?

Dlaczego to jest niebezpieczne, skoro opis mówi o „read”?

Jakie wersje są dotknięte?

Praktyczne konsekwencje / ryzyko

Rekomendacje operacyjne / co zrobić teraz

1) Patch – docelowa i najlepsza ścieżka

2) Mitigacja awaryjna, gdy nie możesz patchować „tu i teraz”

3) Szybkie twardnienie ekspozycji (równolegle)

4) Detekcja i IR – minimum sensowne w 24h

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

Podsumowanie / kluczowe wnioski

Źródła / bibliografia

TL;DR

Krótka definicja techniczna

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

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

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

Detekcja (praktyczne reguły)

Sigma (gotowa reguła)

Negocjacja kompresji i dlaczego `zlib` ma znaczenie