Nach Angaben von Open Source Malware spielte sich der Angriff am 5. Juni ab. In einer automatisierten Bereinigung wurden 73 Microsoft-Repositories auf GitHub deaktiviert, überwiegend in der Azure-Organisation des Unternehmens. Die Folgen reichten über Microsoft hinaus: Organisationen, die betroffene GitHub Actions einsetzten, verzeichneten unterbrochene CI/CD-Pipelines. Open Source Malware hob insbesondere Azure/functions-action hervor. Weil diese Action nicht einfach wie eine Bibliothek fest versioniert werden könne, sondern direkt innerhalb anderer Pipelines laufe, brachen Workflows weltweit weg, sobald GitHub sie zusammen mit functions-container-action deaktivierte.
StepSecurity veröffentlichte am selben Tag eine Analyse, die die Beobachtungen bestätigte und den Vorfall mit Miasma verknüpfte. Diese Variante des Mini-Shai-Hulud-Wurms war laut dem Unternehmen bereits in diesem Monat bei Angriffen auf Red-Hat-npm-Pakete aufgefallen. Darüber hinaus zog StepSecurity eine Verbindung zu einer früheren Kompromittierung eines Microsoft-Pakets auf PyPI. Dort waren am 19. Mai drei manipulierte Versionen des offiziellen durabletask-Python-SDKs von Microsoft veröffentlicht worden. Das Paket wird laut Bericht normalerweise 400.000 Mal pro Monat heruntergeladen und blieb etwa 35 Minuten online, bevor Microsoft es entfernte.
Ashish Kurmi, Mitgründer und Technikchef von StepSecurity, bezeichnete diese manipulierten Versionen damals als „besonders gefährlich“. Sie enthielten demnach ein modulares Cloud-Einbruchs-Framework namens rope.pyz, das Geheimnisse und Zugangsdaten stiehlt und in manchen Regionen auch einen destruktiven Wiper ausrollen kann. Kurmi schrieb weiter, die Angreifer hätten die echten Veröffentlichungszugangsdaten für ein offizielles Microsoft-Paket kompromittiert und die Build-Pipeline des Repositories vollständig umgangen. Microsoft habe die Kompromittierung inzwischen bestätigt und die betroffenen Versionen zurückgezogen.
Schon damals ordnete StepSecurity den PyPI-Vorfall TeamPCP zu und verwies auf überlappende Infrastruktur mit früheren Mini-Shai-Hulud-Angriffen. Im jüngsten Bericht bringt der Anbieter nun auch die kompromittierten Microsoft-Repositories mit der umfassenderen Supply-Chain-Kampagne dieser Gruppe in Verbindung. Ein bösartiger Commit sei von demselben Beitragskonto gekommen, das bereits bei der PyPI-Kompromittierung genutzt worden sei.
Für die wiederholte missbräuchliche Nutzung dieses Kontos nannte Kurmi mehrere mögliche Erklärungen: Die Zugangsdaten könnten nach dem Vorfall vom 19. Mai nicht vollständig rotiert oder widerrufen worden sein. Ebenso sei denkbar, dass das Konto durch die Verbreitungsschleife des Miasma-Wurms ein zweites Mal kompromittiert wurde. Als dritte Möglichkeit nannte er, dass ein Token eines anderen Beitragskontos genutzt und die Metadaten des Commit-Autors über die Git Data API gefälscht wurden. Gegenüber Dark Reading erklärte Kurmi, am wahrscheinlichsten sei eine Kombination aus unvollständiger Rotation nach dem Vorfall vom 19. Mai und einer erneuten Kompromittierung durch die eigene Ausbreitungslogik des Wurms.
Microsoft beantwortete Fragen zu dem Beitragskonto nicht direkt, übermittelte Dark Reading aber eine Stellungnahme. Darin heißt es, man habe einige Repositories während der Untersuchung potenziell schädlicher Inhalte vorübergehend entfernt; nach Prüfung seien alle wiederhergestellt worden. Außerdem habe das Unternehmen eine kleine Zahl von Kunden benachrichtigt, die möglicherweise Inhalte aus den betroffenen Repositories heruntergeladen hatten.
Technisch unterschied sich diese Angriffswelle laut StepSecurity von früheren Miasma- und Shai-Hulud-Kampagnen. Während diese auf Entwickler-Geheimnisse und Cloud-Zugangsdaten zielten, habe die in den Microsoft-Repositories entdeckte Malware speziell Zugangsdaten aus KI-Coding-Werkzeugen abgegriffen. Genannt werden Anthropic Claude Code, Google Gemini CLI, Cursor und Visual Studio Code. Statt ein Paket-Register zu manipulieren, legten die Angreifer Konfigurationsdateien in Repositories ab. Öffnet ein Entwickler ein kompromittiertes Repository in einem solchen Werkzeug oder in einer IDE, wird der Schadcode automatisch ausgeführt.
Kurmi zufolge war dieser Wechsel bewusst gewählt, um Erkennungssysteme zu umgehen. Der Download eines kompromittierten Repositories löse keine Warnung aus, weil das Repository als vertrauenswürdig gelte; aktiv werde die Malware erst beim Öffnen über KI-Entwicklungswerkzeuge, wo viele Scanner noch nicht hinsähen. StepSecurity zufolge änderten die Angreifer keinen Quellcode, sondern hinterlegten Konfigurationsdateien für Claude Code, Gemini CLI, Cursor und VS Code, die alle auf eine 4,6 Megabyte große Nutzlast verwiesen.
GitHubs automatisierte Schutzmechanismen markierten und entfernten die kompromittierten Repositories zwar innerhalb weniger Stunden. StepSecurity hält dieses Zeitfenster dennoch für erheblich. Bei einem sich selbst verbreitenden Wurm sei genau das entscheidend: Wer ein betroffenes Repository heruntergeladen und in einer der anfälligen Umgebungen geöffnet habe, dessen Zugangsdaten seien sofort abgegriffen worden; diese gestohlenen Token dienten dann dazu, den nächsten Commit zu pushen und das nächste Paket neu zu veröffentlichen. Wie viele Entwicklerkonten in diesem Zeitraum kompromittiert wurden, sei unklar.
StepSecurity riet Organisationen, die nach dem 2. Juni eines der betroffenen Repositories geklont und mit den genannten KI-Coding-Tools geöffnet haben, davon auszugehen, dass ihre Systeme kompromittiert wurden. Empfohlen werden die Rotation aller Zugangsdaten, eine Prüfung von npm- und PyPI-Paketen sowie die Auswertung von Protokollen auf Kompromittierungsindikatoren. Um ähnliche Vorfälle zu verhindern, empfiehlt der Anbieter außerdem, geklonte Repositories auf verdächtige Konfigurationsdateien von KI-Agenten und anderen Drittwerkzeugen zu untersuchen, Branch-Schutzregeln mit verpflichtender Prüfung aller Commits zu aktivieren und ausgehende Netzwerkzugriffe von CI/CD-Runnern auf Kommando-und-Kontroll-Domänen zu beschränken.