Wiz und Socket schreiben die Angriffe TeamPCP zu — auf Basis technischer Überschneidungen und betrieblicher Ähnlichkeiten mit früheren Kampagnen der Gruppe. In den vergangenen Monaten hatte TeamPCP bereits Pakete mehrerer Open-Source-Projekte kompromittiert, darunter Trivy, ein von Aqua Security gepflegter Sicherheitsscanner, sowie KICS, ein von Checkmarx entwickeltes Werkzeug zur statischen Codeanalyse.
Die Wahl von SAP-Paketen verleiht den TeamPCP-Angriffen laut Fachleuten eine neue Dimension und erhöht das Risiko für Unternehmen. Das Forschungsteam von Socket verweist auf die „beträchtliche Reichweite im SAP-Entwickler-Ökosystem" mit Hunderttausenden Downloads pro Woche. Wie bei früheren Angriffen sammelten die Schadroutinen Zugangsdaten für GitHub, npm, Kubernetes, CI/CD und Cloud-Dienste, die dann genutzt werden, um weitere Repositories und Pakete zu übernehmen und sogar nachgelagerte Kundenorganisationen zu kompromittieren.
Betroffen sind die Pakete @cap-js/sqlite (v2.2.2), @cap-js/postgres (v2.2.2), @cap-js/db-service (v2.10.1) und mbt (v1.2.48). Die CAP-Pakete hängen mit SAP-Cloud-Bereitstellungsabläufen zusammen, das MBT-Paket dient dem Erstellen einsatzfertiger Multi-Target-Application-Archive (MTA). Die vergifteten Pakete wurden kurz nach ihrer Veröffentlichung wieder entfernt. SAP reagierte auf eine Anfrage von Dark Reading bis Redaktionsschluss nicht.
Die Beschränkung auf wenige hochwertige Unternehmenspakete hebt die Kampagne von früheren Supply-Chain-Angriffen ab. „Statt sich über viele zufällige Pakete zu verteilen, traf dieser Angriff SAP, wo eine erfolgreiche Installation auf Entwicklerrechnern oder in CI-Jobs mit Zugriff auf GitHub-, npm-, Cloud- und Deployment-Geheimnisse laufen kann", sagt Raphael Silva von Aikido Security gegenüber Dark Reading. „Die Zahl der Pakete ist klein, aber der potenzielle Wert jeder kompromittierten Umgebung kann sehr hoch sein. Vermutlich sehen wir die volle Tragweite dieser Kampagne erst noch."
Die Zuordnung zu TeamPCP stützt sich auf überlappende Vorgehensweisen: Die zweite Stufe der Schadroutine bricht vor der Datenausleitung ab, wenn das System auf die russische Sprache eingestellt ist; zudem kommt ein gemeinsam genutzter öffentlicher RSA-Schlüssel zum Verschlüsseln der erbeuteten Daten zum Einsatz. Der Bezug auf die Shai-hulud-Wurmangriffe bleibt nach Einschätzung von Wiz jedoch bloße Anspielung: Eine eindeutige Verbindung lasse sich nicht herstellen. Silva nennt einen auffälligen Unterschied — frühere Shai-Hulud-Wellen legten erbeutete Geheimnisse offen, während diese Kampagne die gestohlenen Daten verschlüsselte.
Wie sich die Angreifer Zugang zu den SAP-Paketen verschafften, ist nicht abschließend geklärt. Der Sicherheitsingenieur Adnan Khan vermutet in einem Beitrag auf X einen npm-Token, der durch eine Fehlkonfiguration in CircleCI im Repository SAP/cloud-mta-build-tool gegenüber Pull-Request-Builds offengelegt war. Silva bestätigt, dass diese Theorie zu den technischen Befunden seines Teams passt, hält den offengelegte Token aber nicht für die alleinige Ursache: „Diese Angriffe sind meist vielschichtiger." Socket berichtet zudem, dass mit denselben Werkzeugen und Methoden auch das PyPI-Paket lightning und Intercoms npm-Paket getroffen wurden.
Silva fordert Organisationen auf, Lockfiles, Paket-Caches, CI-Logs, interne Registries, Artefaktspeicher und Entwicklersysteme auf Spuren der vergifteten SAP-Pakete zu durchsuchen. Wurde ein betroffenes Paket installiert, sollten Geheimnisse erneuert werden — und zwar nicht nur npm-Token, da die Schadroutine GitHub, npm, Cloud-Anbieter, Kubernetes, CI-Geheimnisse und lokale Entwicklerwerkzeuge ins Visier nimmt.