Archiwa: Linux - Strona 36 z 53 - Security Bez Tabu

Tag: Linux

VoidLink: cloud-native framework malware na Linuksa celuje w AWS/Azure/GCP i środowiska kontenerowe

Wprowadzenie do problemu / definicja luki

VoidLink to nowo opisany, cloud-first framework malware dla Linuksa, zaprojektowany nie tyle do „jednorazowego” włamania na serwer, co do długotrwałego, skrytego utrzymania dostępu w nowoczesnej infrastrukturze: chmurze, kontenerach i klastrach Kubernetes. Wyróżnia go rozmach (loadery, implanty, rootkity, dziesiątki wtyczek) oraz to, że od początku „myśli” kategoriami metadanych instancji, API chmurowych i sekretów DevOps.

W skrócie

  • VoidLink został zidentyfikowany przez Check Point Research w grudniu 2025 jako klaster wcześniej niewidzianych próbek Linuksa, wyglądających na aktywnie rozwijany projekt (m.in. artefakty developerskie).
  • Framework jest „cloud-native”: rozpoznaje środowiska (AWS/Azure/GCP/Alibaba/Tencent) oraz Docker/Kubernetes i dostosowuje zachowanie do kontekstu.
  • Ma rozbudowaną modułowość (ponad 30+ pluginów) i API inspirowane podejściem znanym z Cobalt Strike/BOF.
  • Zawiera mechanizmy OPSEC i „adaptive stealth” (m.in. szyfrowanie w runtime, reakcje na „tampering”, dobór strategii na podstawie wykrytych zabezpieczeń).
  • Na moment publikacji analiz: brak potwierdzonych infekcji w środowiskach produkcyjnych, co sugeruje etap przygotowań lub budowę narzędzia „pod klienta”.

Kontekst / historia / powiązania

W próbkach i ekosystemie VoidLink badacze zauważyli sygnały wskazujące na chińskojęzyczne/chińsko-powiązane środowisko wytwórcze (m.in. lokalizacja panelu operatorskiego), przy czym dokładna afiliacja pozostaje niejasna. Jednocześnie poziom „produktowości” (dokumentacja, spójny zestaw komponentów: C2 + dashboard + builder) pasuje do narzędzia, które może być przygotowywane do komercjalizacji (sprzedaż/usługa) lub wykorzystania w ukierunkowanych operacjach (szpiegostwo, długofalowe zbieranie danych).

Istotny jest też strategiczny trend: atakujący coraz częściej traktują Linuksa w chmurze jako „system operacyjny biznesu” (workloady, CI/CD, klastry K8s, usługi danych), a nie poboczny element infrastruktury. VoidLink wygląda jak narzędzie stworzone dokładnie pod tę zmianę.

Analiza techniczna / szczegóły

Architektura i komponenty

VoidLink to kompletne środowisko operacyjne: dwustopniowy loader, implant (cloud-first) oraz zaplecze operatorskie (C2 + webowy dashboard). Wg opisu CPR rdzeń implantu jest napisany w Zig (z elementami Go i C w szerszym ekosystemie), co jest nietypowym, ale coraz częściej spotykanym wyborem w „nowoczesnym” malware.

Rozpoznanie środowiska (cloud/K8s/container-aware)

Po uruchomieniu framework wykonuje fingerprinting: sprawdza, czy działa w Dockerze lub Kubernetes, a następnie odpytuje metadane instancji i rozpoznaje dostawcę chmury (AWS, Azure, GCP, Alibaba, Tencent; w kodzie widoczne plany rozszerzeń o kolejnych providerów). To kluczowe, bo umożliwia dobór technik pod konkretny runtime i potencjalne pivoty w obrębie klastrów/tenantów.

Modułowość i pluginy

VoidLink ma architekturę mocno „frameworkową”: centralny implant + plugin API oraz 30+ modułów (w części opisów: kilkadziesiąt). Rozwiązanie to jest porównywane do podejścia znanego z Cobalt Strike (BOF) — operator może dobierać funkcje pod cel i minimalizować „szum” na hostach, gdzie liczy się stealth.
BleepingComputer podaje dodatkowo, że pluginy są ładowane jako obiekty ELF bezpośrednio do pamięci, co utrudnia klasyczne wykrywanie oparte o artefakty na dysku.

Rootkity, OPSEC i „adaptive stealth”

Wyróżnikiem VoidLink są możliwości rootkitowe zarówno w user-mode, jak i kernel-mode: opisy obejmują m.in. techniki typu LD_PRELOAD, LKM (Linux Kernel Module) oraz eBPF. Do tego dochodzą mechanizmy OPSEC (np. szyfrowanie kodu w runtime, reakcje na próby analizy/tamperingu) i adaptacyjne sterowanie zachowaniem.

SecurityWeek i BleepingComputer opisują też podejście oparte o ocenę ryzyka hosta: malware enumeruje zabezpieczenia/hardening i na tej podstawie dobiera strategię (np. wolniejsze skany, dłuższe interwały beaconingu).

Komunikacja C2

Framework wspiera kilka kanałów C2 (m.in. HTTP/HTTPS, ICMP, DNS tunneling, a w relacjach medialnych również WebSocket) oraz scenariusze P2P/mesh pomiędzy zainfekowanymi hostami. BleepingComputer wskazuje na własną warstwę szyfrowania/opakowania komunikacji („VoidStream”) mającą upodabniać ruch do normalnej aktywności web/API.

Praktyczne konsekwencje / ryzyko

Jeśli VoidLink (lub podobne frameworki) trafią do realnych kampanii, najbardziej narażone są organizacje, które:

  • utrzymują workloady Linuksowe w chmurze i polegają na metadanych instancji, rolach IAM i tokenach usługowych,
  • używają Kubernetes/contenerów (ryzyko ruchu lateralnego między workloadami oraz eskalacji w obrębie klastra),
  • mają rozbudowane procesy CI/CD i repozytoria kodu — ponieważ VoidLink jest opisywany jako nastawiony na kradzież sekretów, credentiali i danych DevOps (Git i systemy kontroli wersji), co tworzy pomost do ataków supply-chain.

Najgorszy scenariusz to ciche, długotrwałe utrzymanie dostępu w chmurze + stopniowe przejmowanie kolejnych zasobów poprzez skradzione uprawnienia i tokeny, bez klasycznych „głośnych” objawów na pojedynczym serwerze.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które realnie podnoszą próg dla narzędzi typu VoidLink (nawet jeśli dziś nie masz IOC pod tę konkretną rodzinę):

  1. Zabezpiecz metadane instancji i tokeny dostępu
    • Ogranicz dostęp workloadów do endpointów metadanych, gdzie to możliwe; stosuj polityki sieciowe i segmentację. (VoidLink aktywnie korzysta z metadanych/cloud fingerprintingu).
  2. Higiena sekretów (DevOps/CI/CD)
    • Wymuś rotację tokenów, krótkie TTL, używaj menedżerów sekretów, skanowania pod kątem sekretów w repozytoriach i pipeline’ach. (Celowanie w cloud/Git credy jest jednym z kluczowych wątków analiz).
  3. Wzmocnij detekcję na Linuksie pod kątem rootkitów i „in-memory”
    • Monitoruj anomalie LD_PRELOAD, nieoczekiwane LKM, nietypowe programy eBPF, oraz procesy z podejrzanym dostępem do /proc, /sys i socketów. (VoidLink ma te techniki wprost w opisie).
  4. Network telemetry: DNS/ICMP i „API-looking traffic”
    • Wykrywaj wzorce tunelowania DNS, nietypowy ICMP oraz beaconing „udający” normalne API. (VoidLink wspiera DNS/ICMP, a komunikacja ma być maskowana).
  5. Kubernetes hardening
    • Minimum uprawnień (RBAC), NetworkPolicies, ograniczenia podów (pod security), kontrola egress, ograniczenia dostępu do node’a i socketów runtime. (VoidLink wykrywa K8s/Docker i dostosowuje techniki).
  6. Załóż, że atakujący „waży ryzyko”
    • Skoro mechanizm ocenia poziom zabezpieczeń i dostosowuje agresywność, to inwestycja w hardening i EDR/telemetrię ma dodatkową wartość: może ograniczyć funkcje lub spowolnić operację napastnika.

Różnice / porównania z innymi przypadkami

  • Cobalt Strike/Sliver (klasyczne post-exploitation): VoidLink jest porównywany do ekosystemu „Beacon + rozszerzenia”, ale od początku jest projektowany jako cloud-native, z rozpoznaniem providerów, metadanych i środowisk kontenerowych.
  • Typowe linuxowe boty/backdoory: wiele rodzin linuksowych jest jednofunkcyjnych (np. koparki, proste backdoory). VoidLink jest opisywany jako wyjątkowo „feature-rich” (rootkity, pluginy, panel operatorski, adaptacja), co przesuwa go w stronę platformy dla długich operacji.

Podsumowanie / kluczowe wnioski

VoidLink to sygnał ostrzegawczy dla zespołów CloudSec/DevSecOps: pojawia się narzędzie, które traktuje chmurę i Kubernetesa jako naturalne środowisko operacyjne malware, a nie „kolejny serwer Linuksowy”. Nawet jeśli dziś nie ma dowodów na szerokie użycie w atakach, architektura (pluginy, OPSEC, rootkity, multi-C2) sugeruje gotowość do realnych kampanii — szczególnie tam, gdzie w grę wchodzą sekrety DevOps i dostęp do zasobów cloud API.

Źródła / bibliografia

  1. Check Point Research – „Unveiling VoidLink – A Stealthy, Cloud-Native Linux Malware Framework” (13 stycznia 2026). (Check Point Research)
  2. SecurityWeek – „VoidLink Linux Malware Framework Targets Cloud Environments” (15 stycznia 2026). (securityweek.com)
  3. Dark Reading – „‘VoidLink’ Malware Poses Advanced Threat to Linux Systems” (14 stycznia 2026). (Dark Reading)
  4. BleepingComputer – „New VoidLink malware framework targets Linux cloud servers” (13 stycznia 2026). (BleepingComputer)
  5. CSO Online – „Sophisticated VoidLink malware framework targets Linux cloud servers” (14 stycznia 2026). (CSO Online)

Krytyczna luka SQL Injection w produktach Advantech (CVE-2025-52694) – co wiemy i jak się zabezpieczyć

Wprowadzenie do problemu / definicja luki

Cyber Security Agency of Singapore (CSA) opublikowała 12 stycznia 2026 alert dotyczący krytycznej podatności w wybranych produktach Advantech, oznaczonej jako CVE-2025-52694. To klasyczny scenariusz wysokiego ryzyka: SQL Injection możliwy do wykorzystania zdalnie i bez uwierzytelnienia, jeśli usługa jest wystawiona do Internetu.

W skrócie

  • CVE: CVE-2025-52694
  • Typ: SQL Injection (SQLi)
  • Skutki: możliwość wykonania dowolnych zapytań SQL przez atakującego bez logowania (gdy endpoint jest dostępny z Internetu)
  • Ocena: CVSS 3.1 = 10.0 (Critical); wektor: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
  • Zalecenie: natychmiastowa aktualizacja do wersji naprawionych

Kontekst / historia / powiązania

W przypadku systemów z rodziny IoTSuite / IoT Edge problem jest szczególnie istotny, bo te komponenty często stoją na styku IT/OT (integracje, telemetria, panele webowe, API). CSA wskazuje, że podatność została skoordynowanie ujawniona, a odkrycie przypisano badaczowi z HCMUTE Information Security Club.

Analiza techniczna / szczegóły luki

SQL Injection oznacza, że aplikacja w pewnym miejscu buduje zapytania do bazy danych w sposób umożliwiający „wstrzyknięcie” fragmentu SQL przez dane wejściowe (np. parametr HTTP). W tym przypadku CSA/NVD opisują scenariusz, w którym:

  • atakujący nie musi być uwierzytelniony (PR:N),
  • atak jest zdalny przez sieć (AV:N) i zwykle możliwy do automatyzacji,
  • konsekwencją jest wykonanie dowolnych poleceń SQL na usłudze (o ile jest wystawiona do Internetu).

Wektor CVSS ze zmianą zasięgu (S:C) sugeruje, że skutki mogą „wychodzić” poza bezpośredni komponent (np. wpływ na inne elementy środowiska, zależnie od architektury i uprawnień DB).

Produkty i wersje podatne (wg CSA):

  • IoTSuite SaaSComposer – wersje < 3.4.15
  • IoTSuite Growth (Linux docker) – wersje < V2.0.2
  • IoTSuite Starter (Linux docker) – wersje < V2.0.2
  • IoT Edge (Linux docker) – wersje < V2.0.2
  • IoT Edge (Windows) – wersje < V2.0.2

Praktyczne konsekwencje / ryzyko

W praktyce SQLi w komponentach webowych / API może prowadzić m.in. do:

  • wycieku danych z bazy (telemetria, konfiguracje, dane operacyjne),
  • manipulacji danymi (fałszowanie odczytów, zmiana konfiguracji, sabotaż procesów),
  • eskalacji wpływu: w niektórych wdrożeniach SQLi bywa krokiem do przejęcia kont aplikacyjnych lub dalszego ruchu lateralnego (zależy od uprawnień konta DB i architektury).

Największe ryzyko pojawia się wtedy, gdy:

  • panel/usługa jest wystawiona bezpośrednio do Internetu,
  • brak jest segmentacji sieci i kontroli dostępu,
  • środowisko jest „płaskie” (łatwy pivot do innych systemów).

Rekomendacje operacyjne / co zrobić teraz

Priorytet: patch management + ograniczenie ekspozycji.

  1. Zidentyfikuj ekspozycję
  • Sprawdź, czy instancje IoTSuite/IoT Edge są dostępne z Internetu (DNS, reverse proxy, publiczne IP, reguły firewall/WAF).
  • Zweryfikuj, które wersje są uruchomione (porównaj z progami podatności powyżej).
  1. Zastosuj poprawki
  • CSA zaleca natychmiastową aktualizację do wersji naprawionych.
  • Dla IoTSuite SaaSComposer, IoTSuite Growth (Linux docker) i IoT Edge (Windows) CSA wskazuje konieczność kontaktu z Advantech w celu uzyskania oficjalnej wersji naprawionej.
  • Dla IoTSuite Starter (Linux docker) oraz IoT Edge (Linux docker) CSA kieruje do stron pobrania aktualizacji (mogą wymagać dostępu/portalu).
  1. Mitigacje „na już” (jeśli patch nie jest natychmiast możliwy)
  • Wycofaj usługę z Internetu: VPN/ZTNA + allowlist, dostęp tylko z sieci administracyjnej.
  • Włącz/zaostrz reguły WAF pod kątem SQLi (to nie zastąpi patcha, ale może kupić czas).
  • Ogranicz uprawnienia konta bazy danych używanego przez aplikację (zasada najmniejszych uprawnień).
  • Monitoruj logi aplikacji/proxy/WAF pod kątem anomalii w parametrach żądań i błędów DB (wzrost 4xx/5xx, charakterystyczne payloady SQLi).
  1. Detekcja i reakcja
  • Jeśli system był wystawiony do Internetu: potraktuj jako potencjalnie narażony, rozważ przegląd logów i artefaktów (zapytania, nietypowe konta, zmiany konfiguracji, dumpy tabel).
  • W środowiskach OT: skoordynuj działania z utrzymaniem ruchu, aby aktualizacja nie wpłynęła na ciągłość procesów.

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

W porównaniu do wielu podatności wymagających logowania lub interakcji użytkownika, ten przypadek ma „zły zestaw cech”:

  • brak uwierzytelnienia i zdalna osiągalność,
  • wysoka przewidywalność wektora ataku (SQLi bywa łatwe do skanowania i automatyzacji),
  • potencjalnie wysoki wpływ w środowiskach przemysłowych, gdzie dane i konfiguracje mają bezpośrednie przełożenie na operacje.

Podsumowanie / kluczowe wnioski

  • CVE-2025-52694 to krytyczna podatność typu SQL Injection w wybranych produktach Advantech, z oceną CVSS 10.0.
  • Największe ryzyko dotyczy instalacji wystawionych do Internetu.
  • Działanie rekomendowane: pilny patch oraz równolegle ograniczenie ekspozycji i wzmocnienie kontroli dostępu.

Źródła / bibliografia

  1. Alert CSA Singapore: „Critical Vulnerability in Advantech Products” (12 stycznia 2026). (Cyber Security Agency of Singapore)
  2. NVD (NIST): rekord CVE-2025-52694 (opis + wektor CVSS od CSA). (NVD)

Nowa chińsko-powiązana grupa UAT-7290 atakuje operatorów telekomunikacyjnych przez exploity na urządzenia brzegowe (edge) i buduje sieć ORB

Wprowadzenie do problemu / definicja luki

Telekomy (oraz dostawcy usług sieciowych) są dziś jednym z najbardziej atrakcyjnych celów dla aktorów APT: dostęp do infrastruktury szkieletowej i węzłów brzegowych daje możliwość długotrwałej obserwacji ruchu, pivotowania do sieci klientów i budowania „strategicznej” przewagi wywiadowczej.

Najświeższy przykład to ujawniona przez Cisco Talos aktywność klastra śledzonego jako UAT-7290: grupa ma wykorzystywać publicznie dostępne exploity (tzw. one-day) na urządzenia brzegowe oraz specyficzny dla celu brute force po SSH, by uzyskać dostęp początkowy i eskalować uprawnienia. Następnie wdraża linuksowe implanty oraz tworzy infrastrukturę Operational Relay Box (ORB) wykorzystywaną także przez inne chińsko-powiązane podmioty.

W skrócie

  • Kto? UAT-7290 – aktor o silnych wskaźnikach „China-nexus”, aktywny co najmniej od 2022 r.
  • Kogo atakuje? Głównie operatorów telekomunikacyjnych w Azji Południowej, a w ostatnich miesiącach także organizacje w Europie Południowo-Wschodniej.
  • Jak wchodzi? One-day exploity na popularne edge urządzenia + targetowany brute force SSH.
  • Co instaluje? Linuxowy łańcuch: RushDrop → DriveSwitch → SilentRaid oraz implant ORB Bulbature.
  • Po co ORB? Do ukrywania operatorów i „przekaźnikowania” operacji (także przez inne grupy).

Kontekst / historia / powiązania

Talos ocenia z wysoką pewnością, że UAT-7290 wpisuje się w chińską „rodzinę” APT i prowadzi działania o profilu cyber-wywiadowczym. Wskazywane są też nakładki TTP i infrastruktury z innymi znanymi bytami: m.in. artefakty kojarzone z RedLeaves (łączonym z APT10) i ShadowPad, a także podobieństwa do grupy opisywanej publicznie jako Red Foxtrot.

Ważny element układanki to ORB. Niezależnie od Talos, Sekoia opisywała już wcześniej ekosystem kompromitowanych urządzeń brzegowych, które po infekcji stają się Operational Relay Boxes – w praktyce „węzłami pośredniczącymi” dla dalszych ataków i tunelowania działań.

Analiza techniczna / szczegóły luki

1) Wejście: exploity na edge + brute force SSH

UAT-7290 ma stawiać na „pragmatykę”:

  • wykorzystywanie publicznych PoC dla znanych podatności w produktach brzegowych (one-day),
  • brute force SSH dopasowany do konkretnej ofiary (a nie masowy „spray”).

To model coraz częstszy w ekosystemie APT: urządzenia brzegowe (VPN, firewall, router, appliance) bywają słabiej monitorowane niż serwery, a ich kompromitacja daje świetny punkt do utrzymania dostępu.

2) Łańcuch malware (Linux): RushDrop → DriveSwitch → SilentRaid

RushDrop (alias ChronosRAT) działa jako dropper: wykonuje proste testy anty-VM, tworzy/wykorzystuje katalog “.pkgdb” i rozpakowuje komponenty, m.in. legalnego busybox, który następnie bywa nadużywany do wykonywania poleceń.

DriveSwitch jest komponentem „pomocniczym”, którego głównym zadaniem jest uruchomienie właściwego implantu.

SilentRaid (alias MystRodX) to zasadniczy implant utrzymujący dostęp – w Talos opisywany jako C++ backdoor z architekturą plugin-like, umożliwiający m.in. zdalną powłokę, operacje na plikach i port-forwarding. Zwraca uwagę detal operacyjny: rozwiązywanie domen C2 przez publiczny resolver 8.8.8.8.

3) Bulbature i ORB: „urządzenie brzegowe jako przekaźnik”

Talos wskazuje również na Bulbature – implant używany do przekształcania przejętych urządzeń w ORB (węzły przekaźnikowe). Malware przechowuje konfigurację C2 w plikach w /tmp (np. z rozszerzeniem *.cfg), potrafi rotować adresy C2 i zestawiać reverse shell.

Sekoia opisywała ORB jako część większej architektury: staging serwery + skrypty + malware, które finalnie robi z edge urządzeń „proxy-tunele” do ukrywania działań operatorów.

Praktyczne konsekwencje / ryzyko

Dla operatorów i firm zależnych od telco-infrastruktury to ryzyko w kilku wymiarach:

  • Długotrwała obecność w sieci (persistence) – edge urządzenia są idealne do „cichego” utrzymania dostępu, często poza standardowym EDR.
  • Pivot do systemów wewnętrznych (ruch „od brzegu do środka”), a w skrajnych scenariuszach także do środowisk klientów przez zaufane połączenia.
  • Zbieranie danych i ułatwienie operacji innym aktorom – rola UAT-7290 jako budowniczego ORB sugeruje, że kompromitacja może „żyć dalej”, nawet gdy pierwotny intruz zmieni priorytety.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz”, ukierunkowany na typowy łańcuch edge-compromise → implant → ORB.

1) Zbijanie powierzchni ataku na edge

  • Wyłącz ekspozycję paneli administracyjnych do Internetu (jeśli możliwe), ogranicz do VPN/management VLAN.
  • Wymuś MFA tam, gdzie to realne (zwłaszcza na VPN/SSO).
  • Zablokuj logowanie hasłem po SSH (preferuj klucze, ogranicz źródła, rate-limit, lockout).
  • Priorytetyzuj patching podatności na urządzeniach brzegowych – rządowe advisory pokazują, że aktorzy PRC rutynowo „jadą” na publicznych CVE na brzegu.

2) Hunting po artefaktach i zachowaniu

  • Szukaj nietypowych katalogów/plików: “.pkgdb”, a także podejrzanych plików konfiguracyjnych w /tmp (np. *.cfg) powiązanych z procesami nasłuchującymi na niestandardowych portach.
  • Monitoruj ruch DNS/egress z urządzeń brzegowych: nietypowe odpytywanie z appliance do 8.8.8.8 (jeśli normalnie nie powinno go być) może być poszlaką.
  • Anomalie typu: port-forwarding, tworzenie archiwów tar, odczyty /etc/passwd z kontekstu procesów, które nie mają uzasadnienia operacyjnego.

3) Detekcja sieci ORB / proxy-tunneling

  • Ustal baseline dla wychodzących połączeń TLS z edge urządzeń i odchyleń (np. nowe cele, stałe kanały utrzymujące sesję).
  • Szukaj sygnałów „proxy provider / tunnel” (Sekoia pokazywała, że ORB bywają zarządzane jak usługa tunelowania).

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

UAT-7290 wpisuje się w szerszy trend działań chińsko-powiązanych, gdzie:

  • edge urządzenia (backbone/PE/CE, firewalle, VPN, routery) są priorytetowym wektorem wejścia i miejscem utrzymywania dostępu,
  • kompromitacja bywa wykorzystywana do pivotowania i „zasilania” systemów wywiadowczych (zbieranie danych o komunikacji i przemieszczaniu się celów).

To zbieżne z tym, co rządowe agencje opisywały jako aktywność częściowo nakładającą się na klastry znane komercyjnie m.in. jako Salt Typhoon (i inne). Różnica praktyczna: Talos mocno akcentuje rolę UAT-7290 jako initial access + ORB builder, co może oznaczać „łańcuch dostaw dostępu” dla kolejnych operatorów.

Podsumowanie / kluczowe wnioski

  • UAT-7290 to nowo opisana (publicznie) aktywność China-nexus wymierzona w telekomy, z ekspansją na Europę Południowo-Wschodnią.
  • Technicznie grupa gra klasykiem, który nadal działa: one-day exploity na edge + brute force SSH, a potem linuksowy implant o architekturze modułowej.
  • Największa „waga” ryzyka wynika z ORB: przejęte edge urządzenia mogą stać się trwałą infrastrukturą przekaźnikową dla dalszych operacji.
  • Obrona powinna zacząć się od edge: patching, ograniczenie ekspozycji, twarde SSH, monitoring egress/DNS i hunting po artefaktach.

Źródła / bibliografia

  1. Cisco Talos – analiza UAT-7290 (RushDrop/DriveSwitch/SilentRaid, ORB). (Cisco Talos Blog)
  2. BleepingComputer – omówienie raportu Talos i podsumowanie arsenalu. (BleepingComputer)
  3. The Hacker News – streszczenie + kontekst (MystRodX, Bulbature, overlap). (The Hacker News)
  4. Sekoia.io – Bulbature/ORB jako model operacyjny na kompromitowanych edge urządzeniach. (Sekoia.io Blog)
  5. Joint Cybersecurity Advisory (IC3.gov) – kontekst działań PRC na routerach/edge i wykorzystywaniu publicznych CVE.

Pakistan-linked APT36 (Transparent Tribe) uderza w indyjskie instytucje: nowa fala spear-phishingu i malware „ReadOnly/WriteOnly”

Wprowadzenie do problemu / definicja luki

Na przełomie 2025/2026 roku odnotowano kolejną kampanię cyber-szpiegowską wymierzoną w indyjskie organizacje rządowe, akademickie i „strategiczne”. Badacze przypisują ją grupie APT36, znanej też jako Transparent Tribe — aktorowi powiązanemu z Pakistanem, aktywnemu co najmniej od 2013 r.

Warto podkreślić: tu nie chodzi o pojedynczą „lukę” w sensie CVE, ale o łańcuch infekcji oparty na socjotechnice (spear-phishing) i dostarczaniu złośliwych plików, które uruchamiają wieloetapowe komponenty malware. To klasyczny model APT: długofalowy dostęp, rozpoznanie, eksfiltracja, a nie szybka monetyzacja.

W skrócie

  • Kampania startuje od spear-phishingu z archiwum ZIP, zawierającego plik podszywający się pod PDF.
  • Po otwarciu, ładunek dostarcza dwa komponenty malware nazwane ReadOnly i WriteOnly.
  • Funkcje obejmują m.in. zdalną kontrolę, kradzież danych, trwałą obserwację, zrzuty ekranu oraz monitorowanie schowka.
  • Zachowanie malware ma się dostosowywać do wykrytego oprogramowania AV na stacji ofiary.
  • To kolejny przykład ewolucji APT36, które w ostatnich latach chętnie wykorzystuje „zaufane” formaty plików i legalne usługi/infrastrukturę do ukrywania działań.

Kontekst / historia / powiązania

Transparent Tribe (APT36) jest opisane w MITRE ATT&CK jako grupa podejrzewana o powiązania z Pakistanem, historycznie celująca w organizacje dyplomatyczne, obronne i badawcze w Indiach oraz Afganistanie.

W ujęciu „taktyk i technik” MITRE wskazuje m.in. na typowe dla tej grupy podejścia: rejestrację domen podszywających się pod legalne serwisy, spear-phishing (załączniki i linki) oraz uruchamianie złośliwych plików przez użytkownika (user execution).

Z perspektywy ostatnich kampanii (2024–2025) widać też rosnący nacisk na:

  • nadużywanie usług chmurowych i komunikatorów w łańcuchu dostarczania i C2 (np. Telegram, Google Drive, Slack),
  • „sprytne” nośniki startowe (LNK, CPL, skróty, pliki udające dokumenty),
  • oraz dopracowywanie odporności na detekcję.

Analiza techniczna / szczegóły luki

1) Wejście: spear-phishing + ZIP + „PDF”

Według opisu kampanii, atak rozpoczyna się od wiadomości spear-phishingowych z archiwum ZIP, w którym znajduje się plik przebrany za dokument PDF. To celowy wybór: formaty „biurowe” i „dokumentowe” nadal mają wysoki współczynnik otwarć w środowiskach urzędowych i akademickich.

2) Payload: ReadOnly + WriteOnly (modułowość)

Po uruchomieniu pliku ofiara otrzymuje dwa komponenty złośliwego oprogramowania określane jako ReadOnly i WriteOnly. Z punktu widzenia obrony to istotne, bo rozdzielenie funkcji na moduły zwykle ułatwia:

  • etapowanie (najpierw „cichy” loader, potem funkcje szpiegowskie),
  • mieszanie technik w zależności od środowiska,
  • oraz utrudnianie analizy.

3) Zachowanie na hoście: adaptacja do AV i funkcje szpiegowskie

Opisane możliwości obejmują zdalne sterowanie, eksfiltrację danych i utrzymywanie obserwacji (surveillance). Wprost wymieniane są m.in. zrzuty ekranu, monitorowanie schowka i zdalny pulpit.

Szczególnie ważne jest monitorowanie schowka: ta technika bywa używana nie tylko do „podsłuchiwania” wklejanych fragmentów (np. haseł, danych z dokumentów), ale też do podmiany wartości kopiowanych przez użytkownika — w artykule wskazano nawet scenariusz „podmiany” przy transakcjach kryptowalutowych.

4) Dlaczego to APT, a nie „zwykły malware”?

Badacze podkreślają, że to kampania nastawiona na długoterminowy nadzór, a nie szybki zysk czy destrukcję. To spójne z profilem Transparent Tribe w MITRE (spear-phishing, infrastruktura, długofalowe kampanie).

Praktyczne konsekwencje / ryzyko

Dla organizacji publicznych i uczelni skutki są zwykle „ciche”, ale bardzo kosztowne:

  • wyciek dokumentów (plany, korespondencja, projekty badawcze),
  • dostęp do skrzynek i zasobów współdzielonych,
  • rekonesans pod ataki łańcuchowe (np. na podmioty powiązane),
  • utrata poufności przez zrzuty ekranu i monitoring aktywności użytkownika.

Dodatkowo, jeśli malware faktycznie dostosowuje zachowanie do zainstalowanego AV, to organizacje z „różnorodnym” parkiem endpointów mogą mieć nierówny poziom widoczności incydentu (część hostów wykryje, część nie).

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które realnie ograniczają ryzyko przy kampaniach spear-phishingowych APT36 (bez czekania na „łatkę”):

  1. Higiena poczty i załączników
  • Sandboxing załączników oraz URL-i (detonacja w izolacji).
  • Blokowanie/oznaczanie archiwów z podejrzanymi cechami (nietypowe rozszerzenia, pliki „udające PDF”, podejrzane skróty).
  • Wymuszenie ostrzeżeń dla ZIP z plikami wykonywalnymi / nietypowymi kontenerami.
  1. Hardening stacji roboczych
  • Ogranicz uprawnienia użytkowników (least privilege).
  • Zablokuj uruchamianie podejrzanych typów plików z katalogów użytkownika (reguły ASR/EDR), a także nietypowe „launch chain” (np. dokument → interpreter/skrót → pobranie → wykonanie).
  1. Detekcja i threat hunting
  • Poluj na nietypowe procesy związane z funkcjami szpiegowskimi: masowe zrzuty ekranu, nietypowe użycie schowka, anomalie w zdalnym dostępie.
  • Koreluj zdarzenia „user execution” po kliknięciu załącznika z późniejszym ruchem sieciowym (zwłaszcza do świeżych domen/usług pośrednich). MITRE wskazuje, że spear-phishing i infrastruktura domenowa to częsty wzorzec dla tej grupy.
  1. Ograniczanie kanałów C2 i nadużyć chmury
    Check Point pokazywał, że Transparent Tribe potrafi wykorzystywać popularne usługi (np. Telegram/Google Drive/Slack) w dystrybucji i C2. W praktyce oznacza to: segmentację, egress filtering i monitoring anomalii do usług chmurowych (zwłaszcza „nietypowych” dla danej roli endpointa).

Różnice / porównania z innymi przypadkami

Ta kampania (ZIP + „PDF” + ReadOnly/WriteOnly) wpisuje się w szerszy trend ewolucji Transparent Tribe:

  • Windows: rozwój niestandardowych RAT/loaderów i kanałów C2
    Check Point opisał rozwój ElizaRAT oraz nadużycia usług chmurowych do dystrybucji i komunikacji, a także różne metody uruchomienia payloadu w kampaniach 2023–2024.
  • Linux: wykorzystywanie „desktop entry” i pozornie niegroźnych artefaktów
    CloudSEK i Sekoia opisywały kampanie, w których phishing prowadził do uruchomienia złośliwych elementów w środowiskach linuksowych (np. poprzez pliki .desktop), a następnie do komunikacji C2 (m.in. WebSocket) i uruchomienia końcowego RAT.

Wspólny mianownik: socjotechnika + „zaufany” nośnik startowy + etapowanie + adaptacja i ukrywanie.

Podsumowanie / kluczowe wnioski

  • Nowa kampania przypisywana APT36/Transparent Tribe ponownie pokazuje, że spear-phishing pozostaje najskuteczniejszym „wektorem APT” przeciw administracji i nauce.
  • Komponenty ReadOnly/WriteOnly oraz deklarowana adaptacja do AV sugerują nacisk na utrzymanie się w środowisku i długofalową eksfiltrację.
  • Obrona nie powinna opierać się na jednym punkcie (np. AV), tylko na warstwach: bramka pocztowa, izolacja/sandbox, hardening endpointów, monitoring egress i polowanie na TTP.

Źródła / bibliografia (wybrane)

  1. The Record (Recorded Future News) — opis kampanii, ReadOnly/WriteOnly, TTP, cele (2 stycznia 2026). (The Record from Recorded Future)
  2. MITRE ATT&CK — profil grupy Transparent Tribe (G0134), techniki i kontekst. (MITRE ATT&CK)
  3. Check Point Research — ewolucja malware APT36 (ElizaRAT), nadużycia usług chmurowych (4 listopada 2024). (Check Point Research)
  4. Sekoia.io — analiza łańcucha infekcji i narzędzi w kampanii DeskRAT (23 października 2025). (Sekoia.io Blog)
  5. CloudSEK — kampania APT36 z phishingiem ZIP i mechanizmem .desktop oraz rekomendacjami defensywnymi (21 sierpnia 2025). (CloudSek)

RondoDox wykorzystuje lukę React2Shell (CVE-2025-55182) do przejmowania serwerów Next.js – co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

Pod koniec grudnia 2025 r. zaobserwowano, że botnet RondoDox aktywnie wykorzystuje krytyczną podatność React2Shell (CVE-2025-55182) do przejmowania podatnych serwerów Next.js i instalowania na nich malware (m.in. komponentów botnetu oraz koparek kryptowalut).

React2Shell to nieautoryzowane zdalne wykonanie kodu (RCE) w ekosystemie React Server Components (RSC) i protokole “Flight”. W praktyce oznacza to, że pojedyncze, odpowiednio spreparowane żądanie HTTP może doprowadzić do wykonania kodu po stronie serwera w domyślnych konfiguracjach popularnych wdrożeń.

W skrócie

  • Kto atakuje: botnet RondoDox (kampania o charakterze masowym, automatyzowanym).
  • Co jest celem: publicznie dostępne, podatne instancje Next.js implementujące RSC (szczególnie ścieżki związane z App Router / Server Actions).
  • Co jest wykorzystywane: React2Shell – CVE-2025-55182 (RCE bez uwierzytelnienia).
  • Po co: instalacja coinminera, loadera/health-checkera i wariantu Mirai; utrzymanie się na hoście m.in. przez modyfikacje /etc/crontab i agresywne “czyszczenie” konkurencyjnych procesów.
  • Skala ryzyka: Shadowserver raportował (stan na 30 grudnia 2025) ponad 94 tys. wystawionych w Internecie zasobów podatnych na React2Shell.

Kontekst / historia / powiązania

RondoDox został wcześniej opisany jako botnet intensywnie “polujący” na n-day (znane już luki, często w wielu technologiach jednocześnie). W grudniowej odsłonie kampanii widać jednak wyraźny zwrot w stronę Next.js / React RSC.

CloudSEK, analizując logi C2 obejmujące marzec–grudzień 2025, wyróżnia trzy fazy aktywności: od rozpoznania i testów, przez automatyzację ataków na aplikacje webowe, po masową rekrutację botów (IoT i serwery). W grudniu 2025 “dominującym wektorem” stało się wykorzystywanie podatności Next.js/React2Shell.

Analiza techniczna / szczegóły luki

1) Co dokładnie psuje React2Shell?

Według analiz Wiz, rdzeń problemu dotyczy obsługi ładunków w React Server Components “Flight” i ma charakter niebezpiecznej deserializacji / błędu logicznego walidacji, co pozwala atakującemu wpłynąć na wykonanie kodu po stronie serwera. Kluczowe jest to, że wektor jest zdalny i bez uwierzytelnienia, a do ataku wystarcza pojedyncze żądanie HTTP.

Wercel podkreśla, że podatność dotyka React/Next.js i wymaga natychmiastowego działania, a najlepszą (w praktyce jedyną kompletną) metodą jest upgrade do wersji naprawionych.

2) Jak RondoDox operacjonalizuje exploit (bez “przepisu”)

CloudSEK opisuje dwa etapy:

  • Wave 1 – skanowanie (8–16 grudnia 2025): identyfikacja podatnych serwerów poprzez “blind RCE testing” (testowe polecenia i obserwacja zachowania aplikacji).
  • Wave 2 – wdrażanie payloadów (od 13 grudnia 2025): zdalne ściąganie i uruchamianie binariów (Linux ELF), ustawianie uprawnień, uruchamianie w tle; wskazane są konkretne ścieżki payloadów i infrastruktura C2.

3) Co jest instalowane na hoście

W kampanii opisano m.in.:

  • Coinminer (jeden z payloadów hostowany pod charakterystyczną ścieżką),
  • “bolts” – komponent dominacji/persistencji (usuwa konkurencję, egzekwuje whitelistę procesów, utrzymuje się m.in. przez /etc/crontab),
  • wariant Mirai.

Praktyczne konsekwencje / ryzyko

  1. Pełne przejęcie serwera aplikacyjnego (RCE) i uruchamianie dowolnych działań w kontekście procesu webowego.
  2. Cryptomining i degradacja zasobów (CPU/RAM), ryzyko kosztów chmurowych i awarii usług.
  3. Trwałość i “dominacja” na hoście – modyfikacje crona, zabijanie procesów nieujętych na liście, usuwanie innych botnetów.
  4. Rozszerzanie kompromitacji – Wiz raportuje obserwacje poeksploatacyjne obejmujące m.in. zwrot w stronę kradzieży poświadczeń chmurowych i dalszego “monetyzowania” dostępu.

Rekomendacje operacyjne / co zrobić teraz

1) Patch/upgrade – priorytet absolutny

  • Wercel wskazuje, że problem dotyczy m.in. Next.js 15.0.0–16.0.6 i zaleca natychmiastowy upgrade do wersji naprawionych.
  • Next.js publikuje listę wersji naprawiających dodatkowe problemy w RSC (m.in. DoS i ekspozycję kodu); nawet jeśli śledzisz tylko React2Shell, praktycznie oznacza to: wejdź na najnowsze “fixed” dla swojej gałęzi (14.x/15.x/16.x).
  • Jeśli utrzymujesz aplikacje Next.js, Vercel wskazuje też narzędzie jednego polecenia: npx fix-react2shell-next (w praktyce pomoc w automatyzacji aktualizacji zależności).

2) Rotacja sekretów, jeśli byłeś wystawiony w oknie ryzyka

Wercel rekomenduje rotację sekretów (priorytetem te najbardziej krytyczne), jeśli aplikacja była online i niezałatana w krytycznym okresie po upublicznieniu exploitów.

3) Monitoring i polowanie na oznaki infekcji

  • Sprawdzaj modyfikacje /etc/crontab i nietypowe zadania cron (persistencja).
  • Poluj na symptomy kopania (wysokie CPU) i procesy “czyszczące” inne procesy co kilkadziesiąt sekund (opisane zachowanie komponentu “bolts”).

4) Blokowanie znanych IOCs / infrastruktury (tam, gdzie to ma sens)

CloudSEK podaje przykładowe elementy infrastruktury C2 oraz charakterystyczne ścieżki payloadów użyte w kampanii. W środowiskach produkcyjnych warto je traktować jako IOC do detekcji i blokad warstwowych (WAF/egress filtering), pamiętając, że aktorzy szybko rotują infrastrukturę.

5) Twarde praktyki “na przyszłość”

  • Minimalizuj ekspozycję endpointów, stosuj zasadę najmniejszych uprawnień dla procesu aplikacji, segmentuj sieć (CloudSEK zwraca uwagę na równoległe fale ataków IoT i sens izolacji urządzeń w dedykowanych VLAN-ach).

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

  • Wektor ataku: w przeciwieństwie do klasycznych “n-day” w konkretnych CMS-ach/komponentach, React2Shell uderza w warstwę RSC/Flight i dotyka szerokiego ekosystemu aplikacji React/Next.js, często w domyślnej konfiguracji.
  • Cel kampanii: RondoDox łączy motywy typowo “botnetowe” (rekrutacja do DDoS, Mirai, IoT) z monetyzacją serwerów (cryptomining) i “utrzymaniem dominacji” na hostach.
  • Ryzyko wtórne: obserwacje Wiz sugerują, że po RCE rośnie udział działań post-exploitation w kierunku credential harvesting w chmurze – to istotnie podnosi stawkę (od “tylko koparki” do potencjalnego naruszenia środowisk i danych).

Podsumowanie / kluczowe wnioski

  • React2Shell (CVE-2025-55182) to krytyczne, łatwo nadużywalne RCE bez auth w ekosystemie React Server Components.
  • Botnet RondoDox aktywnie wykorzystuje lukę do infekowania Next.js, instalując coinminery i komponenty botnetu oraz zapewniając persistencję (cron) i usuwanie konkurencji.
  • Priorytetem jest natychmiastowe aktualizowanie do wersji naprawionych oraz działania “damage control”: rotacja sekretów, monitoring persistencji i anomalii, wzmocnienie kontroli ruchu wychodzącego/WAF.

Źródła / bibliografia

  1. BleepingComputer – „RondoDox botnet exploits React2Shell flaw to breach Next.js servers” (31.12.2025) (BleepingComputer)
  2. Vercel – React2Shell Security Bulletin (aktualizowane, m.in. 26.12.2025) (Vercel)
  3. Next.js Blog – Security Update: December 11, 2025 (CVE-2025-55183/55184/67779, impact na Next.js) (Next.js)
  4. Wiz Blog – „React2Shell (CVE-2025-55182)… Everything You Need to Know” (03.12.2025) (wiz.io)
  5. CloudSEK – „RondoDoX Botnet Weaponizes React2Shell” (29.12.2025) (cloudsek.com)

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

TL;DR

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

Krótka definicja techniczna

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

Gdzie występuje / przykłady platform

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

Szczegółowy opis techniki

Jak to działa (perspektywa defensywna)

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

Cele atakującego

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

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

Dlaczego jest skuteczna

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

Artefakty i logi

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

Detekcja (praktyczne reguły)

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

Sigma (gotowa reguła)

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

Splunk (SPL)

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

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

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

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

KQL (Azure)

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

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

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

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

CloudTrail query (AWS CLI/CloudWatch)

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

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

Elastic/EQL przykłady

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

Heurystyki / korelacje

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

False positives / tuning

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

Playbook reagowania (kroki + komendy)

1) Identyfikacja i triage

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

2) Natychmiastowe ograniczenie ekspozycji (kompensacja)

Zgodnie z zaleceniami w advisory:

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

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

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

3) Polowanie (hunting)

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

4) Jeśli podejrzenie kompromitacji

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

Przykłady z kampanii / case studies

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

Lab (bezpieczne testy) — przykładowe komendy

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

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

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

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

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

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

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

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

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

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

Mapowania (Mitigations, Powiązane techniki)

MITRE ATT&CK (ICS) – techniki

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

MITRE – przykładowe mitigacje dla T0819 (ICS)

Z karty T0819 jako szczególnie sensowne dla smartRTU:

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

Powiązane konteksty podatności

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

Źródła / dalsza literatura

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

Checklisty dla SOC / CISO

SOC (operacyjnie)

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

CISO / właściciel ryzyka

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

CVE-2025-61884 – Oracle E-Business Suite (EBS)

TL;DR

  • CVE-2025-61884 dotyczy Oracle E-Business Suite (EBS) → Oracle Configurator → komponent Runtime UI w wersjach 12.2.3–12.2.14 i jest zdalnie wykorzystywalna bez uwierzytelnienia przez HTTP/HTTPS.
  • Ocena producenta/NVD wskazuje na wysoki wpływ na poufność (CVSS 3.1: 7.5, C:H / I:N / A:N), czyli przede wszystkim nieautoryzowany dostęp/wyciek danych.
  • W praktyce jest opisywana jako pre-auth SSRF (nazwa w KEV/NVD oraz alerty branżowe/instytucjonalne), a publiczne raporty łączą ją z aktywnym wykorzystywaniem i publicznie dostępnym PoC.
  • W ATT&CK najlepiej mapuje się do T1190 – Exploit Public-Facing Application (Initial Access); MITRE wskazuje m.in. WAF, filtrowanie ruchu i patching jako kluczowe mitygacje.

Krótka definicja techniczna (1 akapit)

CVE-2025-61884 to podatność w publicznie wystawionym komponencie webowym (Oracle Configurator Runtime UI), która umożliwia niezalogowanemu atakującemu doprowadzenie aplikacji do zachowań niezamierzonych (w raportach klasyfikowanych jako SSRF) i w konsekwencji uzyskanie dostępu do wrażliwych zasobów/danych; w ATT&CK odpowiada temu T1190 (Initial Access) – wejście przez podatną aplikację dostęp­ną z Internetu.

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

  • Windows: rzadziej jako host EBS, ale jeśli front (proxy/WAF) lub komponenty pośrednie są na Windows — interesują logi IIS/reverse proxy oraz EDR na hoście aplikacji. (Rdzeń CVE jest jednak w komponencie EBS/Configurator).
  • AD: pośrednio — EBS bywa spięty z AD/SSO. Skutkiem może być ekspozycja danych i późniejsza eskalacja (np. kradzież konfiguracji, identyfikatorów, mapowań).
  • AWS: częsty scenariusz: EBS na EC2 + ALB/WAF + CloudWatch Logs. W kontekście SSRF szczególnie ważne: egress z serwera i ochrona przed dostępem do metadata endpoint (169.254.169.254).
  • Azure: analogicznie (App Gateway WAF / Front Door + Log Analytics). SSRF → ryzyko dostępu do metadanych instancji i tokenów, jeśli egress nie jest ograniczony.
  • GCP: podobny model (LB/WAF, logi HTTP LB, kontrola egress).
  • K8s: rzadziej dla EBS, ale jeśli komponent jest „opakowany” lub stoi za ingress — logi ingress + korelacja z egress kontenera.
  • ESXi: nie dotyczy bezpośrednio CVE, ale MITRE wskazuje T1190 także dla infrastruktury (gdy aplikacje/zarządzanie są wystawione).
  • M365: brak bezpośredniego wektora; może być użyte w łańcuchu (np. dalsza eksfiltracja).

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

Kontekst CVE-2025-61884 w łańcuchu Initial Access

W przypadku Oracle EBS/Configurator Runtime UI, atakujący nie potrzebuje konta — wystarczy dostęp sieciowy do HTTP/HTTPS i podatnej wersji. To jest „książkowy” wariant T1190, bo aplikacja publicznie wystawiona staje się bramą do danych/zasobów.

Co realnie daje podatność

  • Oficjalny opis (Oracle/NVD) wskazuje na dostęp do „sensitive resources” oraz nieautoryzowany dostęp do krytycznych danych w ramach tego, co Oracle Configurator udostępnia.
  • W metadanych NVD/KEV podatność nazywana jest SSRF, a CISA-ADP przypisało m.in. CWE-918 (SSRF) oraz inne CWE, co sugeruje albo wieloprzymitywowy błąd, albo różne interpretacje łańcucha (ważne: Oracle zwykle nie publikuje pełnych detali technicznych).
  • Publiczne raporty wskazują, że poprawka wiązała się m.in. z walidacją parametru typu return_url, co jest typowym miejscem dla nadużyć SSRF/redirect/CRLF — dla SOC to cenna wskazówka do polowania w logach.

Dlaczego to jest skuteczne (z perspektywy atakującego)

  • Pre-auth (brak loginu) + niska złożoność (AC:L) = bardzo szybkie skanowanie Internetu i automatyzacja.
  • „Systemy biznesowe” (EBS) często zawierają dane finansowe/HR/procesowe, więc nawet „tylko” poufność (C:H) ma wysoki wpływ operacyjny.
  • MITRE rekomenduje podejście multi-signal (żądanie → błędy → proces/egress), bo same żądania HTTP nie zawsze wystarczą do pewnego potwierdzenia skutecznej eksploatacji.

Artefakty i logi

WarstwaŹródło logówPrzykładowe pola/artefaktyEID / EventCo polować (CVE-2025-61884 / T1190)
Reverse proxy / OHS / Apache / Nginxaccess_log, error_logurl.path, url.query, status, bytes, user_agent, src_ip—Uderzenia w UiServlet/SyncServlet + parametry typu return_url + nietypowe schematy/hosty/IP, skoki 4xx/5xx
WAF (Cloudflare/AWS WAF/Azure WAF/F5)WAF eventsaction, rule_id, uri, args, client_ip—Bloki/alerty na sygnatury SSRF / CVE-2025-61884 (np. nowe reguły WAF)
Aplikacja Oracle EBSlogi aplikacyjne EBS/Configuratorślady wywołań servletów, błędy walidacji URL, wyjątki—Nietypowe wyjątki w Runtime UI, brak sesji użytkownika, nietypowe wzorce zapytań
Sieć (on-prem)firewall/proxydest IP/port, SNI/Host, ilość danych—Egress z serwera EBS do nietypowych hostów / link-local / zasobów wewnętrznych (wzorzec SSRF)
AWSVPC Flow Logs / ALB/WAF logs (CloudWatch)srcaddr, dstaddr, dstport, action— / (CloudTrail: N/A)Korelacja: inbound atak → outbound z EBS do nietypowych destów; WAF hit na CVE
AzureNSG Flow Logs + AppGW/FrontDoor WAF (Log Analytics)clientIP, requestUri, ruleName—Identyczne korelacje jak wyżej
K8sK8s audit / ingress logsrequestURI, userAgent, sourceIPs—Jeśli EBS jest za ingress: wzorce exploit-probing + egress z poda
M365Unified Audit Log——Zwykle N/A dla samego CVE

Detekcja (praktyczne reguły)

Poniższe przykłady celują w telemetrię HTTP/WAF i klasyczne sygnały SSRF/probing. Wg publicznych raportów aktywność obejmowała m.in. endpointy UiServlet/SyncServlet oraz parametry redirekt/URL.

Sigma (gotowa reguła)

Dopasuj mapowanie pól do Twojego parsera (ECS, Splunk CIM, IIS, Nginx itp.).

title: Oracle EBS Configurator Runtime UI - Suspicious SSRF / return_url Patterns (CVE-2025-61884)
id: 2a2c9c6d-6d2b-4b5a-9c86-5b2f7a3f3b7d
status: experimental
description: |
  Detects suspicious requests to Oracle E-Business Suite (Oracle Configurator Runtime UI) endpoints
  with URL/redirect parameters suggestive of SSRF/probing related to CVE-2025-61884.
author: Badacz CVE
date: 2025/12/23
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_endpoint:
    url.path|contains:
      - "/configurator/UiServlet"
      - "/OA_HTML/configurator/UiServlet"
      - "/OA_HTML/SyncServlet"
  selection_param:
    url.query|contains:
      - "return_url="
  selection_ssrf_indicators:
    url.query|contains:
      - "http://"
      - "https://"
      - "file://"
      - "gopher://"
      - "ftp://"
      - "169.254.169.254"
      - "127.0.0.1"
      - "localhost"
      - "%0d%0a"
      - "%0D%0A"
  condition: selection_endpoint and selection_param and selection_ssrf_indicators
falsepositives:
  - Rare legitimate redirect flows using absolute URLs (tune by source IP ranges, auth/session cookies, user agents, rate)
level: high

Splunk (SPL)

(index=web OR index=waf OR index=proxy)
| eval path=coalesce(url_path, uri_path, cs_uri_stem, request_path)
| eval query=coalesce(url_query, uri_query, cs_uri_query, query_string)
| where like(path, "%/configurator/UiServlet%")
   OR like(path, "%/OA_HTML/configurator/UiServlet%")
   OR like(path, "%/OA_HTML/SyncServlet%")
| where isnotnull(query) AND match(lower(query), "return_url=")
| where match(lower(query), "(http://|https://|file://|gopher://|ftp://|169\\.254\\.169\\.254|127\\.0\\.0\\.1|localhost|%0d%0a)")
| stats count as hits min(_time) as first_seen max(_time) as last_seen values(status) as status values(useragent) as ua by src_ip, host, path
| sort - hits

KQL (Azure / Microsoft Sentinel)

WAF / reverse proxy w Log Analytics (przykład ogólny):

let suspiciousPaths = dynamic([
  "/configurator/UiServlet",
  "/OA_HTML/configurator/UiServlet",
  "/OA_HTML/SyncServlet"
]);
AzureDiagnostics
| extend path = tostring(requestUri_s), query = tostring(queryString_s), clientIp = tostring(clientIP_s)
| where path has_any (suspiciousPaths)
| where query has "return_url="
| where query has_any ("http://","https://","file://","gopher://","ftp://","169.254.169.254","127.0.0.1","%0d%0a")
| summarize hits=count(), first_seen=min(TimeGenerated), last_seen=max(TimeGenerated),
            ua=makeset(userAgent_s, 5) by clientIp, path
| order by hits desc

CloudTrail query (AWS CLI/CloudWatch)

Dla tej klasy zdarzeń CloudTrail zwykle nie pomoże (to nie są API calls), ale sensowny jest CloudWatch Logs Insights na AWS WAF logs:

fields @timestamp, httpRequest.clientIp, httpRequest.uri, httpRequest.args, action, terminatingRuleId
| filter httpRequest.uri like /\/configurator\/UiServlet|\/OA_HTML\/configurator\/UiServlet|\/OA_HTML\/SyncServlet/
| filter httpRequest.args like /return_url=/ 
| filter httpRequest.args like /http:\/\/|https:\/\/|169\.254\.169\.254|127\.0\.0\.1|localhost|%0d%0a/i
| stats count() as hits, min(@timestamp) as first_seen, max(@timestamp) as last_seen,
        values(action) as actions, values(terminatingRuleId) as rules
  by httpRequest.clientIp, httpRequest.uri
| sort hits desc

Elastic/EQL przykłady

Kibana KQL (logi HTTP/WAF w ECS):

url.path : ("/configurator/UiServlet" or "/OA_HTML/configurator/UiServlet" or "/OA_HTML/SyncServlet")
and url.query : ("return_url=" and ("http://" or "https://" or "file://" or "gopher://" or "ftp://" or "169.254.169.254" or "127.0.0.1" or "localhost" or "%0d%0a"))

EQL (korelacja inbound → outbound, jeśli masz EDR + network events):

sequence by host.id with maxspan=5m
  [network where network.direction == "inbound"
    and url.path in ("/configurator/UiServlet", "/OA_HTML/configurator/UiServlet", "/OA_HTML/SyncServlet")]
  [network where network.direction == "outbound"
    and destination.ip in ("169.254.169.254","127.0.0.1")]

Heurystyki / korelacje (co łączyć)

Korzystaj z podejścia „multi-signal correlation” (MITRE):

  1. Sygnał 1 — inbound probing: nietypowe żądania do servletów Configurator/Sync, często z zewnętrznych adresów i bez kontekstu sesji.
  2. Sygnał 2 — WAF / error spike: wzrost blokad WAF, 4xx/5xx w krótkim oknie czasu. (Cloudflare dodał nawet dedykowaną detekcję „Oracle EBS – SSRF – CVE-2025-61884”).
  3. Sygnał 3 — egress anomalia: serwer EBS inicjuje połączenia do nietypowych hostów (wewnętrznych, link-local, metadata). To jest kluczowe przy SSRF.
  4. Sygnał 4 — data exfil: duże odpowiedzi HTTP (bytes out) / długie czasy odpowiedzi dla endpointów Runtime UI, szczególnie bez typowego flow aplikacyjnego.
  5. Sygnał 5 — kontekst zagrożenia: CVE zostało dodane do KEV (NVD pokazuje daty dodania i deadline), co zwiększa priorytet i uzasadnia hunting retrospektywny.

False positives / tuning

Typowe FP i jak je ograniczać:

  • Legalne użycie redirectów: jeśli aplikacja używa parametru return_url do nawigacji — dopuszczalne, ale zwykle:
    • pochodzi z wewnętrznych adresów IP/VPN,
    • ma spójny user-agent,
    • występuje w obecności cookie/sesji.
      Tuning: ogranicz detekcję do źródeł spoza korporacyjnych CIDR, dodaj warunek braku sesji, dodaj próg częstotliwości (rate).
  • Skanery podatności w organizacji: wpisz je na allowlistę (IP/UA), ale zachowaj osobny dashboard „security scanning activity”.
  • WAF sygnatury: jeśli korzystasz z Cloudflare — śledź nową regułę dla CVE-2025-61884 jako sygnał, ale koreluj z ruchem „allowed”, bo część kampanii może próbować obejść WAF przez inne ścieżki (np. bez WAF lub przez inne punkty wejścia).

Playbook reagowania (kroki + komendy)

Natychmiastowe ograniczenie ryzyka (containment)

  1. Odetnij Internet → Runtime UI / EBS (tymczasowo: allowlist VPN/bastion/WAF). MITRE wprost rekomenduje ograniczenie ekspozycji usług oraz segmentację/DMZ.
  2. Włącz/zaostrz WAF (jeśli masz Cloudflare — zweryfikuj, czy działa reguła dla CVE-2025-61884).
  3. Ogranicz egress z serwera EBS (SSRF „żyje” egress’em).

Przykład (Linux, defensywnie – blokada metadata; dopasuj do polityk):

sudo iptables -A OUTPUT -d 169.254.169.254 -j REJECT
sudo iptables -A OUTPUT -d 127.0.0.1 -p tcp --dport 80 -j REJECT

Patching i weryfikacja

  • Zastosuj Oracle Security Alert z 11 października 2025 (Rev 1); Oracle wskazuje, że wersje spoza wsparcia mogły nie być testowane, ale „prawdopodobnie” wcześniejsze też mogą być dotknięte → jeśli masz starsze EBS, traktuj to jak ryzyko wysokie i planuj upgrade.

Hunting (retrospektywnie 30–90 dni)

Szybkie grepy (ścieżki dopasuj do Oracle HTTP Server / reverse proxy):

# Szukanie podejrzanych endpointów
zgrep -RniE "(/configurator/UiServlet|/OA_HTML/SyncServlet|/OA_HTML/configurator/UiServlet)" /var/log/* 2>/dev/null

# Szukanie podejrzanych wskaźników SSRF/CRLF w query
zgrep -RniE "return_url=.*(http://|https://|169\.254\.169\.254|127\.0\.0\.1|%0d%0a)" /var/log/* 2>/dev/null

Jeśli podejrzewasz skuteczną kompromitację

  • Traktuj to jak incydent o możliwym wpływie na dane: identyfikacja zakresu wycieku, powiadomienia, analiza kont/SSO integracji.
  • Publiczne raporty opisują złożone łańcuchy exploitacji w ekosystemie EBS (różne CVE i różne łańcuchy); nawet jeśli CVE-2025-61884 ma CVSS tylko na poufność, w praktyce SOC powinien sprawdzić, czy nie wystąpiły sygnały „post-exploit”.

Przykłady z kampanii / case studies

  • Dodanie do KEV (widoczne w NVD) sugeruje dowody aktywnego wykorzystania i podbija priorytet patchowania/huntingu (NVD pokazuje „Date Added: 2025-10-20” oraz deadline).
  • CSA Singapur opublikowała alert wprost o aktywnej eksploatacji SSRF i podała, że PoC jest publicznie dostępny.
  • Media branżowe raportowały, że exploit/PoC miał zostać ujawniony publicznie (m.in. w wątku „ShinyHunters”), a Oracle wypuścił poprawkę out-of-band.
  • Kontekst kampanii extortion wokół Oracle EBS był szeroko opisywany, m.in. przez Reuters (z zastrzeżeniem, że ocena prawdziwości części twierdzeń napastników bywała na tamtym etapie niepewna).

Lab (bezpieczne testy) — przykładowe komendy

Cel labu dla Blue Team: zweryfikować ekspozycję, widoczność w logach i skuteczność detekcji, bez „odtwarzania exploitów”.

  1. Sprawdź ekspozycję portów i usług (host EBS / reverse proxy):
sudo ss -lntp | egrep ':(80|443)\s'
  1. Wygeneruj kontrolowany „ruch testowy” do standardowej strony (bez payloadów CVE), aby upewnić się, że logi trafiają do SIEM:
curl -kI https://twoj-host-ebs.example/ | head
  1. Test parsowania i reguł detekcji na „sztucznych” wpisach logów (bez kontaktu z EBS):
cat <<'EOF' > /tmp/test_access.log
203.0.113.10 - - [23/Dec/2025:10:00:00 +0000] "GET /OA_HTML/SyncServlet?return_url=http://example.com/ HTTP/1.1" 200 1234 "-" "lab-test-agent"
EOF

Następnie odpal swoje pipeline’y (Filebeat/Fluent Bit/Splunk UF) na pliku testowym i sprawdź, czy reguła (Sigma/SPL/KQL) łapie zdarzenie.

  1. Sprawdź, czy WAF raportuje sygnatury dla CVE-2025-61884 (np. w Cloudflare jest to osobna detekcja w managed rules).

Mapowania (Mitigations, Powiązane techniki)

ATT&CK

  • Technika: T1190 – Exploit Public-Facing Application
  • Taktyka: Initial Access
  • ATT&CK (katalog): v18 (aktualizacja październik 2025)
  • Last Modified (T1190): 24 Oct 2025

Mitigations (MITRE)

Dla T1190 MITRE podkreśla m.in.:

  • M1050 Exploit Protection / WAF,
  • M1037 Filter Network Traffic (zwłaszcza ograniczenie egress),
  • M1035 Limit Access to Resource Over Network,
  • M1030 Network Segmentation,
  • M1051 Update Software,
  • M1016 Vulnerability Scanning,
  • M1048 Application Isolation and Sandboxing.

Powiązane techniki (często w tym samym łańcuchu)

  • T1210 Exploitation of Remote Services (gdy exploit przeradza się w ruch lateralny)
  • T1041 Exfiltration Over C2 Channel / T1567 Exfiltration Over Web Service (jeśli dane są wyprowadzane)
  • (Kontekstowo) techniki związane z SSRF → dostęp do metadanych chmurowych i nadużyciem IAM (zależne od środowiska).

Źródła / dalsza literatura

  • Oracle: Security Alert CVE-2025-61884 (opis, risk matrix, wersje dotknięte, parametry CVSS). (Oracle)
  • NVD: CVE-2025-61884 (CVSS vector, wersje 12.2.3–12.2.14, wątek KEV i nazwa SSRF, lista CWE z CISA-ADP). (NVD)
  • MITRE ATT&CK: T1190 (definicja, mitygacje, strategie detekcji, data modyfikacji). (MITRE ATT&CK)
  • CSA Singapore: alert o aktywnej eksploatacji i PoC. (Cyber Security Agency of Singapore)
  • Canadian Centre for Cyber Security: kontekst patchy i KEV. (Canadian Centre for Cyber Security)
  • Cloudflare: emergency WAF release z detekcją dla CVE-2025-61884. (Cloudflare Docs)
  • BleepingComputer: tło kampanii, PoC leak, SSRF/return_url jako trop huntingowy. (BleepingComputer)
  • Google Cloud (Mandiant/GTIG): kontekst wielu łańcuchów exploitacji w EBS (ważne dla „post-exploit” huntingu). (Google Cloud)
  • Reuters: tło kampanii extortion wokół Oracle EBS (ostrożnie z atrybucją). (Reuters)

Checklisty dla SOC / CISO

SOC (operacyjnie, 24–72h)

  • Zidentyfikuj wszystkie instancje Oracle EBS/Configurator Runtime UI i czy są publicznie dostępne.
  • Wdróż/zweryfikuj patch z Security Alert (11 Oct 2025) na dotkniętych wersjach 12.2.3–12.2.14.
  • Włącz korelację: (inbound endpointy) + (WAF/error spike) + (egress anomalia).
  • Retrospektywny hunting: UiServlet/SyncServlet + return_url + wskaźniki SSRF/CRLF.
  • Jeśli widzisz sygnały skutecznej eksploatacji: uruchom IR (triage danych, izolacja hostów, analiza egress).

CISO (zarządczo)

  • Traktuj CVE-2025-61884 jako „exploited-in-the-wild” (KEV) i ustaw priorytet patchowania/izolacji jak dla krytycznych systemów biznesowych.
  • Wymuś polityki: WAF + segmentacja + ograniczenie egress dla aplikacji publicznych.
  • Upewnij się, że monitoring obejmuje warstwę aplikacyjną i sieciową (bez tego SSRF bywa „ciche”).