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

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

---

False positives / tuning

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

---

Playbook reagowania (kroki + komendy)

1) Identyfikacja i triage

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

2) Natychmiastowe ograniczenie ekspozycji (kompensacja)

Zgodnie z zaleceniami w advisory:

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

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

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

3) Polowanie (hunting)

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

4) Jeśli podejrzenie kompromitacji

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

---

Przykłady z kampanii / case studies

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

---

Lab (bezpieczne testy) — przykładowe komendy

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

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

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

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

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

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

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

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

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

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

---

Mapowania (Mitigations, Powiązane techniki)

MITRE ATT&CK (ICS) – techniki

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

MITRE – przykładowe mitigacje dla T0819 (ICS)

Z karty T0819 jako szczególnie sensowne dla smartRTU:

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

Powiązane konteksty podatności

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

---

Źródła / dalsza literatura

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

---

Checklisty dla SOC / CISO

SOC (operacyjnie)

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

CISO / właściciel ryzyka

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