Den Analysen von Aikido und Socket zufolge startet das manipulierte „preinstall"-Skript einen Loader namens setup.mjs. Dieser lädt die JavaScript-Laufzeitumgebung Bun von GitHub herunter und nutzt sie, um eine stark verschleierte Schaddatei namens execution.js auszuführen.

Bei dieser Nutzlast handelt es sich um einen Information-Stealer, der vielfältige Zugangsdaten sowohl von Entwicklerrechnern als auch aus CI/CD-Umgebungen abgreift. Darüber hinaus versucht die Schadsoftware, Geheimnisse direkt aus dem Speicher des CI-Runners auszulesen – vergleichbar mit dem Vorgehen von TeamPCP bei früheren Lieferketten-Angriffen.

„Auf CI-Runnern führt die Nutzlast ein eingebettetes Python-Skript aus, das /proc//maps und /proc//mem des Prozesses Runner.Worker ausliest, um jedes Geheimnis nach dem Muster ‚key’:{‚value’:‚…’,‚isSecret’:true} direkt aus dem Runner-Speicher zu extrahieren und damit jegliche Log-Maskierung der CI-Plattform zu umgehen", erklärt Socket. Dieser Speicher-Scanner sei strukturell identisch mit jenem, der bei den Vorfällen rund um Bitwarden und Checkmarx dokumentiert wurde.

Die gesammelten Daten werden verschlüsselt und in öffentliche GitHub-Repositories unter dem Konto des Opfers hochgeladen. Diese Repositories tragen die Beschreibung „A Mini Shai-Hulud has Appeared", was an die Zeichenkette „Shai-Hulud: The Third Coming" aus dem Bitwarden-Angriff erinnert.

Zusätzlich nutzt die Malware die Commit-Suche auf GitHub als sogenanntes Dead-Drop, um Token abzurufen und sich weiteren Zugriff zu verschaffen. „Die Schadsoftware durchsucht GitHub-Commits nach dieser Zeichenkette und verwendet passende Commit-Nachrichten als Token-Dead-Drop", erläutert Aikido. Commit-Nachrichten nach dem Muster OhNoWhatsGoingOnWithGitHub: würden zu GitHub-Token dekodiert und auf Repository-Zugriff geprüft.

Wie bei früheren Angriffen enthält die Nutzlast zudem Code zur Selbstverbreitung: Mithilfe gestohlener npm- oder GitHub-Zugangsdaten versucht sie, weitere Pakete und Repositories zu verändern, auf die sie Zugriff erlangt, und schleust dort denselben Schadcode ein.

Die Forscher ordnen den Angriff mit mittlerer Sicherheit den TeamPCP-Akteuren zu, die ähnlichen Code und ähnliche Taktiken bereits bei Lieferketten-Angriffen gegen Trivy, Checkmarx und Bitwarden verwendet haben.

Unklar bleibt, wie die Angreifer SAPs npm-Veröffentlichungsprozess kompromittieren konnten. Security Engineer Adnan Khan berichtet, dass ein npm-Token möglicherweise über einen fehlkonfigurierten CircleCI-Job offengelegt wurde. BleepingComputer bat SAP um eine Stellungnahme zum Hergang der Kompromittierung, erhielt bis zur Veröffentlichung jedoch keine Antwort.