Kompromittierte SAP npm-Pakete zum Abfangen von Entwickler- und CI/CD-Geheimnissen

Technik und Auswirkungen

Die gestohlenen Daten werden verschlüsselt und über öffentliche GitHub-Repositories exfiltriert, wobei das gleiche Exfiltrationsmuster verfolgt wird wie bei der ursprünglichen Shai-Hulud-Kampagne.

Die Malware enthält auch eine Propagationslogik: Mithilfe aller gestohlenen npm-Tokens identifiziert sie andere Pakete unter dem Konto des kompromittierten Maintainers, injiziert bösartigen Code und veröffentlicht diese neu, wodurch eine exponentielle, automatisierte Verbreitung im gesamten npm-Ökosystem ohne Eingreifen des Akteurs ermöglicht wird.

Bei der Initialisierung führt die Malware eine gezielte Geofencing-Überprüfung durch – sie inspiziert die Datum-/Uhrzeit-Lokaleinstellungen des Systems und die Umgebungsvariablen der Sprache auf Werte, die mit „ru“ beginnen.

Sicherheitslage und Risiko

Ist das System für die russische Sprache konfiguriert, terminiert die Malware sofort selbst und stellt sicher, dass keine Daten aus russischsprachigen Umgebungen exfiltriert werden. Dieser bewusste Ausschluss ist ein wiederkehrendes Merkmal bei TeamPCP-Kampagnen.

Forscher schreiben diese Kampagne TeamPCP mit hoher Sicherheit zu und weisen auf mehrere überlappende technische Signaturen mit zuvor dokumentierten TeamPCP-Operationen hin, die Pakete wie Trivy, LiteLLM und Checkmarx KICS ins Visier nahmen.

Zu den Schlüsselattributionsindikatoren gehören:

Der gleiche __decodeScrambled-Chiffre, der zur Verschlüsselung

Der gleiche __decodeScrambled-Chiffre, der zur Verschlüsselung in Exfiltrations-Repositories verwendet wurde

Identische russischsprachige Early-Exit-Logik

Ein gemeinsamer Dropper (setup.mjs — SHA256: 4066781fa830224c8bbcc3aa005a396657f9c8f9016f9a64ad44a9d7f5f45e34), der in allen vier Paketen vorhanden ist

Konsistente Muster der Infrasttrukturmissbrauch: Ausführung bei

Konsistente Muster der Infrasttrukturmissbrauch: Ausführung bei der Installation, Exfiltration außerhalb des Hosts und selbstverbreitung durch Canister.

Betroffene Pakete und IOCs Paket Version Tarball SHA256 @cap-js/postgres 2.2.2 1d9e4ece8e13c8eaf94cb858470d1bd8f81bb58f62583552303774fa1579edee @cap-js/db-service 2.10.1 258257560fe2f1c2cc3924eae40718c829085b52ae3436b4e46d2565f6996271 @cap-js/sqlite 2.2.2 a1da198bb4e883d077a0e13351bf2c3acdea10497152292e873d79d4f7420211 mbt 1.2.48 86282ebcd3bebf50f087f2c6b00c62caa667cdcb53558033d85acd39e3d88b41 Der gemeinsame Dropper setup.mjs (SHA1: 307d0fa7407d40e67d14e9d5a4c61ac5b4f20431) ist in allen vier Paketen vorhanden.

Die execution.js-Payload für @cap-js/postgres und @cap-js/db-service ist identisch (SHA256: eb6eb4154b03ec73218727dc643d26f4e14dfda2438112926bb5daf37ae8bcdb ).

Technik und Auswirkungen

Organisationen, die SAP CAP Tooling verwenden, sollten umgehend die Abhängigkeiten der CI/CD-Pipeline überprüfen, alle in betroffenen Umgebungen vorhandenen Geheimnisse rotieren und die oben aufgeführten spezifischen kompromittierten Versionen blockieren.

Verteidiger sollten auch unerwartete Bun-Runtime-Downloads während npm-Installationsvorgängen überwachen, da dieses Verhalten ein neuartiger Indikator ist, der spezifisch für diese Kampagne ist. Eine verantwortungsvolle Offenlegung wurde bei den Maintainern aller betroffenen Pakete vorgenommen.

Der Beitrag SAP npm Packages Compromised to Harvest Developer and CI/CD Secrets erschien zuerst bei