Im Zentrum des Angriffs steht ein sogenannter Imposter-Commit. Dabei handelt es sich um eine Täuschungstechnik in der Software-Lieferkette: Schadcode wird über einen Commit oder Tag eingeschleust, der ausschließlich in einem vom Angreifer kontrollierten Fork existiert – nicht im ursprünglichen, vertrauenswürdigen Repository. Auf diese Weise lassen sich die üblichen Prüfungen von Pull Requests umgehen und beliebiger Code zur Ausführung bringen.

Laut StepSecurity wurde bei der Action actions-cool/issues-helper jeder vorhandene Tag auf einen solchen Imposter-Commit verschoben, der nicht in der normalen Commit-Historie auftaucht. Wird dieser Commit innerhalb eines GitHub-Actions-Runners ausgeführt, läuft eine Reihe von Aktionen ab, die Zugangsdaten aus CI/CD-Pipelines abgreifen und an einen externen Server ausleiten.

Dieselbe Funktionalität fand sich nach Angaben des Unternehmens auch in 15 Tags einer zweiten Komponente, actions-cool/maintain-one-comment. GitHub hat den Zugang zum betroffenen Repository inzwischen gesperrt und begründet dies mit einem Verstoß gegen die Nutzungsbedingungen. Was genau die Microsoft-Tochter zu diesem Schritt veranlasste, ist bislang nicht bekannt.

Bemerkenswert ist eine mögliche Verbindung zu einer anderen Angriffswelle: Die zur Datenausleitung genutzte Domain t.m-kosche[.]com tauchte auch in der jüngsten Welle der sogenannten Mini-Shai-Hulud-Kampagne auf, die npm-Pakete aus dem @antv-Ökosystem ins Visier nahm. Das legt nahe, dass beide Aktivitätsstränge zusammenhängen könnten.

Philipp Burckhardt, Leiter der Threat Intelligence bei Socket, bestätigte gegenüber The Hacker News diese Einschätzung. Der Angriff auf die @antv-npm-Pakete sei wahrscheinlich mit dem actions-cool-Vorfall verknüpft, da sich die Ausleitungs-Domain überschneide. „Das deutet auf denselben Mini-Shai-Hulud-Aktivitätscluster hin, nicht auf einen separaten, rein auf npm beschränkten Vorfall", so Burckhardt. Beim genauen Weg des ersten Zugriffs sei man noch vorsichtig, doch die Überschneidung sei stark genug, um beide Vorfälle als zusammenhängend zu behandeln.

Für betroffene Anwender ergibt sich daraus eine klare technische Konsequenz: Da inzwischen jeder Tag auf bösartige Commits verweist, zieht jeder Workflow, der die Action über eine Versionsangabe einbindet, beim nächsten Lauf den Schadcode nach. Geschützt sind allein jene Workflows, die auf einen bekannten, korrekten vollständigen Commit-SHA festgelegt sind.