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)
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).
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).
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).
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).
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.
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.
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).
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.
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),
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:
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ę”):
Higiena poczty i załączników
Sandboxing załączników oraz URL-i (detonacja w izolacji).
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).
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.
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.
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)
The Record (Recorded Future News) — opis kampanii, ReadOnly/WriteOnly, TTP, cele (2 stycznia 2026). (The Record from Recorded Future)
MITRE ATT&CK — profil grupy Transparent Tribe (G0134), techniki i kontekst. (MITRE ATT&CK)
Check Point Research — ewolucja malware APT36 (ElizaRAT), nadużycia usług chmurowych (4 listopada 2024). (Check Point Research)
Sekoia.io — analiza łańcucha infekcji i narzędzi w kampanii DeskRAT (23 października 2025). (Sekoia.io Blog)
CloudSEK — kampania APT36 z phishingiem ZIP i mechanizmem .desktop oraz rekomendacjami defensywnymi (21 sierpnia 2025). (CloudSek)
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
Pełne przejęcie serwera aplikacyjnego (RCE) i uruchamianie dowolnych działań w kontekście procesu webowego.
Cryptomining i degradacja zasobów (CPU/RAM), ryzyko kosztów chmurowych i awarii usług.
Trwałość i “dominacja” na hoście – modyfikacje crona, zabijanie procesów nieujętych na liście, usuwanie innych botnetów.
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.
CVE-2025-3232 dotyczy Mitsubishi Electric Europe B.V. smartRTU (≤ 3.37) i polega na braku uwierzytelnienia dla krytycznej funkcji (CWE-306) – w praktyce zdalny, nieuwierzytelniony atakujący może obejść kontrolę dostępu i przez konkretną trasę API doprowadzić do wykonania poleceń systemu operacyjnego.
Ocena ryzyka (CNA/ICS-CERT): CVSS v3.1 7.5 (HIGH); NVD pokazuje też CVSS v4 8.7 (HIGH) (ocena NVD “not yet provided”, widoczna jest ocena CNA).
To część pakietu problemów w smartRTU opisanego w ICSA-25-105-09 – obok CVE-2025-3128 (CWE-78, OS Command Injection, CVSS 9.8), który bywa opisywany jako kolejny krok po obejściu uwierzytelnienia.
Najważniejsze działania defensywne (kompensacyjne): zdejmij ekspozycję z Internetu, ogranicz dostęp do zaufanych sieci, stosuj VPN / firewall, a jeśli HTTP/HTTPS musi być wystawione – rozważ WAF.
W materiałach CISA/CSAF (ICSA-25-105-09) wskazano, że nie było raportów o publicznie znanej exploitacji ukierunkowanej na tę podatność (stan na publikację/rewizję advisory).
Krótka definicja techniczna
CVE-2025-3232 to podatność typu Missing Authentication for Critical Function (CWE-306) w smartRTU (≤ 3.37), umożliwiająca atakującemu z sieci wywołanie wrażliwej funkcji przez określoną trasę API bez poprawnego uwierzytelnienia, co według opisu CVE może skutkować wykonaniem dowolnych poleceń OS (impact wg CVSS: Integrity = High). W kontekście MITRE ATT&CK (ICS) najbliższe mapowanie to T0819 Exploit Public-Facing Application (Initial Access), często w praktyce łączone też z T0866 Exploitation of Remote Services oraz wykonaniem komend po przejęciu kontekstu (np. T0807 Command-Line Interface).
Gdzie występuje / przykłady platform
ICS/OT: smartRTU (urządzenie/komponent RTU używany w środowiskach przemysłowych, zwykle z interfejsem web/API do zarządzania).
Windows: pośrednio (stacje inżynierskie/HMI/jump hosty, z których administruje się smartRTU) – przydatne do korelacji EDR/SIEM.
AD: zwykle nie dotyczy bezpośrednio (chyba że integracja/SSO w warstwie IT).
AWS / Azure / GCP:nie dotyczy samej podatności, ale może dotyczyć ekspozycji (np. reverse proxy/WAF w chmurze).
K8s:nie dotyczy.
ESXi:nie dotyczy.
M365:nie dotyczy.
Szczegółowy opis techniki
Jak to działa (perspektywa defensywna)
W smartRTU istnieje funkcjonalność dostępna przez interfejs web/API, która powinna być chroniona uwierzytelnieniem/autoryzacją. W przypadku CVE-2025-3232 mechanizm ten jest niewystarczający: krytyczna funkcja (wywoływana przez “specific API route”) może zostać uruchomiona bez poprawnej autentykacji, co według opisu CVE prowadzi do wykonania poleceń OS.
Cele atakującego
W OT/ICS taki wektor wejścia jest atrakcyjny, bo:
daje zdalny foothold na urządzeniu brzegowym (RTU), często stojącym na styku sieci (telemetria, zdalne zarządzanie),
może umożliwić manipulację konfiguracją, “tampering” oraz potencjalnie przygotowanie gruntu pod kolejne kroki (ruch boczny, zmiana parametrów, sabotaż).
Dlaczego jest skuteczna
Brak wymogu poświadczeń (PR:N) i niska złożoność (AC:L) w CVSS oznacza, że przy złej ekspozycji (Internet / nieufne segmenty) ryzyko operacyjne szybko rośnie.
OT często ma ograniczony telemetry/EDR na urządzeniach embedded, więc “signal” detekcyjny bywa głównie sieciowy (FW/WAF/IDS) i z elementów pośredniczących.
Artefakty i logi
Źródło / warstwa
EID (Windows)
CloudTrail events
K8s audit
M365 operations
Co warto zbierać / na co patrzeć
Dostęp do interfejsu web/API smartRTU
N/A
N/A
N/A
N/A
Logi HTTP (reverse proxy/WAF), metoda POST/PUT/DELETE, nietypowe URI, skoki 4xx/5xx, nietypowe UA, duże payloady
Firewall / IDS/IPS
N/A
N/A
N/A
N/A
Inbound do panelu zarządzania (80/443 lub inne), źródła spoza allowlist, skanowanie, bursty requestów
Host/EDR na stacji inżynierskiej/jump hoście (jeśli zarządzanie z Windows)
4688, 4625/4624 (korelacje logowań)
N/A
N/A
N/A
Nietypowe procesy uruchomione w kontekście narzędzi admin/remote, “helper tools”, nowe połączenia sieciowe do RTU
Telemetria z urządzenia (jeśli dostępna)
N/A
N/A
N/A
N/A
Syslog/audit (o ile jest), historia poleceń, zmiany konfiguracji, restarty usług/urządzenia
WAF (jeśli publikujesz web)
N/A
(raczej) N/A
N/A
N/A
Reguły blokujące nietypowe requesty, anomalie w parametrach i nagłówkach; korelacja z ruchem zewnętrznym
Detekcja (praktyczne reguły)
Uwaga praktyczna: w OT często nie masz idealnych logów “z urządzenia”. Dlatego poniżej są reguły, które da się zastosować w warstwie pośredniej (WAF/reverse proxy) albo na hostach, które zbierają procesy (EDR). Nie używam tu żadnych “kroków exploitacji” ani nie podaję konkretnej trasy API – bo publiczne advisory mówi tylko o “specific API route”.
Sigma (gotowa reguła)
title: Possible Web/API Triggered OS Command Execution via Web Server Parent (smartRTU / CVE-2025-3232 context)
id: 3b2b8e3a-3c3d-4d6a-9d7a-1f6b62b8d6c1
status: experimental
description: |
Detects suspicious shell/process execution spawned by common embedded/web server processes.
Useful as compensating detection for scenarios where an unauthenticated API route may lead to OS command execution
(e.g., smartRTU CVE-2025-3232 and related chains).
references:
- https://nvd.nist.gov/vuln/detail/CVE-2025-3232
- https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/OT/white/2025/icsa-25-105-09.json
author: "Badacz CVE (SOC/Blue Team)"
date: 2025/12/25
tags:
- attack.initial_access
- attack.t1190
- attack.execution
logsource:
category: process_creation
product: linux
detection:
parent_websrv:
ParentImage|endswith:
- /nginx
- /apache2
- /httpd
- /lighttpd
- /uhttpd
- /boa
child_shell:
Image|endswith:
- /sh
- /bash
- /ash
- /busybox
cmd_susp:
CommandLine|contains:
- " -c "
- "wget "
- "curl "
- "nc "
- "mkfifo "
- "/dev/tcp/"
condition: parent_websrv and (child_shell or cmd_susp)
falsepositives:
- Legitimate CGI scripts or admin maintenance jobs that spawn shells from web services
- Firmware update routines implemented via web backend
level: high
Splunk (SPL)
Wariant A – proxy/WAF access logs (szukamy nieautoryzowanych prób do panelu/API):
index=net* (sourcetype=nginx:access OR sourcetype=apache:access OR sourcetype=waf)
dest_port IN (80,443)
| eval uri=coalesce(uri_path, uri, request)
| search http_method IN ("POST","PUT","DELETE") OR like(uri,"%api%")
| where NOT cidrmatch("10.0.0.0/8", src_ip) AND NOT cidrmatch("192.168.0.0/16", src_ip)
| stats count min(_time) as firstSeen max(_time) as lastSeen values(http_method) values(status) values(uri) by src_ip dest_ip
| sort -count
Wariant B – EDR/host telemetry (webserver → shell):
index=edr* sourcetype=process*
| where (parent_process_name IN ("nginx","httpd","apache2","lighttpd","uhttpd","boa"))
| where (process_name IN ("sh","bash","ash","busybox") OR like(process_command_line,"% -c %"))
| stats count min(_time) max(_time) values(process_command_line) by host user parent_process_name process_name
| sort -count
KQL (Azure)
Defender for Endpoint (jeśli masz DeviceProcessEvents z hostów/jump hostów):
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("nginx","httpd","apache2","lighttpd","uhttpd","boa")
| where FileName in~ ("sh","bash","ash","busybox") or ProcessCommandLine has " -c "
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp desc
Azure WAF / App Gateway (jeśli smartRTU stoi za takim frontem):
AzureDiagnostics
| where Category has "ApplicationGatewayFirewallLog"
| where action_s == "Blocked" or ruleSetType_s =~ "OWASP"
| project TimeGenerated, clientIp_s, requestUri_s, requestMethod_s, message_s, ruleId_s
| order by TimeGenerated desc
CloudTrail query (AWS CLI/CloudWatch)
CloudTrail nie loguje ruchu HTTP do smartRTU (to nie są wywołania AWS API). Jeżeli jednak wystawiasz smartRTU przez AWS WAF/ALB, sensowniejsze jest pytanie CloudWatch Logs Insights na logach WAF:
fields @timestamp, httpRequest.clientIp as srcIp, httpRequest.httpMethod as method, httpRequest.uri as uri, action, terminatingRuleId
| filter method in ["POST","PUT","DELETE"] or uri like /api/
| stats count() as hits, min(@timestamp) as firstSeen, max(@timestamp) as lastSeen by srcIp, method, uri, action
| sort hits desc
Elastic/EQL przykłady
process
where host.os.type == "linux"
and process.parent.name in ("nginx","httpd","apache2","lighttpd","uhttpd","boa")
and (
process.name in ("sh","bash","ash","busybox")
or process.command_line like "* -c *"
)
Heurystyki / korelacje
Ruch sieciowy → objaw na hoście: burst requestów HTTP/HTTPS do interfejsu zarządzania + w krótkim oknie czasowym proces potomny typu shell (jeśli masz telemetrię).
Źródło spoza polityki dostępu: jakikolwiek request do panelu/API smartRTU z IP spoza allowlist (VPN/management VLAN).
Zmiany konfiguracyjne / restarty: anomalia w dostępności RTU, restart usług, zmiany parametrów – skorelowane czasowo z nietypowym ruchem do web/API.
Skanowanie: rozproszony ruch do portów zarządczych (80/443) poprzedzający właściwe wywołania.
FW/IDS: ruch do portów zarządczych z “dziwnych” źródeł,
EDR: webserver → shell (jeśli masz).
4) Jeśli podejrzenie kompromitacji
Odizoluj urządzenie od sieci produkcyjnej (w OT zawsze z oceną wpływu na proces).
Zabezpiecz logi i artefakty z elementów pośrednich (WAF/FW/jump host).
Rotuj hasła/poświadczenia powiązane z dostępem administracyjnym i kanałami zdalnymi.
Rozważ kontrolę integralności konfiguracji (co się zmieniło i kiedy).
Przykłady z kampanii / case studies
Publiczne materiały dla smartRTU (ICSA-25-105-09 w formacie CSAF) wskazują, że raportującym był Claroty Team82 (w acknowledgments), a w sekcji “Recommended Practices” pada stwierdzenie o braku znanej publicznej exploitacji ukierunkowanej na tę podatność (na moment publikacji/rewizji).
Lab (bezpieczne testy) — przykładowe komendy
Tylko w odseparowanym labie OT (VLAN/lab), za zgodą właściciela środowiska. Celem jest walidacja ekspozycji i detekcji, nie test exploitów.
Test 1: czy urządzenie/panel jest wystawiony tam, gdzie nie powinien
CVE-2025-61884 dotyczy Oracle E-Business Suite (EBS) → Oracle Configurator → komponent Runtime UI w wersjach 12.2.3–12.2.14 i jest zdalnie wykorzystywalna bez uwierzytelnienia przez HTTP/HTTPS.
Ocena producenta/NVD wskazuje na wysoki wpływ na poufność (CVSS 3.1: 7.5, C:H / I:N / A:N), czyli przede wszystkim nieautoryzowany dostęp/wyciek danych.
W praktyce jest opisywana jako pre-auth SSRF (nazwa w KEV/NVD oraz alerty branżowe/instytucjonalne), a publiczne raporty łączą ją z aktywnym wykorzystywaniem i publicznie dostępnym PoC.
W ATT&CK najlepiej mapuje się do T1190 – Exploit Public-Facing Application (Initial Access); MITRE wskazuje m.in. WAF, filtrowanie ruchu i patching jako kluczowe mitygacje.
Krótka definicja techniczna (1 akapit)
CVE-2025-61884 to podatność w publicznie wystawionym komponencie webowym (Oracle Configurator Runtime UI), która umożliwia niezalogowanemu atakującemu doprowadzenie aplikacji do zachowań niezamierzonych (w raportach klasyfikowanych jako SSRF) i w konsekwencji uzyskanie dostępu do wrażliwych zasobów/danych; w ATT&CK odpowiada temu T1190 (Initial Access) – wejście przez podatną aplikację dostępną z Internetu.
Gdzie występuje / przykłady platform (Windows, AD, AWS, Azure, GCP, K8s, ESXi, M365)
Windows: rzadziej jako host EBS, ale jeśli front (proxy/WAF) lub komponenty pośrednie są na Windows — interesują logi IIS/reverse proxy oraz EDR na hoście aplikacji. (Rdzeń CVE jest jednak w komponencie EBS/Configurator).
AD: pośrednio — EBS bywa spięty z AD/SSO. Skutkiem może być ekspozycja danych i późniejsza eskalacja (np. kradzież konfiguracji, identyfikatorów, mapowań).
AWS: częsty scenariusz: EBS na EC2 + ALB/WAF + CloudWatch Logs. W kontekście SSRF szczególnie ważne: egress z serwera i ochrona przed dostępem do metadata endpoint (169.254.169.254).
Azure: analogicznie (App Gateway WAF / Front Door + Log Analytics). SSRF → ryzyko dostępu do metadanych instancji i tokenów, jeśli egress nie jest ograniczony.
GCP: podobny model (LB/WAF, logi HTTP LB, kontrola egress).
K8s: rzadziej dla EBS, ale jeśli komponent jest „opakowany” lub stoi za ingress — logi ingress + korelacja z egress kontenera.
ESXi: nie dotyczy bezpośrednio CVE, ale MITRE wskazuje T1190 także dla infrastruktury (gdy aplikacje/zarządzanie są wystawione).
M365: brak bezpośredniego wektora; może być użyte w łańcuchu (np. dalsza eksfiltracja).
Szczegółowy opis techniki (jak działa, cele, dlaczego jest skuteczna)
Kontekst CVE-2025-61884 w łańcuchu Initial Access
W przypadku Oracle EBS/Configurator Runtime UI, atakujący nie potrzebuje konta — wystarczy dostęp sieciowy do HTTP/HTTPS i podatnej wersji. To jest „książkowy” wariant T1190, bo aplikacja publicznie wystawiona staje się bramą do danych/zasobów.
Co realnie daje podatność
Oficjalny opis (Oracle/NVD) wskazuje na dostęp do „sensitive resources” oraz nieautoryzowany dostęp do krytycznych danych w ramach tego, co Oracle Configurator udostępnia.
W metadanych NVD/KEV podatność nazywana jest SSRF, a CISA-ADP przypisało m.in. CWE-918 (SSRF) oraz inne CWE, co sugeruje albo wieloprzymitywowy błąd, albo różne interpretacje łańcucha (ważne: Oracle zwykle nie publikuje pełnych detali technicznych).
Publiczne raporty wskazują, że poprawka wiązała się m.in. z walidacją parametru typu return_url, co jest typowym miejscem dla nadużyć SSRF/redirect/CRLF — dla SOC to cenna wskazówka do polowania w logach.
Dlaczego to jest skuteczne (z perspektywy atakującego)
Pre-auth (brak loginu) + niska złożoność (AC:L) = bardzo szybkie skanowanie Internetu i automatyzacja.
„Systemy biznesowe” (EBS) często zawierają dane finansowe/HR/procesowe, więc nawet „tylko” poufność (C:H) ma wysoki wpływ operacyjny.
MITRE rekomenduje podejście multi-signal (żądanie → błędy → proces/egress), bo same żądania HTTP nie zawsze wystarczą do pewnego potwierdzenia skutecznej eksploatacji.
Jeśli EBS jest za ingress: wzorce exploit-probing + egress z poda
M365
Unified Audit Log
—
—
Zwykle N/A dla samego CVE
Detekcja (praktyczne reguły)
Poniższe przykłady celują w telemetrię HTTP/WAF i klasyczne sygnały SSRF/probing. Wg publicznych raportów aktywność obejmowała m.in. endpointy UiServlet/SyncServlet oraz parametry redirekt/URL.
title: Oracle EBS Configurator Runtime UI - Suspicious SSRF / return_url Patterns (CVE-2025-61884)
id: 2a2c9c6d-6d2b-4b5a-9c86-5b2f7a3f3b7d
status: experimental
description: |
Detects suspicious requests to Oracle E-Business Suite (Oracle Configurator Runtime UI) endpoints
with URL/redirect parameters suggestive of SSRF/probing related to CVE-2025-61884.
author: Badacz CVE
date: 2025/12/23
tags:
- attack.initial_access
- attack.t1190
logsource:
category: webserver
detection:
selection_endpoint:
url.path|contains:
- "/configurator/UiServlet"
- "/OA_HTML/configurator/UiServlet"
- "/OA_HTML/SyncServlet"
selection_param:
url.query|contains:
- "return_url="
selection_ssrf_indicators:
url.query|contains:
- "http://"
- "https://"
- "file://"
- "gopher://"
- "ftp://"
- "169.254.169.254"
- "127.0.0.1"
- "localhost"
- "%0d%0a"
- "%0D%0A"
condition: selection_endpoint and selection_param and selection_ssrf_indicators
falsepositives:
- Rare legitimate redirect flows using absolute URLs (tune by source IP ranges, auth/session cookies, user agents, rate)
level: high
Splunk (SPL)
(index=web OR index=waf OR index=proxy)
| eval path=coalesce(url_path, uri_path, cs_uri_stem, request_path)
| eval query=coalesce(url_query, uri_query, cs_uri_query, query_string)
| where like(path, "%/configurator/UiServlet%")
OR like(path, "%/OA_HTML/configurator/UiServlet%")
OR like(path, "%/OA_HTML/SyncServlet%")
| where isnotnull(query) AND match(lower(query), "return_url=")
| where match(lower(query), "(http://|https://|file://|gopher://|ftp://|169\\.254\\.169\\.254|127\\.0\\.0\\.1|localhost|%0d%0a)")
| stats count as hits min(_time) as first_seen max(_time) as last_seen values(status) as status values(useragent) as ua by src_ip, host, path
| sort - hits
KQL (Azure / Microsoft Sentinel)
WAF / reverse proxy w Log Analytics (przykład ogólny):
let suspiciousPaths = dynamic([
"/configurator/UiServlet",
"/OA_HTML/configurator/UiServlet",
"/OA_HTML/SyncServlet"
]);
AzureDiagnostics
| extend path = tostring(requestUri_s), query = tostring(queryString_s), clientIp = tostring(clientIP_s)
| where path has_any (suspiciousPaths)
| where query has "return_url="
| where query has_any ("http://","https://","file://","gopher://","ftp://","169.254.169.254","127.0.0.1","%0d%0a")
| summarize hits=count(), first_seen=min(TimeGenerated), last_seen=max(TimeGenerated),
ua=makeset(userAgent_s, 5) by clientIp, path
| order by hits desc
CloudTrail query (AWS CLI/CloudWatch)
Dla tej klasy zdarzeń CloudTrail zwykle nie pomoże (to nie są API calls), ale sensowny jest CloudWatch Logs Insights na AWS WAF logs:
fields @timestamp, httpRequest.clientIp, httpRequest.uri, httpRequest.args, action, terminatingRuleId
| filter httpRequest.uri like /\/configurator\/UiServlet|\/OA_HTML\/configurator\/UiServlet|\/OA_HTML\/SyncServlet/
| filter httpRequest.args like /return_url=/
| filter httpRequest.args like /http:\/\/|https:\/\/|169\.254\.169\.254|127\.0\.0\.1|localhost|%0d%0a/i
| stats count() as hits, min(@timestamp) as first_seen, max(@timestamp) as last_seen,
values(action) as actions, values(terminatingRuleId) as rules
by httpRequest.clientIp, httpRequest.uri
| sort hits desc
Elastic/EQL przykłady
Kibana KQL (logi HTTP/WAF w ECS):
url.path : ("/configurator/UiServlet" or "/OA_HTML/configurator/UiServlet" or "/OA_HTML/SyncServlet")
and url.query : ("return_url=" and ("http://" or "https://" or "file://" or "gopher://" or "ftp://" or "169.254.169.254" or "127.0.0.1" or "localhost" or "%0d%0a"))
sequence by host.id with maxspan=5m
[network where network.direction == "inbound"
and url.path in ("/configurator/UiServlet", "/OA_HTML/configurator/UiServlet", "/OA_HTML/SyncServlet")]
[network where network.direction == "outbound"
and destination.ip in ("169.254.169.254","127.0.0.1")]
Heurystyki / korelacje (co łączyć)
Korzystaj z podejścia „multi-signal correlation” (MITRE):
Sygnał 1 — inbound probing: nietypowe żądania do servletów Configurator/Sync, często z zewnętrznych adresów i bez kontekstu sesji.
Sygnał 2 — WAF / error spike: wzrost blokad WAF, 4xx/5xx w krótkim oknie czasu. (Cloudflare dodał nawet dedykowaną detekcję „Oracle EBS – SSRF – CVE-2025-61884”).
Sygnał 3 — egress anomalia: serwer EBS inicjuje połączenia do nietypowych hostów (wewnętrznych, link-local, metadata). To jest kluczowe przy SSRF.
Sygnał 4 — data exfil: duże odpowiedzi HTTP (bytes out) / długie czasy odpowiedzi dla endpointów Runtime UI, szczególnie bez typowego flow aplikacyjnego.
Sygnał 5 — kontekst zagrożenia: CVE zostało dodane do KEV (NVD pokazuje daty dodania i deadline), co zwiększa priorytet i uzasadnia hunting retrospektywny.
False positives / tuning
Typowe FP i jak je ograniczać:
Legalne użycie redirectów: jeśli aplikacja używa parametru return_url do nawigacji — dopuszczalne, ale zwykle:
pochodzi z wewnętrznych adresów IP/VPN,
ma spójny user-agent,
występuje w obecności cookie/sesji. Tuning: ogranicz detekcję do źródeł spoza korporacyjnych CIDR, dodaj warunek braku sesji, dodaj próg częstotliwości (rate).
Skanery podatności w organizacji: wpisz je na allowlistę (IP/UA), ale zachowaj osobny dashboard „security scanning activity”.
WAF sygnatury: jeśli korzystasz z Cloudflare — śledź nową regułę dla CVE-2025-61884 jako sygnał, ale koreluj z ruchem „allowed”, bo część kampanii może próbować obejść WAF przez inne ścieżki (np. bez WAF lub przez inne punkty wejścia).
Playbook reagowania (kroki + komendy)
Natychmiastowe ograniczenie ryzyka (containment)
Odetnij Internet → Runtime UI / EBS (tymczasowo: allowlist VPN/bastion/WAF). MITRE wprost rekomenduje ograniczenie ekspozycji usług oraz segmentację/DMZ.
Włącz/zaostrz WAF (jeśli masz Cloudflare — zweryfikuj, czy działa reguła dla CVE-2025-61884).
Ogranicz egress z serwera EBS (SSRF „żyje” egress’em).
Przykład (Linux, defensywnie – blokada metadata; dopasuj do polityk):
sudo iptables -A OUTPUT -d 169.254.169.254 -j REJECT
sudo iptables -A OUTPUT -d 127.0.0.1 -p tcp --dport 80 -j REJECT
Patching i weryfikacja
Zastosuj Oracle Security Alert z 11 października 2025 (Rev 1); Oracle wskazuje, że wersje spoza wsparcia mogły nie być testowane, ale „prawdopodobnie” wcześniejsze też mogą być dotknięte → jeśli masz starsze EBS, traktuj to jak ryzyko wysokie i planuj upgrade.
Hunting (retrospektywnie 30–90 dni)
Szybkie grepy (ścieżki dopasuj do Oracle HTTP Server / reverse proxy):
Traktuj to jak incydent o możliwym wpływie na dane: identyfikacja zakresu wycieku, powiadomienia, analiza kont/SSO integracji.
Publiczne raporty opisują złożone łańcuchy exploitacji w ekosystemie EBS (różne CVE i różne łańcuchy); nawet jeśli CVE-2025-61884 ma CVSS tylko na poufność, w praktyce SOC powinien sprawdzić, czy nie wystąpiły sygnały „post-exploit”.
Przykłady z kampanii / case studies
Dodanie do KEV (widoczne w NVD) sugeruje dowody aktywnego wykorzystania i podbija priorytet patchowania/huntingu (NVD pokazuje „Date Added: 2025-10-20” oraz deadline).
CSA Singapur opublikowała alert wprost o aktywnej eksploatacji SSRF i podała, że PoC jest publicznie dostępny.
Media branżowe raportowały, że exploit/PoC miał zostać ujawniony publicznie (m.in. w wątku „ShinyHunters”), a Oracle wypuścił poprawkę out-of-band.
Kontekst kampanii extortion wokół Oracle EBS był szeroko opisywany, m.in. przez Reuters (z zastrzeżeniem, że ocena prawdziwości części twierdzeń napastników bywała na tamtym etapie niepewna).
Lab (bezpieczne testy) — przykładowe komendy
Cel labu dla Blue Team: zweryfikować ekspozycję, widoczność w logach i skuteczność detekcji, bez „odtwarzania exploitów”.
Sprawdź ekspozycję portów i usług (host EBS / reverse proxy):
sudo ss -lntp | egrep ':(80|443)\s'
Wygeneruj kontrolowany „ruch testowy” do standardowej strony (bez payloadów CVE), aby upewnić się, że logi trafiają do SIEM:
curl -kI https://twoj-host-ebs.example/ | head
Test parsowania i reguł detekcji na „sztucznych” wpisach logów (bez kontaktu z EBS):
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.
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).
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):
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).
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.
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).
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)
