Nx-Paket zur Cloud-Verwaltungskontrolle in 72 Stunden

Im August 2025 zeigte eine Lücke in der Software-Versorgungskette wieder, dass die schwächste Verbindung im Workflow des Entwicklers sein kann. Eine engagierte Version des in npm veröffentlichten nx-Pakets beinhaltete ein schädliches Post-Installations-Skript, das endete die Eingangstür für einen Angriff, der in die Cloud kletterte, um in weniger als drei Tagen vollständige administrative Kontrolle zu werden.

Der anfängliche Mechanismus war in seinem Konzept nicht ausgefeilt: die Ausbeutung eines GitHub-Aktionen-Workflows basierend auf_ Anfrage _ Ziel, eine Art Angriff, den die Gemeinschaft als Pwn Anfrage. Forschung über diese Art von Missbrauch und wie es Repositorien und Workflows betrifft, können in technischen Analysen wie Praetorian, Endor Labs und SonarSource. Diese Art von Fluss ermöglicht es einem Schauspieler mit Zugang zu einer Extraktionsanfrage, hohe Privilegien zu erhalten und Geheimnisse zu zeichnen, die dann wieder verwendet werden, um empfindlichere Umgebungen zu kompromittieren.

In diesem Fall umfasste das Gewindepaket einen Anmelde-Dieb im benannten JavaScript QUIETVAULT, dessen Erkennung in Malware-Analysequellen wie VirusTotal. Der Code suchte Umweltvariablen, Systemmetadaten und wertvolle Token - einschließlich GitHubs persönliche Tokens (PAT) - und hochgeladen die gesammelten Informationen an ein öffentliches Repository. Der Ausführungsvektor war paradoxerweise ein Update, das von einer Entwicklungserweiterung (Nx Console) abgefeuert wurde, als ein Mitarbeiter seinen Editor öffnete und das Post-Installation erlaubte, auf seiner Maschine zu laufen.

Mit den Token in der Hand, die Gruppe identifiziert von Google als UNC6426 initiierte Aufklärung Manöver innerhalb der GitHub-Umgebung des Opfers und verwendet ein legitimes Geheimentnahme-Tool namens Nord Stream um zusätzliche Anmeldeinformationen zu finden, einschließlich der eines GitHub-Service-Kontos. Von dort aus nutzte der Angreifer die Vertrauensbeziehung zwischen GitHub Actions und Amazon Web Services (die OIDC-Integration), um temporäre AWS STS-Token zu fordern und auf Rollen zuzugreifen, die Infrastruktur bereitstellen können.

Das zentrale Problem in der Cloud war die Zulässigkeit einer Rolle im Zusammenhang mit GitHub-Aktionen, die CloudFormation-Operationen mit den Kräften ermöglichten, Identitäten zu schaffen und Politiken einzuschließen. Mit diesem Fenster setzten die Angreifer einen Stapel ein, dessen einziges Ziel darin bestand, eine neue Identität mit der Politik der Administratorzugriff angehängt. Laut der Analyse veröffentlicht von Google in seiner Cloud Threat Horizon Bericht H1 2026, diese Kanalisierung erlaubt, von einem gestohlenen Token in volle administrative Genehmigungen in AWS in weniger als 72 Stunden zu bewegen.

Mit absoluter administrativer Kontrolle taten die Angreifer, was jeder schädliche Bediener auf dieser Ebene konnte: sie listeten und exfiltrierte S3-Buckets Objekte, fertige Produktionsinstanzen in EC2 und RDS und entschlüsseln Anwendungsschlüssel, die andere Vermögenswerte geschützt. In einer abschließenden Phase der operativen Demütigung fielen Veränderungen im Entwicklungsökosystem zusammen: Sie umbenannten interne Repositorien und machten sie öffentlich, ließen Beweise für Engagement und die Ausweitung des namhaften und operativen Schadens.

Für diesen Vorfall ist eine zusätzliche Schicht relevant: das Eingreifen von künstlichen Geheimagenten als operationelles Werkzeug. Der Dieb QUETVAULT nutzte neben dem Sammeln von Geheimnissen einen LLM-Assistenten, der in Endpunkten anwesend ist, um Anmeldeinformationen und Daten mit Anweisungen in der natürlichen Sprache zu lokalisieren, was eine neue Art von Supply-Chain-Missbrauch beweist, wo die Ausführung von schädlichen Handlungen als Aufforderungen und nicht als verschlüsselte Callbacks ausgedrückt wird. Spezialisierte Signaturen, wie Sockel, haben gewarnt, wie die Teilnehmer in den Fluss des Entwicklers integriert erweitern den Angriffsumfang und komplizierte traditionelle Erkennung.

Die technischen Empfehlungen, die aus der Forschung hervorgehen, um sowohl in der Entwicklungsphase als auch in der Verwaltung von Identitäten und Zugriffen in der Cloud zu messen. Es ist wichtig, Skripte nach der Installation zu begrenzen oder Pakete in isolierten Umgebungen auszuführen, streng die Prinzip des kleinen Privilegs in Konten und Rollen, die mit CI / CD interagieren, und vermeiden dauerhafte Privilegien für Aufgaben, die sie nicht benötigen, wie die Schaffung von administrativen Rollen. Es ist auch angebracht, mehr körnige und kurzlebige PATs zu verwenden, ungewöhnliche Muster in der AMI-Aktivität zu überwachen und die Überwachung zu verstärken, um Anzeichen von IA-Agenten zu erkennen, die auf Entwicklungssysteme wirken.

Neben den konkreten Maßnahmen zeigt der Fall eine strukturelle Lektion: Moderne Lieferketten sind ein Multiplikatorvektor. Ein beliebtes Paket mit einem schädlichen Update kann eine lokale Explosion in eine groß angelegte Intrusion verwandeln, wenn die Vertrauensverhältnisse zwischen Werkzeugen (Herausgeber, Erweiterungen, Registrierungen, Pipelines und Wolken) nicht richtig gebunden sind. Organisationen müssen nicht nur die Cloud-Sicherheitspolitik neu denken, sondern wie Entwicklungswerkzeuge in verteilte Umgebungen integriert und vertraut sind.

Für diejenigen, die die technischen Details und Minderungen vertiefen wollen, bieten die oben genannten Berichte und Analysen Leitlinien und zusätzlichen Kontext: Googles Bericht über die oben genannten Cloud-Bedrohungen, die technischen Essays über Pwn Request von Praetorian und SonarSource und arbeiten an der Umsetzung von KI-Agenten und Risiken in Erweiterungen durch die Sockel. Die Überwachung von beiden Fronten - Cloud-Identity-Versorgung und -Steuerkette - ist jetzt eine operative und Governance-Priorität für jede Organisation, die von Drittanbieter-Software und automatisierten Pipelines abhängt.