Gestohlene Azure-App-Identitäten ermöglichten JadePuffer, Cloud-Zugriff in Zerstörung zu verwandeln

Microsoft macht JadePuffer für zerstörerische Aktivitäten in Azure-Mandanten verantwortlich. Das Unternehmen führt den Akteur unter dem Namen Storm-3168. Bei einem detailliert untersuchten Vorfall kontrollierte der Angreifer zwei Dienstprinzipale. Damit spürte er Ressourcen auf, beschaffte Zugangsdaten, löschte Cloud-Dienste und versuchte, Schutzmaßnahmen zur Wiederherstellung auszuhebeln.

Microsoft veröffentlichte seinen Bericht am 25. September 2026. Darin beschreibt das Unternehmen Aktivitäten von Anfang Juni. Separaten Berichten zufolge beobachtete Microsoft zwei Angriffe im Juni; der ausführliche Bericht dokumentiert jedoch hauptsächlich einen Angriff.

Der Vorfall richtete erheblichen Schaden an, ohne dass eine öffentlich bekannte Software-Schwachstelle ausgenutzt wurde. Stattdessen agierte JadePuffer mit kompromittierten Anwendungsidentitäten, deren Berechtigungen Aktionen ermöglichten, die wie reguläre Cloud-Administration aussehen konnten.

Zwei Dienstprinzipale teilten sich die Arbeit beim Angriff

Azure-Dienstprinzipale sind Anwendungsidentitäten, mit denen sich Software und automatisierte Prozesse authentifizieren und auf Ressourcen zugreifen können. Ihnen lassen sich Berechtigungen über die rollenbasierte Zugriffssteuerung (RBAC) von Azure zuweisen, ohne dass ein interaktives Benutzerkonto erforderlich ist.

JadePuffer kompromittierte zwei solcher Identitäten innerhalb desselben Mandanten. Eine davon nutzte der Angreifer vor allem, um die Umgebung über einen Zeitraum von rund 15,5 Stunden zu erfassen. Dabei führte er mehr als 300 erfolgreiche Lesezugriffe auf virtuelle Maschinen, Abonnements, Ressourcengruppen und weitere Azure-Ressourcen aus.

Die zweite Identität ging deutlich schneller vor. Etwa 90 Minuten nach Beginn der umfassenderen Aufklärung erfasste sie virtuelle Maschinen und Ressourcengruppen in zwei Abonnements – und das innerhalb von nur fünf Sekunden.

Diese Aufgabenteilung deutet auf einen strukturierten Ablauf hin: Eine Identität erstellte eine umfassende Bestandsaufnahme, während die andere gezielt Informationen sammelte und zerstörerische Aktionen ausführte. Die verfügbaren Belege zeigen allerdings nicht, ob diese Aufteilung durch KI, herkömmliche Automatisierung oder direkte Anweisungen eines Angreifers gesteuert wurde.

Die Microsoft-Forscher Yossi Weizman und Tushar Mudi erklärten, dass eine derart umfassende Erkundung einem Angreifer Einblick in die Azure-Umgebung eines Opfers verschaffen kann. Dabei ging es nicht nur darum, einzelne Workloads zu identifizieren.

Der zweite Dienstprinzipal fragte außerdem Konfigurationsspeicher von Azure App Service ab – möglicherweise auf der Suche nach Zugangsdaten in Anwendungseinstellungen. Die Suche nach Azure-OpenSearch-Ressourcen blieb erfolglos. Auch ein ListKey-Aufruf für ein nicht vorhandenes Speicherkonto schlug fehl.

Weniger als eine Sekunde nach dieser fehlgeschlagenen Anfrage begannen die Löschversuche.

Speicherkonten und unterstützende Dienste wurden innerhalb weniger Minuten gelöscht

Der Angreifer unternahm mehr als 100 Versuche, Azure-Speicherkonten zu löschen. Die meisten davon waren erfolgreich. Auch ein Azure Key Vault, eine Function App und ein App Service-Plan in derselben Ressourcengruppe wurden entfernt.

Laut Berichten zu den beobachteten Azure-Angriffen dauerte die zerstörerische Phase etwa sieben Minuten. Neben Speicherkonten, Key Vaults und Function Apps waren auch virtuelle Maschinen und App Services betroffen. Microsofts ausführlicherer Bericht beschreibt zwar die Erfassung virtueller Maschinen, bestätigt aber nicht, dass diese tatsächlich gelöscht wurden.

JadePuffer versuchte außerdem, mehrere Azure-SQL-Datenbanken zu löschen. Diese Versuche schlugen fehl, weil der Angreifer eine nicht unterstützte API-Version angab. Das zeigt, dass auch eine schnelle, automatisierte Angriffskette scheitern kann, wenn die Anfragen nicht zum jeweiligen Dienst passen.

Anschließend richtete sich der Angriff erneut gegen den Speicherbereich. Etwa 30 Minuten nach der Löschphase forderte der kompromittierte Dienstprinzipal eine Liste der Azure-Speicherkonten an, darunter Konten, die mit Azure Site Recovery verknüpft waren.

Danach führte der Angreifer mehr als 30 erfolgreiche ListKeys-Anfragen aus und erhielt dadurch Zugriffsschlüssel für die Speicherkonten. Je nach Konfiguration können diese Schlüssel direkten Zugriff auf Speicherkonten ermöglichen – unabhängig von den ursprünglichen Azure-RBAC-Berechtigungen des Dienstprinzipals.

Der Angreifer versuchte auch, Sicherungs- und Wiederherstellungsmaßnahmen zu schwächen. Die Versuche, Sperren von Azure Site Recovery zu entfernen, schlugen fehl. Ressourcensperren und Schutzmaßnahmen auf Ebene der Speicherkonten verhinderten außerdem die Löschung einiger angegriffener Konten.

Diese Kontrollen machten einen messbaren Unterschied. Sie konnten den Angriff nicht stoppen, begrenzten aber seine Reichweite.

Ein offengelegtes GitHub-Geheimnis könnte den Zugriff erklären – die Zuordnung bleibt jedoch unvollständig

Microsoft konnte nicht genau feststellen, wie die beiden Dienstprinzipale kompromittiert wurden. Bei einer der Identitäten entdeckte das Unternehmen jedoch einen möglichen erheblichen Datenabfluss.

Ein Mitarbeiter der betroffenen Organisation hatte die Client-ID, das Clientgeheimnis und die Mandanten-ID des Dienstprinzipals im Klartext in einem öffentlichen GitHub-Issue veröffentlicht. Das Issue wurde später bearbeitet und das Geheimnis entfernt. Der ursprüngliche Wert war jedoch weiterhin über den öffentlichen Bearbeitungsverlauf abrufbar.

Microsoft konnte nicht bestätigen, dass JadePuffer das offengelegte Zugangsmittel erlangt oder verwendet hatte. Der Fund stellt daher einen plausiblen Zugangsweg dar, aber keinen Beleg für den Erstzugriff.

Dieser Unterschied ist wichtig: Wird ein Geheimnis aus der aktuellen Version eines Beitrags gelöscht, verschwinden dadurch weder Kopien noch zwischengespeicherte Inhalte, der Repository-Verlauf oder die Bearbeitungsprotokolle der Plattform. Sobald ein Zugangsmittel in einem öffentlichen System auftaucht, sollten Verteidiger es als kompromittiert behandeln und austauschen, statt sich auf das Entfernen des Inhalts zu verlassen.

Wie Ross Filipek, CISO bei Corsica Technologies, anmerkte, können Aktionen über eine Anwendungsidentität außerdem wie normale Cloud-Administration aussehen. Das erschwert die Erkennung, wenn die Überwachung vor allem fehlgeschlagene Anmeldungen oder verdächtige Sitzungen menschlicher Nutzer im Blick hat – und nicht ungewöhnliches API-Verhalten von Workload-Identitäten.

Microsoft beobachtet außerdem seit Jahresbeginn eine mit JadePuffer verbundene Infrastruktur, die Azure App Services bei mehreren Kunden auf Schwachstellen prüft. Zu den getesteten Pfaden gehörten WordPress-Administrationsseiten, PHP-CGI, der Endpunkt zur Codevalidierung von LangFlow unter /api/v1/validate/code sowie Pfade, die Web-Shell-Verzeichnissen ähneln.

Ob diese Prüfungen zu der hier beschriebenen Kompromittierung führten, ist nicht bekannt.

Das Ransomware-Muster ist deutlich, der KI-Einsatz hingegen weniger eindeutig

Microsoft stufte die Aktivitäten als mit Ransomware- oder Erpressungstaktiken vereinbar ein. Das Löschen von Produktionsressourcen, der Versuch, Speicherschlüssel zu erlangen, und die Angriffe auf Wiederherstellungsmaßnahmen passen zu einer Strategie, die durch Zerstörung Druck ausüben soll.

Die Ermittler fanden jedoch keine Lösegeldforderung, bestätigten keine finanzielle Forderung und konnten keine erfolgreiche Datenexfiltration nachweisen. Den Vorfall als Ransomware zu bezeichnen, beschreibt daher das mutmaßliche Vorgehen – nicht einen abgeschlossenen und belegten Erpressungsversuch.

Sysdig bezeichnete JadePuffer im Juli als den ersten dokumentierten Ransomware-Angriff, bei dem ein großes Sprachmodell zum Einsatz kam. Das geht aus Berichten zu Microsofts Erkenntnissen und früheren Aktivitäten des Akteurs hervor. Der Analyse zufolge automatisierten KI-Agenten mehrere Phasen, darunter Aufklärung, Diebstahl von Zugangsdaten, laterale Bewegung, Persistenz und Verschlüsselung.

JadePuffer weitete seine Angriffe später Berichten zufolge auf KI-Ressourcen, Trainingsdatensätze und Vektordatenbanken aus und setzte dafür ein Tool namens EncForge ein.

Der Azure-Vorfall belegt eine hochgradig koordinierte Automatisierung. Er beweist für sich genommen jedoch nicht, dass ein KI-Agent jeden API-Aufruf auswählte oder steuerte.

Nick Tausek, leitender Architekt für Sicherheitsautomatisierung bei Swimlane, hob diesen Unterschied hervor und teilte zugleich Microsofts grundsätzliche Warnung: Agentische KI könnte Angreifern ermöglichen, Aktionen schneller und für mehr Ressourcen auszuführen. Eine schnelle Koordination allein belegt jedoch nicht, dass KI die gesamte Angriffskette kontrollierte.

Für Verteidiger ist das praktische Risiko in beiden Fällen ähnlich. Cloud-Identitäten können Hunderte Abfragen zur Erkundung und Löschung deutlich schneller ausführen, als ein menschliches Reaktionsteam sie manuell prüfen kann.

Verteidiger sollten offengelegte Zugangsdaten austauschen und Anwendungsidentitäten einschränken

Organisationen, die Azure nutzen, sollten zunächst Dienstprinzipale mit weitreichendem Zugriff auf Speicher, Wiederherstellungssysteme, Key Vaults, Anwendungskonfigurationen und Löschvorgänge ermitteln. Die Azure-RBAC-Zuweisungen sollten daraufhin geprüft werden, ob sie dem Prinzip der geringsten Berechtigungen entsprechen – insbesondere, wenn eine Identität über mehrere Abonnements hinweg agieren kann.

Microsoft empfiehlt folgende Maßnahmen:

• Für kritische Azure-Workloads geeignete Microsoft Defender for Cloud-Pläne aktivieren.
• Anmeldeinformationen und Geheimnisse von Anwendungen kontinuierlich auf mögliche Offenlegung prüfen.
• Zugangsdaten sofort austauschen, wenn sie veröffentlicht wurden oder ein Kompromittierungsverdacht besteht.
• Lebenszykluskontrollen für die Erstellung, Speicherung, Gültigkeitsdauer und den Widerruf von Geheimnissen einführen.
• Die Berechtigungen von Dienstprinzipalen und Workload-Identitäten auf das erforderliche Minimum beschränken.
• Öffentliche Repositories, Issues, Kommentare und Versionsverläufe auf offengelegte Zugangsdaten prüfen.

Ressourcensperren und Schutzmaßnahmen für Speicherkonten sollten ebenfalls eingerichtet werden, sofern dies betrieblich sinnvoll ist. Bei diesem Vorfall verhinderten sie unmittelbar einige Löschversuche, darunter Angriffe auf geschützte Speicher- und Wiederherstellungsressourcen.

Bei der Überwachung sollten ganze Ereignisabfolgen statt einzelner Aktionen im Mittelpunkt stehen. Warnsignale sind etwa eine schnelle, abonnementweite Erfassung von Ressourcen, Zugriffe auf Konfigurationsspeicher von App Service, eine Häufung von ListKeys-Anfragen für Speicherkonten sowie zahlreiche Löschvorgänge durch einen Dienstprinzipal.

Microsoft verwies auf Project Perception und MDASH als Initiativen, die Verteidigern mithilfe KI-gestützter Arbeitsabläufe bei der Untersuchung und Reaktion in großen Umgebungen helfen sollen. Unabhängig davon, welche Technologie zum Einsatz kommt, bleibt die unmittelbare Aufgabe klar: Anwendungsidentitäten müssen wie privilegierte Akteure überwacht werden – nicht wie vertrauenswürdige Hintergrundprozesse.