Wenige Tage nach der Offenlegung der kritischen Schwachstelle React2Shell (CVE-2025-55182) beobachten Analysten von Sysdig bereits breit angelegte Angriffe auf Next.js-Anwendungen. Ziel der Kampagne ist die Verteilung einer neuen Linux-Malware namens EtherRAT, die sich durch den Missbrauch von Ethereum-Smart-Contracts als Command-and-Control-Infrastruktur (C2) und durch robuste Persistenzmechanismen auszeichnet.
React2Shell: Kritische RCE-Schwachstelle in React Server Components und Next.js
React2Shell ist eine Remote-Code-Execution-Schwachstelle (RCE) in den React Server Components und wurde mit der maximalen CVSS-Bewertung 10.0 eingestuft. Ursache ist eine unsichere Deserialisierung von Daten auf Serverseite. Ein gewöhnlicher HTTP-Request ohne Authentifizierung oder erhöhte Rechte genügt, um beliebigen Code auf dem Zielserver auszuführen.
Betroffen sind insbesondere die React-Versionen 19.0, 19.1.0, 19.1.1 und 19.2.0 in Standardkonfiguration sowie Anwendungen auf Basis von Next.js. Patches stehen in React 19.0.1, 19.1.2, 19.2.1 und den jeweils aktualisierten Next.js-Versionen bereit. Dennoch sind nach Erkenntnissen von Sysdig weiterhin zahlreiche verwundbare Instanzen öffentlich erreichbar – ein typisches Bild, da laut Branchenstudien wichtige Sicherheitsupdates in vielen Unternehmen Wochen bis Monate verzögert ausgerollt werden.
Die Schwachstelle wird mindestens von zwei chinesischen Akteuren, Earth Lamia und Jackpot Panda, aktiv ausgenutzt; betroffen sind bereits über 30 Organisationen. Experten warnen zudem, dass ähnliche Implementierungen von React Server Components – etwa in Vite RSC plugin, Parcel RSC plugin, React Router RSC preview, RedwoodSDK oder Waku – anfällig für vergleichbare Fehler sein könnten.
Angriffskette: Von HTTP-Request zu versteckter Node.js-Umgebung
Die beobachtete Angriffskette beginnt mit der Ausnutzung von React2Shell (MITRE ATT&CK: T1190 – Exploit Public-Facing Application). Über die Schwachstelle wird ein base64-kodierter Shell-Befehl eingeschleust, der in einer Schleife alle 300 Sekunden versucht, ein Skript s.sh per curl, wget oder python3 nachzuladen. Erst nach erfolgreichem Download wird das Skript ausführbar gemacht und gestartet.
Dieses Skript legt ein verstecktes Verzeichnis unter $HOME/.local/share/ an und lädt von dort aus einen legitimen Node.js-20.10.0-Binary direkt von nodejs.org. Der Einsatz einer authentischen, signierten Binärdatei erschwert die Erkennung, da viele Sicherheitstools legitime Entwickler-Umgebungen nur eingeschränkt kontrollieren.
Anschließend werden ein verschlüsselter Payload sowie ein obfuskierter JavaScript-Dropper abgelegt. Der Dropper wird über den frisch installierten Node.js-Interpreter gestartet, entschlüsselt den Payload mithilfe eines fest kodierten AES-256-CBC-Schlüssels und schreibt das Ergebnis als weiteren versteckten JS-Code, der wiederum ausgeführt wird. Dieses letzte Stadium bildet die eigentliche Malware EtherRAT. Abschließend löscht s.sh sich selbst, um forensische Spuren zu minimieren.
EtherRAT: Linux-Malware mit Ethereum-Smart-Contracts als C2-Kanal
Das technisch herausragendste Merkmal von EtherRAT ist die Nutzung von Ethereum-Smart-Contracts als C2-Infrastruktur. Die Malware fragt parallel neun öffentliche Ethereum-RPC-Provider ab und wählt die C2-Information anhand eines Mehrheitsentscheids. Dieser Ansatz macht klassische Gegenmaßnahmen wie das Abschalten einzelner Nodes oder Sinkholing einzelner Domains deutlich weniger effektiv.
In kurzen Intervallen von rund 500 Millisekunden generiert EtherRAT zufällige, CDN-ähnliche URLs, kontaktiert darüber den Steuerungsmechanismus und führt den zurückgelieferten JavaScript-Code über AsyncFunction direkt im Speicher aus. So erhalten Angreifer einen interaktiven Node.js-Shell, der sich flexibel steuern lässt, ohne neue Dateien auf dem Dateisystem abzulegen – ein Muster, das signaturbasierte Erkennung stark erschwert.
Diese Technik reiht sich in den bekannten Trend „EtherHiding“ ein, der bereits von Google Threat Analysis Group und GuardioLabs beschrieben wurde. Sysdig erkennt zudem Parallelen im verschlüsselten Loader von EtherRAT zu der Malware BeaverTail aus der Kampagne „Contagious Interview“, die mutmaßlich der nordkoreanischen Gruppe Lazarus zugeschrieben wird. Dies deutet auf mögliche Code-Reuse oder Kooperation zwischen unterschiedlichen Akteuren hin.
Mehrschichtige Persistenz und Selbstaktualisierung auf Linux
Auf kompromittierten Linux-Systemen setzt EtherRAT laut Analyse mindestens fünf parallele Persistenzmechanismen ein. Typische Techniken umfassen manipulierte Autostart-Konfigurationen, Cron-Jobs, systemd-Services und benutzerbezogene Startskripte. Dieser Defence-in-Depth-Ansatz führt dazu, dass das Entfernen eines einzelnen Prozesses oder einer Datei in der Regel nicht ausreicht, um die Malware vollständig zu eliminieren.
Besonders problematisch ist zudem das Selbstaktualisierungs-Feature. EtherRAT sendet seinen eigenen Quellcode an einen dedizierten API-Endpunkt und erhält eine funktional identische, aber anders obfuskierte Version zurück. Die Malware überschreibt daraufhin sich selbst und startet neu. Dadurch verlieren statische Signaturen und herkömmliche YARA-Regeln schnell an Wirksamkeit, und Angreifer können ihre Taktiken mit minimaler Vorlaufzeit an neue Schutzmaßnahmen anpassen.
Empfohlene Schutzmaßnahmen für React- und Next.js-Umgebungen
Organisationen, die React, React Server Components oder Next.js in Linux- oder Cloud-Umgebungen einsetzen, sollten umgehend handeln. Priorität haben:
1. Sofortige Patch-Strategie und Code-Review
Admins und DevSecOps-Teams sollten React mindestens auf Version 19.0.1, 19.1.2 oder 19.2.1 aktualisieren und die passenden Next.js-Releases einspielen. Zusätzlich ist ein Code-Review aller Komponenten zu empfehlen, die serverseitige Deserialisierung verwenden, insbesondere in alternativen React-Server-Implementierungen.
2. Forensische Prüfung der Server
Systeme sollten auf versteckte Verzeichnisse unter $HOME/.local/share/, unerwartete Node.js-Installationen, Dateien wie s.sh sowie auffällige Node-Prozesse geprüft werden, insbesondere wenn diese unter Service- oder Applikationskonten laufen.
3. Erkennung von Persistenz und IoCs
Es empfiehlt sich, Autostart-Mechanismen, Cron-Tabellen und systemd-Units systematisch auf Anomalien zu untersuchen und die Infrastruktur mit den von Sysdig veröffentlichten Indicators of Compromise (IoCs) abzugleichen. EDR- und SIEM-Systeme sollten um entsprechende Erkennungsregeln erweitert werden.
4. Monitoring und Einschränkung von Ethereum-RPC-Traffic
Da EtherRAT öffentlich zugängliche Ethereum-RPC-Provider für C2-Zwecke nutzt, sollten Zugriffe auf diese Endpunkte von Applikationsservern aus überwacht und, wo möglich, eingeschränkt werden. Ungewöhnlicher ausgehender RPC-Traffic ist ein wertvoller Indikator für laufende Kompromittierungen.
Unternehmen, die jetzt in ein eng verzahntes Zusammenspiel von sicherer Softwareentwicklung, konsequentem Vulnerability-Management und kontinuierlichem Monitoring investieren, reduzieren das Risiko nachhaltig, Opfer vergleichbarer, zunehmend hybrider Angriffe zu werden. Die Kombination aus Zero‑Day-nahen Schwachstellen, legitimen Entwicklerwerkzeugen und Blockchain-basierter C2-Infrastruktur zeigt, dass moderne Angriffe längst über klassische Muster hinausgehen – und dass nur ein ganzheitlicher Sicherheitsansatz ausreichend Schutz bieten kann.
