React2Shell w praktyce: jak atakujący przejmują ruch WWW przez złośliwe konfiguracje NGINX - Security Bez Tabu

React2Shell w praktyce: jak atakujący przejmują ruch WWW przez złośliwe konfiguracje NGINX

Wprowadzenie do problemu / definicja luki

Na początku grudnia 2025 r. ujawniono krytyczną podatność React2Shell (CVE-2025-55182) w React Server Components (RSC), ocenioną na CVSS 10.0, umożliwiającą nieautoryzowane zdalne wykonanie kodu (RCE). Co istotne, ryzyko nie ogranicza się do „egzotycznych” implementacji — obecność podatnych pakietów RSC w środowisku często bywa wystarczająca, by atak był możliwy.

W lutym 2026 r. badacze opisali kolejną, bardzo praktyczną ewolucję post-exploitation: po uzyskaniu dostępu atakujący modyfikują konfiguracje NGINX, by przechwytywać i przekierowywać legalny ruch użytkowników przez własną infrastrukturę (klasyczny model Adversary-in-the-Middle, tylko „w warstwie reverse proxy”).

W skrócie

  • Punkt wejścia: w wielu obserwacjach — React2Shell (CVE-2025-55182) jako początkowy RCE (wnioskowane na podstawie korelacji czasowej i overlapu infrastruktury).
  • Cel operacji: „ciche” przejęcie ścieżek URL w NGINX i przekierowanie wybranych żądań do serwerów napastnika.
  • Twarde sygnały kompromitacji: podejrzane bloki location, rewrite, proxy_pass, niestandardowe domeny backendów, artefakty mapowania w /tmp, oraz wskazane w analizie domeny/IP C2.
  • Kogo to dotyczy: szczególnie środowiska z NGINX oraz panele zarządzania hostingiem (np. Baota/BT), a także domeny w wybranych TLD (m.in. .in, .id) i sektory publiczne/edukacyjne (.gov, .edu).

Kontekst / historia / powiązania

React2Shell został publicznie ujawniony 3 grudnia 2025 r. i niemal natychmiast zaczął być masowo wykorzystywany przez różne klastry zagrożeń: od aktorów oportunistycznych (np. cryptomining) po grupy o profilu szpiegowskim.

Równolegle do „klasycznych” łańcuchów (droppery, backdoory, minery), obserwujemy coraz częściej monetyzację dostępu poprzez przejęcie ruchu WWW — to wygodne, bo:

  • nie zawsze wymaga „hałaśliwego” malware na endpointach,
  • może generować zysk (np. przekierowania, phishing, wstrzykiwanie treści),
  • a jednocześnie bywa trudne do wykrycia, jeśli ktoś nie monitoruje integralności konfiguracji reverse proxy.

Analiza techniczna / szczegóły luki

1) React2Shell (CVE-2025-55182) – gdzie jest problem?

React opisał podatność jako krytyczną lukę w pakietach RSC:

  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack

Podatne były m.in. wersje 19.0, 19.1.0, 19.1.1, 19.2.0, a poprawki wprowadzono w 19.0.1 / 19.1.2 / 19.2.1.

Microsoft zwraca uwagę na mechanikę problemu: niewystarczająca walidacja przychodzących danych w określonych wersjach RSC może prowadzić do wstrzyknięcia struktur akceptowanych przez React i finalnie do RCE (m.in. przez podatne wzorce przetwarzania danych).

2) Po RCE: przejęcie NGINX przez złośliwe location + proxy_pass

W opisywanej kampanii atakujący po uzyskaniu dostępu wdrażają zestaw skryptów shellowych, które automatycznie „wstrzykują” bloki konfiguracji NGINX. Kluczowy wzorzec wygląda (koncepcyjnie) tak:

  • dopasowanie konkretnej ścieżki: location /%PATH%/ { ... }
  • zbudowanie pełnego URL: set $fullurl "$scheme://$host$request_uri";
  • przepięcie na backend napastnika przez proxy_pass
  • zachowanie kontekstu żądania przez liczne proxy_set_header (Host, X-Real-IP, X-Forwarded-For, User-Agent, Referer, itd.)
  • dodatkowo rewrite, aby zamienić „ładny” path na parametr (np. index.php?domain=...) po stronie infrastruktury napastnika

Efekt: użytkownik trafia na poprawnie działającą stronę/ścieżkę, ale wybrane żądania przechodzą przez serwer kontrolowany przez atakującego — co daje możliwość podmiany treści, wstrzyknięć, przekierowań, kradzieży sesji (w zależności od reszty stacku) i budowy dalszych łańcuchów ataku.

3) Toolkit: automatyzacja, persystencja i „bezawaryjne” przejęcie

Datadog opisał wieloetapowy toolkit. Najważniejsze elementy z perspektywy obrony:

  • zx.sh – orkiestrator (pobieranie/kolejne etapy). Ciekawy detal: gdy curl/wget są blokowane, używa surowych połączeń TCP przez /dev/tcp do pobierania treści.
  • bt.sh – wariant ukierunkowany na Baota/BT, operujący na ścieżkach panelu (m.in. /www/server/panel/vhost/nginx) i nadpisujący konfiguracje.
  • 4zdh.sh – „mocniejszy” wariant: enumeracja popularnych lokalizacji NGINX (/etc/nginx/sites-enabled, /etc/nginx/conf.d, itd.), walidacja przez nginx -t, oraz artefakt mapowania w /tmp/.domain_group_map.conf.
  • zdh.sh – węższe targetowanie (Linux/kontenery) i wybrane TLD.
  • ok.sh – raportowanie reguł hijackingu i eksfiltracja mapy do wskazanego C2.

4) IoC z raportu Datadog (przykłady)

W analizie wskazano m.in. domeny backendów oraz host C2 do uploadu (w formie IoC). Przykładowo:

  • backendy: xzz.pier46[.]com, ide.hashbank8[.]com, th.cogicpt[.]org
  • C2/upload target: 158.94.210[.]227
  • artefakt persystencji/trackingu: /tmp/.domain_group_map.conf

Praktyczne konsekwencje / ryzyko

  1. Przechwycenie ruchu bez „widocznego malware” na stacjach
    Jeśli NGINX stoi przed aplikacją (częste), zmiana konfiguracji może być wystarczająca, by przejąć wybrane ścieżki i prowadzić działania w tle.
  2. Ryzyko phishingu / podmiany treści / złośliwych przekierowań
    Atakujący, kontrolując backend dla części requestów, może serwować alternatywne odpowiedzi dla określonych endpointów (np. „/help”, „/news”, „/blog” — w zależności od wzorca).
  3. Dalsza eskalacja i utrzymanie dostępu
    Jeżeli punkt wejścia to RCE, NGINX-hijacking bywa świetnym mechanizmem persystencji: nawet po częściowym sprzątaniu systemu, konfiguracja reverse proxy może nadal „robić swoje”.

Rekomendacje operacyjne / co zrobić teraz

A. Natychmiastowa redukcja ryzyka (patching i weryfikacja ekspozycji)

  • Zaktualizuj podatne pakiety RSC do co najmniej 19.0.1 / 19.1.2 / 19.2.1 (zgodnie z gałęzią, której używasz).
  • Jeśli używasz ekosystemu Next.js/React w produkcji, załóż, że skanowanie i próby exploitacji są powszechne (wiele klastrów, różne payloady).

B. Polowanie na oznaki przejęcia NGINX

  • Przejrzyj konfiguracje NGINX pod kątem nietypowych location oraz par rewrite + proxy_pass kierujących na nieznane domeny.
  • Szukaj artefaktów wskazanych w raporcie (np. /tmp/.domain_group_map.conf) i zweryfikuj, czy w /tmp lub /dev/shm nie pojawiają się pliki raportujące/mapujące reguły.
  • Zweryfikuj logi zmian: kiedy modyfikowano pliki w /etc/nginx/** lub katalogach paneli (np. BT).

C. Monitoring integralności i hardening

  • Wdróż File Integrity Monitoring (FIM) dla ścieżek NGINX (wszystkie katalogi konfiguracyjne + te specyficzne dla paneli). Datadog podaje przykładowy warunek detekcji dla zapisu plików .conf w typowych lokalizacjach.
  • Ogranicz dostęp do paneli zarządzania (np. BT): tylko VPN/allowlista, MFA, rotacja haseł i kluczy, blokada publicznej ekspozycji. (To dobra praktyka niezależnie od kampanii; w tej kampanii BT jest wyraźnie wskazywany jako środowisko docelowe).

D. Incident response (gdy znajdziesz kompromitację)

  • Załóż, że NGINX-hijacking to etap po włamaniu: sprawdź, jak uzyskano dostęp (podatne RSC/Next.js, exposed serwisy, klucze, itp.).
  • Usuń złośliwe bloki, odtwórz konfiguracje z repo/backupów, wykonaj nginx -t, przeładuj usługę, a następnie przeanalizuj „pamięć” systemu: crony, systemd, kontenery, nowe binarki/skrypty.

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

Typowe post-exploitation po RCE w web stacku to dropper + miner/backdoor. React2Shell jest jednak interesujący, bo:

  • bywa masowo wykorzystywany przez wiele typów aktorów (od opportunistów po grupy przypisywane państwom),
  • a przejęcie NGINX to „sprytna” monetyzacja/operacjonalizacja dostępu: mniej widoczne niż koparka, a często bardziej dochodowe/strategiczne (szczególnie gdy reverse proxy obsługuje krytyczne domeny lub ruch sektorów .gov/.edu).

Podsumowanie / kluczowe wnioski

  • CVE-2025-55182 (React2Shell) to nie tylko „jednorazowy exploit” — w 2026 r. obserwujemy, jak dostęp po RCE jest przekuwany w przejęcie ruchu WWW poprzez modyfikacje NGINX.
  • Najgroźniejsze są scenariusze, w których NGINX stoi na styku użytkownik ↔ aplikacja, bo wtedy atakujący może sterować ruchem na poziomie reverse proxy.
  • Priorytety obrony: patch React/RSC, monitoruj integralność konfiguracji NGINX, oraz traktuj wszelkie anomalie w location/proxy_pass jako potencjalny sygnał kompromitacji.

Źródła / bibliografia

  1. Datadog Security Labs – analiza kampanii hijackingu ruchu przez złośliwe konfiguracje NGINX (securitylabs.datadoghq.com)
  2. The Hacker News – omówienie kampanii i kontekstu React2Shell→NGINX traffic hijacking (The Hacker News)
  3. React.dev – oficjalny komunikat o krytycznej podatności CVE-2025-55182 i wersjach naprawionych (react.dev)
  4. Google Threat Intelligence Group – obserwacje masowej eksploatacji i rekomendacje obrony (Google Cloud)
  5. Microsoft Security Blog – techniczny kontekst podatności i podejście defensywne (Microsoft)