Red Hat npm-Pakete getroffen: Über 30 Repos liefern Cloud-Credential-Stealer
Eine koordinierte Angriffskampagne auf die npm-Lieferkette zum Diebstahl von Cloud-Zugangsdaten hat einen der bekanntesten Namen in der Unternehmenssoftware getroffen. Unbekannte Angreifer kompromittierten mehr als 30 npm-Pakete der Red Hat Cloud Services, indem sie zunächst das GitHub-Konto eines Red-Hat-Mitarbeiters übernahmen und diesen Zugang dann nutzten, um schädliche Commits einzuschleusen. Die in diesen Paketen enthaltene Malware, die als Variante des „Mini Shai-Hulud“-Stamms identifiziert wurde, wird automatisch bei der Installation ausgeführt und beginnt sofort mit dem Exfiltrieren von Cloud-Zugangsdaten, darunter AWS-, GCP- und Azure-Zugriffsschlüssel sowie SSH-Schlüssel und Kubernetes-Konfigurationsdateien.
Dieser Vorfall sticht nicht wegen einer Schwäche in npm selbst hervor, sondern wegen des Weges, auf dem die Angreifer eindrangen: über eine legitime, vertrauenswürdige Entwickleridentität.
Wie die Red Hat npm-Pakete kompromittiert wurden
Die Angriffskette begann mit der Kompromittierung eines einzelnen GitHub-Kontos, das einem Red-Hat-Mitarbeiter gehörte. Sobald die Angreifer in diesem Konto waren, hatten sie den nötigen Zugriff, um Code direkt in die Repositories zu pushen, die mit den npm-Paketen von Red Hat Cloud Services verknüpft sind. Da die Commits von einem anerkannten Mitwirkendenkonto stammten, war die Hürde für automatisierte Pipelines und Peer-Reviewer, etwas Verdächtiges zu erkennen, deutlich höher.
Das ist das charakteristische Merkmal eines Software-Lieferkettenangriffs: Die schädliche Nutzlast reist innerhalb legitimer Software, die signiert und über vertrauenswürdige Kanäle verteilt wird. Entwickler, die während des Kompromittierungsfensters eines der betroffenen Pakete installierten oder aktualisierten, führten die Malware unwissentlich auf ihren eigenen Systemen aus – ohne offensichtliche Warnung. Die Pakete selbst funktionierten weiterhin normal, was die Erkennung zusätzlich erschwerte.
Die Malware-Variante „Mini Shai-Hulud“ ist gezielt darauf ausgelegt, zum Installationszeitpunkt ausgeführt zu werden – in dem Moment, in dem ein Entwickler npm install eingibt. Sie wartet weder darauf, dass die Anwendung gestartet wird, noch auf eine Benutzerinteraktion. Dieser Ansatz verkürzt die Zeitspanne zwischen Infektion und Datenabfluss drastisch.
Welche Zugangsdaten gestohlen wurden und warum sie wichtig sind
Die Zielliste der Malware liest sich wie eine Checkliste der schädlichsten Dinge, die ein Angreifer von der Workstation eines Entwicklers oder einem CI/CD-Pipeline-Runner extrahieren könnte. AWS-, Google Cloud Platform- und Azure-Zugangsdateien sind Hauptziele, da diese Schlüssel oft weitreichende Berechtigungen für die gesamte Produktionsinfrastruktur mit sich bringen. Private SSH-Schlüssel und Kubernetes-Konfigurationsdateien vervollständigen die Beute und eröffnen Angreifern potenzielle Querbewegungspfade in interne Netzwerke und Container-Orchestrierungscluster.
Für Organisationen, die automatisierte Build-Pipelines betreiben, ist das Expositionsrisiko noch größer. CI/CD-Systeme speichern häufig langlebige Cloud-Zugangsdaten als Umgebungsvariablen oder eingehängte Secrets. Ein einzelner infizierter Build-Runner könnte unbemerkt Schlüssel ausliefern, die ganze Cloud-Umgebungen kontrollieren – und damit Tür und Tor für Datenabfluss, Ransomware-Implementierung oder persistente Hintertür-Zugänge öffnen.
Das ist auch der Grund, warum Sicherheitsteams bedenken sollten, dass Einstiegspunkte in der Lieferkette oft zu einer tiefergehenden Systemkompromittierung führen. Die jüngste Warnung der CISA zu CVE-2026-31431, einer Linux-Schwachstelle zur lokalen Rechteausweitung, ist eine direkte Mahnung: Angreifer, die mit gestohlenen Zugangsdaten oder einem ersten Zugriff auf ein System landen, bleiben selten dort stehen. Sie suchen nach dem nächsten Glied in der Kette.
Warum Lieferkettenangriffe ein blinder Fleck für die Standard-Sicherheit sind
Herkömmliche Sicherheitswerkzeuge basieren auf der Annahme, dass externer, unsignierter oder unbekannter Code die Bedrohung darstellt. Firewalls, Endpoint-Detection-Agenten und signaturbasierte Scanner sind darauf kalibriert, Anomalien zu erkennen. Lieferkettenangriffe hebeln dieses Modell aus, indem sie sich in Software verstecken, die eine gültige Signatur trägt und über einen erwarteten Kanal hereinkommt.
In diesem Fall hätten die Marke Red Hat und die zugehörige GitHub-Kontohistorie den kompromittierten Paketen ein hohes Maß an implizitem Vertrauen verliehen. Entwickler, die an Red-Hat-naher Infrastruktur arbeiten, könnten diese Pakete genau deshalb installiert haben, weil sie erwarteten, dass sie gut gepflegt und sicher sind.
Standard-Tools zur Abhängigkeitsanalyse, die nach bekannten verwundbaren Versionen suchen, würden Installationszeit-Zugangsdatendiebe nicht erkennen, es sei denn, die schädliche Version wäre bereits in einer Schwachstellendatenbank gekennzeichnet. Der Angriff nutzt die Lücke zwischen der Erkennung von „bekannt bösartig“ und der Verhaltensanalyse aus.
Mehrschichtige Verteidigung: Secrets-Management, Netzwerksegmentierung und VPNs
Keine einzelne Kontrollmaßnahme stoppt einen ausgefeilten Lieferkettenangriff, aber mehrschichtige Verteidigung kann den Explosionsradius erheblich verringern.
Secrets-Management statt lokaler Zugangsdateien. Die wirksamste Gegenmaßnahme besteht darin, statische Zugangsdateien von Entwickler-Rechnern und CI/CD-Runnern vollständig zu entfernen. Tools, die kurzlebige Just-in-Time-Zugangsdaten ausgeben, bedeuten, dass selbst gestohlene Anmeldedaten ablaufen, bevor ein Angreifer sie sinnvoll nutzen kann.
Abhängigkeits-Pinning und Integritätsprüfung. Pakete auf bestimmte, verifizierte Commit-Hashes festzulegen, anstatt variablen Versionsbereichen zu folgen, begrenzt die Gefahr durch unerwartete Codeänderungen. In Kombination mit automatisierten Integritätsprüfungen des Paketinhalts entsteht eine weitere Erkennungsebene.
Netzwerksegmentierung und Egress-Filterung. Die Mini Shai-Hulud-Malware muss die gestohlenen Daten irgendwohin senden. Die Beschränkung ausgehender Verbindungen von Build-Umgebungen und Entwickler-Maschinen auf bekannte Endpunkte kann den Datenabfluss selbst dann verhindern, wenn die Malware erfolgreich ausgeführt wird. VPNs und Zero-Trust-Netzwerkarchitekturen können diese Egress-Richtlinien einheitlich über verteilte Teams hinweg durchsetzen.
Multi-Faktor-Authentifizierung auf jedem Entwicklerkonto. Der ursprüngliche Zugang war hier eine GitHub-Kontoübernahme. Strenge MFA-Anforderungen, insbesondere Hardware-Sicherheitsschlüssel oder passkeybasierte Authentifizierung, machen die Kontoübernahme wesentlich schwieriger.
Verhaltensüberwachung in CI/CD-Pipelines. Das Alarmieren bei unerwarteten ausgehenden DNS-Abfragen oder Netzwerkverbindungen während der Build-Phase kann Installationszeit-Malware an die Oberfläche bringen, bevor gestohlene Zugangsdaten genutzt werden.
Was das für Sie bedeutet
Falls Ihre Entwicklungs- oder Betriebsumgebung von npm-Paketen der Red Hat Cloud Services abhängt, besteht die unmittelbare Priorität darin, zu prüfen, welche Paketversionen verwendet werden, in den Netzwerkprotokollen rund um Installationsereignisse nach Kompromittierungsindikatoren zu suchen und alle Cloud-Zugangsdaten zu rotieren, die auf betroffenen Systemen vorhanden gewesen sein könnten.
Allgemeiner betrachtet ist dieser Vorfall ein Anstoß, Ihre gesamte Cloud-Zugangsdaten-Hygiene auf den Prüfstand zu stellen. Werden Zugangsdaten als Dateien auf Entwickler-Maschinen gespeichert? Sind CI/CD-Umgebungsvariablen nach dem Prinzip der geringsten Rechte festgelegt? Ist MFA auf jedem Konto mit Paketveröffentlichungsrechten durchgesetzt?
Lieferkettenangriffe sind erfolgreich, weil sie Vertrauen ausnutzen. Die Gegenmaßnahme besteht darin, Systeme aufzubauen, die sich nicht allein auf implizites Vertrauen stützen – verifizierte Identitäten, zeitlich begrenzte Secrets und Verhaltensüberwachung sind die Grundlage. Beginnen Sie noch heute mit einem Credential-Audit und behandeln Sie jede Abhängigkeit als potenzielle Angriffsfläche, die eine genaue Prüfung verdient.
