Sicherheitsforscher von GitGuardian haben festgestellt, dass eine neue Variante des Infostealer-Wurms Shai-Hulud 469 unterschiedliche Speicherorte nach Zugangsdaten durchsucht.
Nach Einschätzung der Analyse versuchen Angreifer immer seltener, grundlegende Vertrauensbeziehungen in der Software-Lieferkette selbst zu brechen, etwa zwischen Entwicklern und Paketverzeichnissen oder zwischen Organisationen und Projektbetreuern. Stattdessen suchen sie gezielt nach bereits vorhandenen Zugangsdaten und Berechtigungen, die diese Vertrauensbeziehungen ohnehin tragen. Ein auf einem Entwicklerrechner gefundenes Zugriffstoken kann dabei Zugang zu Quellcode eröffnen, der wiederum Cloud-Zugangsdaten enthält, die weiteren Zugriff auf Infrastruktur ermöglichen, während ein GitHub-Token Schreibzugriff auf zusätzliche Repositories gewähren kann. Zugangsdaten fungieren so als Verbindungsglied von einer kompromittierten Umgebung zur nächsten.
Solche Zugangsdaten finden sich dabei längst nicht mehr nur in Quellcode-Repositorys, sondern auch in Konfigurationsdateien, der Shell-Historie, CLI-Zwischenspeichern, CI/CD-Konfigurationen sowie Entwicklungsumgebungs-Einstellungen, zunehmend auch in Konfigurationen von KI-Entwicklungswerkzeugen. Besondere Aufmerksamkeit verdienen dabei Zugangsdaten zur Veröffentlichung von Paketen, da deren Diebstahl Angreifern erlaubt, Schadsoftware über einen von anderen Entwicklern bereits als vertrauenswürdig eingestuften Kanal zu verbreiten, wodurch sich ein einzelner Diebstahl zu einer eigenständigen Verbreitungskette weiterentwickelt.
Shai-Hulud-Wurm: Drei Prioritäten für Unternehmen zur Risikominderung
Als wichtigste Sofortmaßnahme empfiehlt die Analyse, Zugangsdaten zur Paketveröffentlichung konsequent aus Klartext-Konfigurationen zu entfernen und wo immer möglich durch kurzlebige, identitätsgebundene Mechanismen wie OpenID Connect zu ersetzen, wie es etwa Docker und GitHub Actions zuletzt bereits stärker unterstützen. Zweite Priorität ist die Beseitigung offengelegter Zugangsdaten zu tatsächlich produktiven Systemen wie Cloud-Konten, Kundendatenbanken, Signatur-Infrastruktur, Kubernetes-Clustern sowie Verwaltungsoberflächen, da ein gültiges Zugangstoken mit Produktivzugriff ein deutlich schwerwiegenderes Risiko darstellt als eines für eine isolierte Testumgebung. Als dritten Schritt empfiehlt die Analyse, sämtliche verbleibenden offengelegten Zugangsdaten nach tatsächlichem Risiko zu priorisieren, etwa danach, ob sie noch gültig sind, welche Umgebung sie erreichen und welche Rechte die zugehörige Identität besitzt.
Als Beleg für die schiere Größenordnung des Problems verweist die eigene GitGuardian-Untersuchung zur Verbreitung offengelegter Zugangsdaten darauf, dass allein im Jahr 2025 rund 28,65 Millionen neue, fest im Code eingebettete Geheimnisse in öffentlichen GitHub-Commits hinzukamen, ein Anstieg von 34 Prozent gegenüber dem Vorjahr. Bei einer derartigen Menge sei eine rein manuelle Sichtung nicht mehr praktikabel, weshalb Unternehmen systematisch bewerten müssten, welche der gefundenen Zugangsdaten tatsächlich noch nutzbar sind.
Ein wiederkehrender Prozess statt einmaliger Aufräumaktion
Die Analyse betont abschließend, die Reaktion auf derartige Wurm-Varianten dürfe sich nicht auf eine einmalige Bereinigungsaktion beschränken, da mit fortschreitender Softwareentwicklung, neuen Werkzeugen und wachsender Systemintegration kontinuierlich neue Zugangsdaten entstehen. Notwendig sei stattdessen ein wiederkehrender Kreislauf aus vollständiger Bestandsaufnahme sämtlicher vorhandener Zugangsdaten, risikobasierter Priorisierung der Behebung sowie Maßnahmen, die verhindern, dass sich dieselbe Angriffsfläche durch neu eingebettete, dauerhaft gültige Zugangsdaten erneut aufbaut. Ziel müsse sein, dass jede künftige Wurm-Variante bei ihrer Suche zunehmend weniger tatsächlich nutzbare Zugangsdaten vorfindet.
(red)