Ein typischer Schutzreflex in JavaScript-Projekten lautet: Installationsskripte abschalten, Abhängigkeiten pinnen, Scanner laufen lassen. Der aktuelle RedC2-Fall zeigt, warum das allein nicht mehr reicht. TrendAI Research hat eine Gruppe trojanisierter npm-Pakete analysiert, die wie harmlose Kalender- und Streak-Hilfsbibliotheken aussehen. Sie liefern tatsächlich funktionierende Datumslogik. Gleichzeitig starten sie beim Laden des Moduls einen Linux-Implant. The Hacker News berichtete am Wochenende darüber und ordnete den Befund als Lieferkettenangriff mit KI-gestütztem Command-and-Control ein.
Der praktische Punkt für Unternehmen ist nicht nur „noch ein böses npm-Paket“. Auffällig ist die Kombination aus drei Eigenschaften: Die Pakete funktionieren fachlich, der Schadcode hängt nicht an einem klassischen preinstall- oder postinstall-Hook, und das ausgelieferte RedC2-Framework enthält mit „Red Agent“ eine LLM-Schicht, die natürliche Sprache in Post-Exploitation-Befehle übersetzen soll. Damit verschiebt sich die Kontrolle von der Paketinstallation in die Laufzeit eines beliebigen Imports.
Was technisch passiert
Laut TrendAI wurden 14 Paketnamen beziehungsweise Versionen beobachtet, darunter [email protected]/1.0.1, [email protected], [email protected] und weitere ähnlich benannte „streak“- und „map“-Pakete. Die npm-Registry zeigt für geprüfte Beispiele inzwischen nur noch 0.0.1-security als aktuelle Version; frühere Versionen waren im Juli und August 2026 veröffentlicht worden. Das spricht dafür, dass die Pakete nach der Entdeckung entschärft oder übernommen wurden. Für forensische Prüfungen ist das trotzdem relevant, weil kompromittierte Build-Container, Entwicklerrechner oder CI-Caches ältere Artefakte lokal behalten können.
Die Tarnung ist vergleichsweise sauber. Im Paket liegt echte Datumslogik, etwa Funktionen zum Gruppieren von Werten nach Tagen oder zum Berechnen von Streaks. Daneben befindet sich eine Linux-ELF-Datei, im Quelltext als nativer „Math Accelerator“ gerahmt. Die Dateinamen variieren: math-core.bin, math-calc.bin, calc-math.dat, calc-cache.bin, calc.bin oder calc-mapping.bin. Inhaltlich handelt es sich nach TrendAI um denselben RedShell-Linux-Implant für RedC2 4.0.
Entscheidend ist der Loader in dist/index.mjs. Er re-exportiert die legitimen Hilfsfunktionen, führt aber beim Modulladen zusätzlich eine Initialisierungsroutine aus. Diese Routine prüft, ob die Binärdatei vorhanden ist, setzt sie mit chmod auf ausführbar, verifiziert einen SHA-256-Hash und startet sie dann per cp.spawn als abgekoppelten Hintergrundprozess. Es muss keine exportierte Funktion aufgerufen werden. Ein einzelner import reicht, auch wenn er nur indirekt über eine transitive Abhängigkeit erfolgt.
Damit fällt ein wichtiger Standardhebel aus: --ignore-scripts hilft gegen Lebenszyklus-Skripte, aber nicht gegen Code, der regulär beim Modulimport läuft. Genau diese Grenze ist für moderne Build- und Agentenumgebungen relevant. KI-Coding-Agenten, Testläufe, Preview-Server und Automatisierungsjobs importieren Pakete häufig, um Typen, Tests, Generatoren oder kleine Hilfsfunktionen auszuführen. In dem Moment kann der Loader bereits aktiv werden.
Warum RedC2 die Lage verschärft
RedC2 wird nach den Berichten als plattformübergreifendes C2-Framework für Windows, macOS und Linux vermarktet. Die Linux-Komponente RedShell kommuniziert mit einem C2-Server, registriert das System mit Basisinformationen und verarbeitet anschließend Befehle. TrendAI beschreibt Funktionen wie interaktive Shell über /bin/sh, System- und Netzwerkerkundung, Dateioperationen, Sammlung von SSH-Schlüsseln und Browser-Zugangsdaten, Persistenz, SOCKS5-Proxying, Port-Forwarding und In-Memory-Ausführung von ELF-Dateien oder Shellcode.
Die KI-Komponente macht daraus kein magisches autonomes Superwerkzeug. Sie verändert aber die Bedienoberfläche. „Red Agent“ soll natürliche Sprache in geordnete Framework-Befehle übersetzen. Ein Operator muss also nicht jeden Schritt manuell beherrschen, sondern kann Ziele wie Reconnaissance oder Credential Dumping formulieren. TrendAI formuliert es als Abstraktion, die die Einstiegshürde für mehrstufige Intrusionen senken kann. Diese Einordnung ist plausibel, sollte aber nüchtern bleiben: Die Quellen belegen ein beworbenes und analysiertes Werkzeug; sie belegen nicht automatisch massenhafte erfolgreiche Kompromittierungen in Unternehmen.
Einordnung für Unternehmen
Für AIFence ist der Fall deshalb stark, weil er zwei bisher getrennte Risikoklassen zusammenführt: Software-Supply-Chain und agentisch unterstützte Offensive-Tools. Viele Organisationen behandeln npm-Malware noch als Registry-Problem: Paket blockieren, Lockfile aktualisieren, Scanner-Regel hinzufügen. Das greift zu kurz, wenn der eigentliche Schaden in der Laufzeit eines Imports entsteht und der betroffene Host ein CI-Runner, ein Entwickler-Laptop oder eine Agenten-Sandbox mit Zugriff auf Repositories, Cloud-Umgebungen, Paket-Tokens oder Modell-API-Keys ist.
Konkrete Konsequenzen:
- Paketprüfungen müssen nicht nur
scriptsinpackage.json, sondern auch Einstiegspunkte wiemain,module,exportsund gebündelte native Artefakte bewerten. - CI- und Agenten-Sandboxes sollten ausgehende Netzwerkverbindungen, Prozessstarts und ausführbare Dateien aus
node_modulesrestriktiv behandeln. npm auditund klassische SCA-Tools bleiben wichtig, reichen aber bei neu veröffentlichten oder kaum verbreiteten Paketen nicht als alleinige Kontrolle.- Build-Runner sollten kurzlebig sein; persistente Workspaces, Paket-Caches und wiederverwendete Entwicklercontainer erhöhen die forensische Komplexität.
- Secrets für npm, GitHub, Cloud, Datenbanken, MCP-Server und Modellanbieter gehören mit minimalem Scope und kurzer Laufzeit in die Umgebung, nicht dauerhaft auf Entwicklerhosts.
Risiken und Grenzen der Bewertung
Die Quellenlage ist für die technische Analyse gut: TrendAI liefert die Primäranalyse, Paketnamen, Loader-Verhalten und RedShell-Details; The Hacker News bestätigt und verdichtet die Befunde unabhängig journalistisch. Öffentlich sichtbare npm-Metadaten bestätigen zudem, dass betroffene Paketnamen inzwischen auf 0.0.1-security stehen. Nicht belegt ist hingegen, wie viele echte Opfer es gab. Downloadzahlen oder Registry-Sichtbarkeit wären ohne saubere Quelle kein belastbarer Kompromittierungsnachweis. Ebenso sollte man die KI-Schicht nicht überhöhen: Ein LLM im C2-Framework automatisiert Bedienung, ersetzt aber nicht Netzwerkzugang, Rechteausweitung oder operative Fehlerfreiheit.
Fazit
RedC2 über npm ist ein Warnsignal für die nächste Stufe der Entwickler- und Agenten-Sicherheit. Der gefährliche Pfad beginnt nicht erst beim Installationsskript, sondern beim Import. Er endet nicht bei einem einfachen Beacon, sondern kann in ein C2-Framework mit natürlicher Sprachsteuerung führen. Unternehmen sollten deshalb ihre Supply-Chain-Kontrollen stärker an tatsächlichem Laufzeitverhalten ausrichten: native Binärartefakte in Paketen, Prozessstarts aus Abhängigkeiten, Netzwerk-Egress aus Builds und Agentensessions sowie Secret-Zugriffe gehören zusammen überwacht. Wer KI-Coding-Agenten produktiv einsetzt, sollte deren Arbeitsumgebung wie einen privilegierten Build-Host behandeln – kurzlebig, netzwerkarm, nachvollziehbar und ohne unnötige Geheimnisse.
Quellen: TrendAI Research, „Prompting the Payload: How an npm Supply Chain Attack Delivers the RedC2 AI-Powered Linux Implant“ (20.08.2026); The Hacker News, „14 Trojanized npm Packages Drop RedC2 4.0 Linux Backdoor With AI-Assisted C2“ (22.08.2026); öffentliche npm-Registry-Metadaten der genannten Paketnamen.
