In der JavaScript-Welt sind Abhängigkeiten oft harmlos – bis ein Build-Prozess plötzlich zur Lieferstrecke für Schadcode wird. Aktuell haben Sicherheitsforscher mehrere trojanisierte npm-Pakete identifiziert, die sich als Kalender- und Streak-Utilities ausgeben. Tatsächlich sind sie so präpariert, dass sie heimlich eine Linux-Implantat-Version namens RedC2 4.0 nachladen und starten.
Besonders kritisch: Die Ausführung erfolgt bereits beim Laden eines Moduls. Ein spezieller Install-Hook ist dafür nicht nötig. Damit sinkt die Hürde für Angreifer weiter, auch in komplexen Abhängigkeitsbäumen unbemerkt zu werden.
Warum die Pakete wie echte Tools funktionieren
Die betroffenen Pakete wirken auf den ersten Blick plausibel. Sie bieten die versprochenen Funktionen rund um Datum, Streaks und zugehörige Berechnungen. Genau diese „Nützlichkeit“ macht den Angriff tückisch: Wer einen Kalender-Helper einbindet, bekommt erwartungsgemäß Ergebnisse – und übergibt gleichzeitig ungewollt den Schadcode.
Unter der Oberfläche steckt jedoch ein weiterer Mechanismus: Der Code setzt eine eingebettete Datei als ausführbar und startet sie als separaten Hintergrundprozess. So entsteht der Eindruck eines normalen Libraries-Verhaltens, während im Hintergrund ein Implantat aktiv wird.
Welche npm-Pakete betroffen sind
Im Bericht werden mehrere Pakete mit ähnlichem Muster aufgeführt. Dazu zählen unter anderem folgende Versionen (jeweils @1.0.0, @1.0.1 oder wie angegeben):
- streak-metrics-math
- kit-map-vim
- streak-map-cache
- streak-map-kit
- map-streak-kit
- streak-cache-map
- streak-calc-metrics
- streak-calc-math
- streak-math-abz
- streak-metricsaz
- streak-math-metrics
- streak-metricazbd
- streak-metricsazb
- streak-kit-map
Die Dateinamen der eigentlichen Payload unterscheiden sich je nach Paket. Typische Varianten, die in den Paketen auftauchen, sind unter anderem: math-core.bin, math-calc.bin, calc-math.dat, calc-cache.bin, calc.bin und calc-mapping.bin.
So startet die RedC2-Backdoor: Laden genügt
Ein zentraler Punkt der Entdeckung: Die Schadfunktion hängt nicht an einer klassischen Install-Phase. Laut den Forschern wird die Payload gestartet, sobald das Modul geladen wird. Es ist ausreichend, wenn irgendwo in der Abhängigkeitskette ein Import stattfindet – selbst dann, wenn das betroffene Paket nur transitive Abhängigkeit ist.
Verantwortlich dafür ist das Einstiegselement in den Paketen. Genannt wird insbesondere dist/index.mjs als trojanischer Loader. Dieses Modul exportiert die Datumshelfer nach außen, startet aber gleichzeitig das eingebettete Implantat beim Laden des Moduls.
Auch der Speicherort der Payload ist paketabhängig. Sie liegt entweder direkt unter dist/ oder innerhalb von dist/internal/. Inhaltlich ist die Funktion jedoch gleich: Sie enthält eine Linux-Beacon-Komponente für RedC2 4.0.
RedC2 4.0: Funktionen über typische Backdoor-Features hinaus
RedC2 4.0 wird auf einschlägigen Plattformen als plattformübergreifendes Werkzeug vermarktet, das insbesondere auf Windows, macOS und Linux ausgerichtet ist. Für die Linux-Variante existiert damit eine Beacon-Komponente, die nach erfolgreicher Bereitstellung mit einem entfernten Server kommuniziert.
Die Beschreibung aus dem Bericht macht deutlich, wie breit die Steuerbarkeit ausfällt. Neben grundlegenden Kommando- und Kontrollaufgaben werden Funktionen genannt wie:
- Interaktives Arbeiten über eine Shell (u. a. /bin/sh)
- Dateioperationen und Systemerkundung
- Datensammlung, inklusive sensibler Inhalte wie SSH-Schlüssel und Browser-Anmeldeinformationen
- Persistenzmechanismen
- In-Memory-Ausführung von Payloads (u. a. für ELF-Dateien)
- SOCKS5-Proxying und Netzwerk-Pivoting
- Empfang und Ausführung eingehender Aufgaben in einer Command-Processing-Schleife
Nach der Bereitstellung läuft zunächst ein „Check-in“-Ablauf: Die Beacon sammelt Basissysteminformationen, sendet sie an den C2-Server und registriert die infizierte Maschine. Danach verarbeitet sie fortlaufend Befehle, führt sie über die Shell aus und übermittelt Ergebnisse zurück.
Warum das für Unternehmen besonders gefährlich ist
Das Angriffsmuster ist weniger „zerstörerisch“ als vielmehr skalierbar. Wer Pakete aus dem npm-Ökosystem in Build- oder Laufzeitprozessen verwendet, kann ohne Warnung eine Backdoor starten, sobald ein Import erfolgt. Gerade in modernen Projekten mit vielen Abhängigkeiten und automatisierten Pipelines ist das Risiko hoch, dass eine betroffene Library unbemerkt in den Produktivbetrieb gelangt.
Hinzu kommt: Die Pakete sind nicht leer oder offensichtlich kaputt. Sie erfüllen ihre scheinbar legitimen Aufgaben. Damit sinkt die Wahrscheinlichkeit, dass Entwickler die Abhängigkeit sofort als schädlich erkennen.
AI-gestützte Bedienoberfläche: Red Agent und natürliche Sprache
Ein weiterer Aspekt des Falls ist die Vermarktungs- und Funktionslogik rund um RedC2 als C2-Framework. Der Bericht beschreibt, dass es Erweiterungen gibt, darunter ein komponentenbasiertes Element namens Red Agent. Dieser Teil soll laut den Angaben auf einem großen Sprachmodell (LLM) beruhen und Operatoren ermöglichen, komplexe Post-Exploitation-Schritte über natürliche Sprache in konkrete Befehle zu übersetzen.
Damit wird die Bedienung potenziell für Nutzer mit unterschiedlichem Skill-Level zugänglicher: Statt alle Befehle manuell zu formulieren, sollen Prompts in ausführbare Befehlssequenzen überführt werden. Für die Angreifer kann das die Effektivität erhöhen, weil weniger Einarbeitung nötig ist, um mehrstufige Intrusionen zu steuern.
Vergleich in der Supply Chain: ähnliche Muster tauchen parallel auf
Die Entdeckung fällt in eine Zeit, in der Supply-Chain-Angriffe auch in anderen Ökosystemen Thema sind. Der Bericht verweist auf einen zuvor beobachteten koordinierten Angriff auf mehrere legitime Rust-Crates, bei dem eine bösartige proc-macro-Abhängigkeit automatisch beim Cargo-Build ausgeführt wurde. Wie bei den npm-Fällen geht es dabei um die Idee, dass ein scheinbar normales Build-Verhalten zur Ausführung von Malware führt.
Solche parallelen Muster zeigen: Es reicht nicht, nur den eigentlichen Produktionscode zu prüfen. Ebenso wichtig ist die Integrität der Abhängigkeiten, der Paketquellen und der Build-Pipeline.
Was jetzt hilft: konkrete Abwehrmaßnahmen
Auch wenn der genaue Umfang für jedes Projekt unterschiedlich ist, lassen sich aus dem Angriff mehrere sinnvolle Schritte ableiten:
- Abhängigkeiten prüfen: Kontrollieren Sie, ob betroffene Pakete oder ähnliche Namensvarianten in directen oder transitiven Abhängigkeiten vorkommen.
- Lockfiles und Build-Artefakte absichern: Nutzen Sie nachvollziehbare Abhängigkeitsstände (z. B. Lockfiles) und vermeiden Sie unkontrollierte Updates.
- Code-Review für npm-Integrationen: Achten Sie besonders auf Libraries, die beim Laden von Modulen mehr tun als „nur“ Utility-Funktionen.
- Monitoring für Ausführungen: Red flags sind aus Sicht der Verteidigung das Setzen ausführbarer Rechte und das Starten separater Hintergrundprozesse, die nicht zum Projekt passen.
- Threat-Intel nutzen: Ergänzen Sie interne Regeln um IoCs aus aktuellen Reports und führen Sie schnelle Scans auf Workstations und Servern durch.
Wenn Sie in einer Umgebung arbeiten, in der automatisierte Builds häufig im Hintergrund laufen, lohnt sich zusätzlich ein zeitnaher Abgleich: Welche Pakete wurden wann installiert, und auf welchem System? So lassen sich verdächtige Zeitfenster besser eingrenzen.
Fazit
Die gemeldeten trojanisierten npm-Pakete zeigen erneut, wie effektiv getarnter Schadcode in gängigen Entwickler-Ökosystemen sein kann. Obwohl die Libraries wie funktionierende Kalender- und Streak-Utilities wirken, ist beim Laden ein Mechanismus aktiv, der eine Linux-Backdoor im Stil von RedC2 4.0 startet. Für Organisationen bedeutet das: Abhängigkeiten sind nicht nur „Komponenten“, sondern potenzielle Eintrittspunkte.
Wer Supply-Chain-Risiken ernst nimmt, kombiniert technische Kontrollen, Abhängigkeits-Hygiene und Monitoring. Dann sinkt die Chance, dass ein einzelnes unauffälliges Paket die komplette Sicherheitslage aushebelt.
Quelle: https://thehackernews.com/2026/08/14-trojanized-npm-packages-drop-redc2.html
