NGINX-Config-Manipulation ermöglicht dauerhafte Traffic-Kontrolle React2Shell-Kampagne missbraucht NGINX-Konfigurationen

Ein Gastbeitrag von Ryan Simon 3 min Lesedauer

Anbieter zum Thema

Sicherheitsforscher beobachteten kurz nach der React2Shell-Offenlegung eine Kampagne, die Web-Traffic über manipulierte NGINX-Kon­fi­gu­ra­ti­ons­da­tei­en umleitet. Angreifer schleusen sich in Live-Traffic ein, greifen Zu­gangs­da­ten ab und übernehmen Sessions. Wir erklären, wie die Umleitung funk­tioniert und was Admins jetzt prüfen sollten.

Eine Analyse von Datadog Security zeigt, wie Angreifer NGINX-Konfigurationen missbrauchen, um sich in Live-Traffic einzuklinken.(Bild: ©  Santiago - stock.adobe.com)
Eine Analyse von Datadog Security zeigt, wie Angreifer NGINX-Konfigurationen missbrauchen, um sich in Live-Traffic einzuklinken.
(Bild: © Santiago - stock.adobe.com)

Am 3. Dezember wurde eine kritische Schwachstelle (CVE-2025-55182) in populären ser­ver­sei­ti­gen JavaScript-Frameworks öffentlich gemacht, die unter dem Namen „React2Shell“ diskutiert wird. Datadog Security Research beobachtete nach der Offenlegung die Ausnutzung „in the wild“ und identifizierte dabei eine Kampagne, die Web-Traffic umleite und das nicht primär über neue Malware-Binaries, sondern über manipulierte NGINX-Konfigurationsdateien. Ziel: le­gi­ti­me Nutzeranfragen werden transparent über Angreifer-kontrollierte Backend-Server geroutet.

Warum das mehr ist als „klassischer“ Webserver-Compromise

Was diese Kampagne besonders gefährlich macht, ist, dass Angreifer sich nicht nur Daten greifen, die bereits auf dem Server liegen, sondern sich still in den laufenden Nutzer-Traffic schieben. Das verschiebt die Risikolage deutlich. Denn wer Live-Traffic kontrolliert, bekommt im Prinzip eine dauerhafte Position zwischen User und Anwendung.

Das ermöglicht Angreifern über längere Zeiträume, Zugangsdaten und Session-Cookies abzugreifen. Accounts zu übernehmen, Nutzerdaten während der Übertragung mitzulesen oder zu stehlen, obwohl sie durch die legitime Anwendung fließen, sowie Webseiten oder API-Antworten in Echtzeit zu manipulieren – bis hin zur Malware-Auslieferung oder Account-Übernahme, während die Website nach außen unauffällig weiterläuft.

Kampagnenstart kurz nach Disclosure

Auf Basis von Zeitstempeln und der Exploit-Logik in den beobachteten Skripten lässt sich der Start der Kampagne in den frühen bis mittleren Dezember einordnen. Also zeitlich eng an die initiale Offenlegung und Ausnutzung von React2Shell gekoppelt.

Traffic-Hijacking erfolgt hier über manipulierte bestehende NGINX-Konfigurationen statt über neue, auffällige Binaries. Da NGINX eine zentrale Komponente moderner Web-Infrastrukturen ist, bedeutet Kontrolle der Konfiguration auch Kontrolle über Routing. Das ist für Verteidiger besonders heikel, weil signatur- und prozessbasierte Security-Kontrollen ins Leere laufen können, wenn die schädliche Logik in legitimen Config-Dateien steckt.

Wie die Umleitung technisch funktioniert

Im Kern missbraucht die Kampagne typische NGINX-Direktiven:

  • location: definiert, welche Requests wie verarbeitet werden
  • rewrite: verändert Request-URLs, um sie an ein Backend-Pattern anzupassen
  • proxy_pass: leitet Requests an einen Upstream/Backend-Server weiter
  • proxy_set_header: hält Header-Kontext (Host, Forwarded-For etc.) konsistent, was die Umleitung unauffälliger machen kann

Die beobachtete Logik nutzt einen Pfad-Platzhalter (z. B. /%PATH%/), baut daraus die volle URL zusammen und proxyt dann zu einer attacker-kontrollierten Domain. Auffällig ist: Header wie X-Forwarded-For, User-Agent oder Referer werden bewusst weitergereicht. Der Request wirkt dadurch für das Backend „echt“.

Die eingesetzten Templates unterscheiden sich je nach Top-Level-Domain (TLD) und nutzen teils „unauffällige“ Pfade wie help, news, blog, about oder auch game, live, casino.

Betroffene Zielgruppen und Infrastruktur

Auffällig ist zudem ein geografisch wirkendes Zielmuster: Die Kampagne richte sich unter anderem gegen Domains mit asiatischen Top-Level-Domains wie .in, .id, .pe oder .bd aber auch gegen .edu- und .gov-Domains sowie .th. Ein weiteres Merkmal ist der Fokus auf Umgebungen mit chinesischer Hosting-Infrastruktur und Management-Panels wie Baota (BT), die in bestimmten Regionen verbreitet sind.

Was jetzt zu tun ist: Patchen und Compromise einkalkulieren

Admins sollten die betroffenen Frameworks unbedingt patchen, insbesondere wenn Next.js oder andere betroffene Frameworks eingesetzt werden. Wenn nicht innerhalb weniger Stunden nach der initialen Offenlegung gepatcht wurde, sollte man laut Datadog davon ausgehen, dass eine Kompromittierung möglich ist, da „high volumes of automated, large-scale exploitation“ beobachtet wurden.

  • 1. React2Shell-Patches einspielen (Framework-/App-seitig).
  • 2. NGINX-Konfigurationsänderungen im fraglichen Zeitraum prüfen (Diffs, mtime, Deploy-Historie).
  • 3. Reload/Restart-Ereignisse korrelieren (wann wurde NGINX neu geladen?).
  • 4. Konfigurationen auf unerwartete Proxies und verdächtige location-Pfade untersuchen. Alle Indicators of Compromise, die geprüft werden sollten, finden sich in diesem Blogbeitrag.
  • 5. Credential- und Session-Rotation erwägen, wenn Traffic-Hijacking nicht ausgeschlossen werden kann.

Warum Observability hier zum Security-Thema wird

Web-Traffic-Hijacking über NGINX-Konfigurationen ist brisant, weil es oft nicht wie klassische Malware aussieht und lange unbemerkt bleiben kann – inklusive Datendiebstahl, Session-Übernahme und Content-Manipulation. Deshalb reicht der Blick auf Netzwerk- oder Endpoint-Signale allein nicht aus: Entscheidend sind Sichtbarkeit von Konfigurationsänderungen, Service-Reloads und Routing-Anomalien sowie die Nachvollziehbarkeit, ob Traffic plötzlich zu unerwarteten Backends abfließt.

Über den Autor: Ryan Simon arbeitet bei Datadog als Senior Security Researcher. Seine Leidenschaft gilt Sicherheitsarchitekturen, Cloud-native Technologien und insbesondere der Schnittstelle zwischen beiden Bereichen.

(ID:50772023)

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung