Shai-Hulud Infostealer durchsucht 469 Anmeldedaten-Stellen

Eine kürzlich entdeckte Variante des Shai-Hulud-Infostealer-Wurms hat die Anzahl der Stellen, an denen sie nach Anmeldedaten sucht, von 189 auf 469 erhöht, so eine Forschung von GitGuardian, die Anfang August veröffentlicht wurde. Die neue Zielliste umfasst Entwickler-Workstations, Systeme für kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD), Cloud-Konfigurationen und sogar Konfigurationsdateien, die von KI-Entwicklungstools verwendet werden. Ein Infostealer ist eine Schadsoftware, die darauf ausgelegt ist, Passwörter, Zugriffstokens und andere Anmeldedaten von einem infizierten Rechner zu sammeln, und Anmeldedaten sind die Passwörter oder Tokens, die Programme und Personen verwenden, um ihre Identität nachzuweisen. Diese Änderung ist wichtig, weil Angreifer nicht mehr versuchen, Vertrauensbarrieren zu durchbrechen. Sie sammeln die vorhandenen Anmeldedaten, die bereits dafür sorgen, dass vertrauenswürdige Softwaresysteme funktionieren.

Software-Lieferketten haben schon immer auf Vertrauen basiert. Entwickler vertrauen Paketregistern wie npm oder Docker Hub. Organisationen vertrauen Projektbetreuern. CI/CD-Systeme vertrauen den Anmeldedaten und Identitäten, die ihnen gegeben werden, und Anwendungen vertrauen den Abhängigkeiten, die sie während eines Builds herunterladen. Angreifer haben erkannt, dass sie dieses Vertrauen nicht brechen müssen. Sie müssen nur herausfinden, wo Anmeldedaten und dauerhafte Berechtigungen bereits vorhanden sind. Deshalb ist das Sammeln von Anmeldedaten zum Kernelement für den Erfolg von Infostealer-Würmern geworden. Shai-Hulud gehört zu einer wachsenden Klasse von Lieferkettenangriffen, die eine bereits kompromittierte Umgebung nach Anmeldedaten durchsuchen, die dem Angriff helfen können, fortzufahren.

Der Weg von einem gestohlenen Anmeldedatum zum nächsten ist direkt. Ein Token, das auf einer Entwickler-Workstation gefunden wird, könnte Zugriff auf Quellcode ermöglichen, und dieser Quellcode könnte Cloud-Anmeldedaten enthalten, die dann Zugriff auf die Infrastruktur gewähren können. Ein GitHub-Zugriffstoken, eine Textzeichenfolge, die einem Programm oder einer Person Zugriff auf ein GitHub-Konto ermöglicht, könnte Schreibzugriff auf weitere Repositorys ermöglichen, während eine Paketveröffentlichungs-Anmeldedaten einem Angreifer erlauben könnten, Software über einen Kanal zu veröffentlichen, dem Entwickler bereits vertrauen. Anmeldedaten werden zum verbindenden Gewebe zwischen einer kompromittierten Umgebung und der nächsten. Moderne Entwicklerrechner enthalten weit mehr Authentifizierungsmaterial als nur das Quellcode-Repository. Anmeldedaten erscheinen an erwarteten Orten wie .env-Dateien, Shell-Verlauf und Paketmanager-Konfiguration, verstecken sich aber auch in Caches von Befehlszeilenschnittstellen, CI/CD-Konfigurationsdateien, Einstellungen integrierter Entwicklungsumgebungen und zunehmend in der Konfiguration, die von KI-Codierungsassistenten verwendet wird. Der Angreifer weiß nicht immer, welche Anmeldedaten vor der Sammlung am wichtigsten sind, also sammelt er, was verfügbar ist, und sortiert später, was jede einzelne freischaltet.

Verteidiger sollten das Problem in die entgegengesetzte Richtung angehen, so die GitGuardian-Analyse. Sicherheitsteams müssen identifizieren, welche Anmeldedaten am wichtigsten sind, und deren Gefährdung beheben, bevor ein Angreifer sie nutzen kann. Paketveröffentlichungs-Anmeldedaten verdienen besondere Aufmerksamkeit, weil sie Anmeldedatendiebstahl in Softwareverteilung verwandeln. Tokens, die Entwickler zum Veröffentlichen von Paketen verwenden, tragen Autorität über ein vertrauenswürdiges Paket, das andere Entwickler, Build-Systeme und Organisationen automatisch konsumieren. Dieses Vertrauen missbrauchen Angreifer. Organisationen sollten die Anzahl dauerhafter Veröffentlichungs-Anmeldedaten reduzieren, die gestohlen werden können, und auf kurzlebige, verifizierte Authentifizierung über OpenID Connect (OIDC) umsteigen, einen Standard, der es einem Dienst ermöglicht, die Identität zu verifizieren, ohne ein langlebiges Passwort weiterzugeben, oder ähnlich begrenzte Mechanismen. Docker und GitHub Actions haben das Ökosystem kürzlich in diese Richtung gedrängt, mit stärkerer Authentifizierung und stärkerer Nutzung von vertrauenswürdiger Veröffentlichung. Jede verbleibende langlebige Veröffentlichungs-Anmeldedaten sollte als hochsensible Infrastruktur behandelt werden.

Anmeldedaten verbinden auch Systeme, die Sicherheitsteams oft getrennt verwalten. Sicherheitsteams denken traditionell in Begriffen von Quellcode-Verwaltungssicherheit, CI/CD-Sicherheit, Cloud-Sicherheit, Endpunktsicherheit und Anwendungssicherheit. Aber ein einzelner Entwickler kann sich an einem normalen Tag bei GitHub, npm, AWS, Kubernetes (ein System, das containerisierte Anwendungen über viele Maschinen hinweg ausführt), internen APIs und Build-Infrastruktur authentifizieren, und CI/CD-Pipelines tragen oft eine ebenso vielfältige Reihe von Anmeldedaten. Eine Anmeldedaten, die in einer Entwicklerumgebung zurückgelassen wird, kann Autorität an einem völlig anderen Ort darstellen. Die Datei könnte auf einem Laptop liegen, während die Anmeldedaten eine Cloud-Ressource kontrollieren oder Paketveröffentlichungsrechte gewähren. Wo ein Geheimnis entdeckt wird, erzählt nur einen Teil der Geschichte. Organisationen, die Reife im Geheimnisverwaltung anstreben, müssen auch wissen, ob die Anmeldedaten gültig sind, zu welcher Identität sie gehören, welches System sie akzeptiert, welche Berechtigungen sie trägt, welche Umgebung sie erreicht und wer für ihre Behebung verantwortlich ist. Das verwandelt Geheimniserkennung in Anmeldedaten-Risikomanagement.

Nicht jedes exponierte Geheimnis birgt das gleiche Risiko. Eine Liste mit 100.000 Geheimnisbefunden repräsentiert nicht 100.000 gleich dringende Vorfälle. Einige Anmeldedaten sind bereits ungültig, andere erreichen Wegwerf-Entwicklungsumgebungen, und eine kleinere Anzahl bietet Zugriff auf Produktionsdatenbanken, Cloud-Infrastruktur, Bereitstellungssysteme oder Paketveröffentlichung. Diese Befunde identisch zu behandeln, erzeugt Warteschlangen, anstatt Risiken zu reduzieren. Die erste Priorität sollte sein, Paketveröffentlichungsschlüssel aus Klartext zu entfernen. Entwickler und Pipeline-Automatisierung schreiben Authentifizierungsschlüssel oft als Teil normaler Arbeitsabläufe in lokale Konfigurationsdateien, aber ein Geheimnis muss nicht in Git übertragen worden sein, um für Malware auf dem Entwicklerrechner verfügbar zu sein. Das ist einer der Gründe, warum jüngste Lieferkettenangriffe zunehmend die Arbeitsumgebung des Entwicklers selbst ins Visier nehmen. Die am schwersten zu stehlende Veröffentlichungs-Anmeldedaten für einen Angreifer ist eine, die nicht existiert. Wenn sie existieren muss, desto besser, je kürzer das Zeitfenster ist, in dem Zugriff gewährt werden kann. Das Ziel ist, wiederverwendbare Veröffentlichungsautorität in Klartext zu eliminieren und die Paketveröffentlichung auf kurzlebige, identitätsbasierte Mechanismen umzustellen, wo unterstützt. OIDC-basierte vertrauenswürdige Veröffentlichung ist ein Beispiel. Die meisten Cloud-Plattformen bewegen sich in Richtung föderierter Sicherheits-Token-Dienste wie AWS STS, die Arbeitslastverifizierung über Plattformen hinweg ermöglichen, wo Artefakte gepusht werden.

Nach den Veröffentlichungs-Anmeldedaten sollten sich Organisationen auf Anmeldedaten konzentrieren, die Zugriff auf kritische Produktionssysteme bieten. Eine exponierte Anmeldedaten, die mit einer isolierten Entwicklungsumgebung verbunden ist, könnte begrenzten Schaden anrichten, während eine gültige Anmeldedaten mit Schreibzugriff auf Produktionsinfrastruktur ein völlig anderer Vorfall ist. Eine nützliche kurze Liste umfasst Produktions-Cloud-Konten, Datenbanken mit Kundeninformationen, Signierungsinfrastruktur, Kubernetes-Cluster, Bereitstellungswerkzeuge und administrative Schnittstellen. Die Schlüsselfrage ist, was passiert, wenn ein Angreifer etwas Böswilliges mit gestohlenem Zugriff tut. Gültigkeit ist ein nützlicher Filter, und die Bestimmung des tatsächlichen Schadensradius hilft bei der Priorisierung, welche Systeme angegangen werden müssen, um langlebige Geheimnisse zu eliminieren oder zumindest zu rotieren. Geteilte Anmeldedaten schaffen versteckte Pfade zwischen Umgebungen. Eine in Staging entdeckte Anmeldedaten könnte sich immer noch gegen Produktion authentifizieren. Ein Token, das in die lokale Umgebung eines Entwicklers kopiert wurde, könnte Berechtigungen behalten, die für Automatisierung gedacht waren, und dieselbe Anmeldedaten könnte über mehrere Systeme hinweg auftauchen, lange nachdem ihr ursprünglicher Zweck vergessen wurde. Das Geheimnis zu finden ist nur der erste Schritt; Alarme sind nur Rauschen, wenn sie es nicht auf die Identität, Berechtigungen, Ressourcen, Umgebungen und Eigentümer dahinter zurückführen.

Sobald Paketveröffentlichungs-Anmeldedaten und offensichtlicher Produktionszugriff behandelt sind, können Organisationen systematisch durch das verbleibende Anmeldedaten-Inventar arbeiten. Das Ziel ist nicht, alles zufällig zu rotieren, sondern einen Aktionsplan zu erstellen, der kontinuierlich die nützlichsten Anmeldedaten aus dem Pfad des Angreifers entfernt. Gültigkeit ist ein guter Ausgangspunkt. Eine gültige Anmeldedaten verdient sofortige Aufmerksamkeit mehr als eine, die bereits abgelaufen oder widerrufen ist, und in großem Maßstab macht der Unterschied enorm aus. GitGuardians Forschung zum Stand der Geheimnisverbreitung fand 28,65 Millionen neue hartcodierte Geheimnisse, die 2025 allein in öffentlichen GitHub-Commits hinzugefügt wurden, ein Anstieg von 34 Prozent im Jahresvergleich. Mengen in dieser Größenordnung machen manuelle Priorisierung unrealistisch. Teams müssen feststellen, welche Befunde noch nutzbare Authentifizierung darstellen, und diese an die Spitze der Warteschlange bringen. Gültigkeit allein erzählt jedoch nicht die ganze Geschichte. Eine gültige Anmeldedaten für einen gemeinsamen Entwicklungsdienst verdient Aufmerksamkeit, aber eine gültige Anmeldedaten mit Administratorzugriff auf ein Produktions-Cloud-Konto verdient erheblich mehr. Die Priorisierung sollte Kontext hinzufügen: ob die Anmeldedaten noch gültig ist, ob sie Produktion, Staging oder Entwicklung erreicht, welche Identität sie repräsentiert, welche Berechtigungen diese Identität hat, auf welche Ressourcen sie zugreifen kann, wo sonst die Anmeldedaten verwendet wird und wer sie besitzt und rotieren oder widerrufen kann. Antworten, die überprüfbar sind, verwandeln eine überwältigende Liste durchgesickerter Geheimnisse in einen tatsächlichen Sanierungsplan.

Die neueste Welle von Shai-Hulud-Angriffen sollte zu mehr führen als zu einer einmaligen Anmeldedatenbereinigung. Anmeldedaten werden weiterhin akkumulieren, während Entwickler Software bauen, Dienste integrieren, Pipelines sich weiterentwickeln und neue Werkzeuge in die Umgebung kommen. Die Reaktion muss zu einem wiederholbaren Zyklus werden. Organisationen brauchen zuerst breite Sichtbarkeit in alle Anmeldedaten, einschließlich Quellcode und Git-Verlauf, aber moderne Angriffe sprechen dafür, weiter in CI/CD-Systeme und Entwicklerumgebungen zu schauen, wo Authentifizierungsmaterial sich ansammelt. Erkennung sollte beantworten, wo wiederverwendbare Autorität derzeit existiert, und sie sollte überprüfbar sein, anstatt nur die bekannten Geheimnisse widerzuspiegeln, die bereits in einem Tresor gespeichert sind. Der Prozentsatz von Geheimnissen, die außerhalb des Tresors existieren, ist eine wichtige Metrik bei der Adressierung von Geheimnissicherheit in großem Maßstab, weil Sanierungspläne, die verwaiste Klartext-Geheimnisse nicht berücksichtigen, zum Scheitern verurteilt sind. Prävention muss verhindern, dass sich dieselbe Anmeldedaten-Schicht wieder aufbaut, indem neue hartcodierte Geheimnisse blockiert werden, Arbeitsabläufe wo möglich auf kurzlebige Anmeldedaten umgestellt werden, Anmeldedaten in Entwicklerumgebungen geschützt werden und neue Exposition erfasst wird, bevor sie zu einem weiteren großen Projekt wird. Erkennung, Sanierung und Prävention müssen als fortlaufender Zyklus behandelt werden, nicht als Notfallreaktion nach einem Angriff. Für Website-Betreiber und kleinere Teams ohne Vollzeit-Sicherheitsfunktion kann eine sicherheitsorientierte IT- und Infrastrukturprüfung wie die von AEU-I angebotene helfen, dieses Anmeldedaten-Inventar und eine Basislinie geringster Rechte aufzubauen. Die nächste Shai-Hulud-Variante wird mit ziemlicher Sicherheit irgendwo Neues suchen und über die 469 bereits identifizierten Stellen hinausgehen. Angreifer werden weiterhin Pfade und Entwicklerwerkzeuge hinzufügen, weil moderne Softwareumgebungen voller wiederverwendbarer Autorität sind. Verteidiger werden nicht gewinnen, indem sie sich jeden Ort merken, an dem der nächste Infostealer suchen könnte. Sie gewinnen, indem sie dauerhafte Berechtigungen entfernen und exponierte Anmeldedaten überall eliminieren, wo sie existieren, sodass es jedes Mal, wenn ein neuer Wurm kommt, weniger auffindbare Schlüssel gibt, die missbraucht werden können.