Microsoft hat umfangreiche destruktive Aktivitäten innerhalb einer Azure-Umgebung offengelegt und sie der Gruppe Storm-3168 zugeordnet, die auch unter ihrer Verbindung zu JADEPUFFER bekannt ist. Der Angriff stützte sich auf zwei kompromittierte Dienstidentitäten (Service Principals), um Ressourcen aufzuklären, Cloud-Dienste zu löschen und Anmeldeinformationen zu sammeln, die für den Zugriff auf Daten oder zur späteren Erleichterung ihrer Entnahme verwendet werden könnten.
Microsoft zufolge liefert die Untersuchung die erste detaillierte Beschreibung der Aktivitäten von Storm-3168 innerhalb von Azure und erweitert das bisherige Wissen über JADEPUFFER, die Sysdig im Juli 2026 als den ersten dokumentierten Ransomware-Vorgang bezeichnete, der auf Agenten basiert. Microsoft bestätigte nicht, dass der Vorfall eine erfolgreiche Datenentnahme umfasste, und beobachtete auch keine Lösegeldforderung.
Aufklärung vor der Zerstörung
Anfang Juni 2026 verbrachte eine der Dienstidentitäten etwa 15 Stunden und 30 Minuten damit, virtuelle Maschinen, Abonnements, Ressourcengruppen und Ressourcen aufzulisten, wobei mehr als 300 erfolgreiche Lesevorgänge durchgeführt wurden. Etwa 90 Minuten später führte die zweite Identität innerhalb von nur fünf Sekunden über zwei Abonnements hinweg eine Auflistung virtueller Maschinen und Ressourcengruppen durch.
Beide Identitäten verwendeten eine mit Storm-3168 verbundene Infrastruktur, einen einheitlichen Netzwerk-Fingerprint und den User-Agent python-requests/2.34.2. Nach 16 Stunden untersuchte die zweite Identität App-Service-Konfigurationsspeicher, vermutlich auf der Suche nach offengelegten Anmeldeinformationen. Anschließend versuchte sie erfolglos, auf Azure-OpenSearch-Ressourcen zuzugreifen, bevor sie einen ListKey-Versuch gegen ein nicht vorhandenes Speicherkonto durchführte.
Löschen von Ressourcen und Sammeln von Schlüsseln
Weniger als eine Sekunde nach dem fehlgeschlagenen ListKey-Versuch begann die destruktive Kette. Die zweite Identität führte innerhalb von 35 Minuten mehr als 150 Vorgänge im Zusammenhang mit dem Löschen oder Sammeln von Anmeldeinformationen durch, während die eigentliche destruktive Phase etwa sieben Minuten dauerte.
Die Aktivitäten umfassten mehr als 100 Versuche, Azure-Storage-Konten zu löschen, von denen die meisten erfolgreich waren, sowie das Löschen von Azure Key Vault, einer Function App und eines App-Service-Plans. Außerdem wurden parallel Versuche unternommen, Azure-SQL-Datenbanken zu löschen; diese scheiterten jedoch aufgrund der Verwendung einer nicht unterstützten Version der API. Die Angreifer versuchten außerdem, mit Azure Site Recovery und Azure Backup verbundene Sperren zu löschen, also Ressourcen, die dem Schutz der Wiederherstellung dienen.
Etwa 30 Minuten nach dem letzten destruktiven Vorgang führte die Identität mehr als 30 erfolgreiche ListKeys-Anfragen aus, wodurch Zugriffsschlüssel für Speicherkonten zurückgegeben wurden, darunter Konten, die mit Azure Site Recovery verbunden waren.
Was bedeutet das für Verteidiger?
Microsoft ist der Ansicht, dass die Kombination aus dem Löschen von Ressourcen, dem Angriff auf Sicherungs- und Wiederherstellungskontrollen sowie dem Versuch, Speicherschlüssel zu erlangen, mit Taktiken übereinstimmt, die Ransomware und Erpressung unterstützen können. Die Quelle belegt jedoch allein nicht, dass das endgültige Ziel darin bestand, das Opfer zu erpressen, oder dass Daten tatsächlich entwendet wurden.
Die Untersuchung weist außerdem auf die Bedeutung unabhängiger Schutzmechanismen hin: Ressourcensperren und der Löschschutz auf Ebene einiger Speicherkonten verhinderten weitere Löschvorgänge, selbst wenn die kompromittierte Identität weitreichende administrative Berechtigungen besaß. Gleichzeitig ermöglichten Azure-RBAC-Rollen, die der Gruppe oder direkt der Dienstidentität gewährt worden waren, die Durchführung der destruktiven Vorgänge, die in ihrem Berechtigungsumfang lagen.
Empfohlene Schutzmaßnahmen
- Alle offengelegten Anmeldeinformationen unverzüglich rotieren oder widerrufen; das Entfernen eines Geheimnisses aus einer öffentlichen Veröffentlichung macht es nicht ungültig, da es möglicherweise im Änderungsverlauf, im Cache oder in Archiven verbleibt.
- Das Prinzip der geringsten Berechtigung auf Dienstidentitäten anwenden und Azure-RBAC-Rollen sowie die Ressourcen überprüfen, auf die jede Identität zugreifen kann.
- Sicherungs- und Wiederherstellungsressourcen schützen und Versuche überwachen, ihre Sperren zu ändern oder zu löschen.
- Geeignete Microsoft-Defender-for-Cloud-Pläne aktivieren, einschließlich des Schutzes für Resource Manager, Storage, Key Vault, App Service und Datenbanken.
- Durch künstliche Intelligenz unterstützte Untersuchungs- und Reaktionsfunktionen wie Project Perception einsetzen und dabei KI-Anwendungen sowie agentische Systeme absichern.