Storm-3168 löscht Azure-Ressourcen – ein entferntes Secret bleibt gültig

28. September 2026 um 21:39|Autor: QUASA-Redaktion|5 Min. Lesezeit

Microsofts Analyse vom 25. September 2026 dokumentiert, wie Storm-3168 Anfang Juni 2026 mit zwei kompromittierten Service Principals Ressourcen eines Azure-Tenants auskundschaftete und löschte. Die Angreifer riefen außerdem Schlüssel von Storage Accounts ab. Ein Secret einer betroffenen Identität war zuvor in einem öffentlichen GitHub-Issue erschienen und später aus dem Beitrag entfernt worden; das machte es nicht ungültig. Ob die Angreifer genau dieses Secret für den Erstzugang nutzten, blieb ungeklärt.

Die Warnung von HackWatch ordnet den Anfang Juni beobachteten Azure-Vorfall als Identitäts- und Kontokompromittierung ein und vermerkt verfügbare Gegenmaßnahmen. Für andere Azure-Umgebungen folgt daraus keine bestätigte Betroffenheit. Zu prüfen ist vielmehr, welche Anwendungsidentitäten dort Löschrechte und Zugriff auf Storage-Schlüssel besitzen und welche Schutzsperren trotz kompromittierter Rechte wirksam wären.

Wie die kompromittierten Service Principals zusammenwirkten

Die beiden Identitäten hatten im betroffenen Tenant unterschiedliche Rollen im Angriff. Eine erfasste über längere Zeit virtuelle Maschinen, Abonnements, Ressourcengruppen und weitere Ressourcen. Die andere durchsuchte ebenfalls die Umgebung, ging dann aber zu Löschaufrufen und zum Abruf von Zugangsdaten über. Für die Rekonstruktion ist diese Trennung entscheidend: Inventarabfragen und spätere Zerstörung müssen nicht unter derselben Anwendungsidentität auftauchen, obwohl sie zum selben Ablauf gehören.

Vor den Löschungen sichtete die zweite Identität Konfigurationsspeicher von Azure App Service. Danach scheiterte ein Schlüsselabruf für ein nicht existentes Storage-Konto; unmittelbar darauf begannen die destruktiven Aufrufe. Das enge zeitliche Zusammenspiel und parallel verwendete Zugriffstoken sprechen für automatisierte oder skriptgesteuerte Ausführung. Aus den beobachteten Azure-Operationen allein lässt sich jedoch kein bestimmtes Werkzeug ableiten.

Sieben Minuten Löschaufrufe, danach Schlüsselabrufe

Die Rekonstruktion von Cyber Press beschreibt eine etwa siebenminütige Zerstörungsphase mit mehr als 100 Versuchen, Azure Storage Accounts zu löschen. Die meisten angegriffenen Konten wurden tatsächlich gelöscht. Azure-Ressourcensperren und ein Löschschutz auf Ebene einzelner Storage Accounts verhinderten einige weitere Löschungen. Versuchte und erfolgreiche Aufrufe sind deshalb für die Schadensbewertung getrennt zu zählen.

Aus derselben Ressourcengruppe wurden auch ein Azure Key Vault, eine Function App und ihr App Service Plan gelöscht. Gleichzeitige Löschversuche gegen Azure SQL-Datenbanken scheiterten an einer für diesen Ressourcentyp nicht unterstützten API-Version. Auch Versuche, Schutzsperren für Azure Site Recovery und Azure Backup zu entfernen, blieben erfolglos. Der Ablauf zeigt damit sowohl tatsächlich zerstörte Ressourcen als auch Grenzen der verwendeten Rechte und Befehle.

Nach dem Ende der Löschungen rief die kompromittierte Identität Zugriffsschlüssel von Storage Accounts ab, darunter solche mit Bezug zu Azure Site Recovery. Der Abruf verschaffte ihr Zugangsdaten, die für weitere Zugriffe nutzbar sein könnten. Er belegt aber weder einen Zugriff auf gespeicherte Inhalte noch deren Abfluss. Für den beschriebenen Vorfall sind auch eine Lösegeldforderung und eine erfolgreiche Datenexfiltration nicht bestätigt.

Das GitHub-Secret ist eine Spur, kein belegter Erstzugang

In einem öffentlichen GitHub-Issue standen Client-ID, Client-Secret und Tenant-ID einer betroffenen Identität im Klartext. Nach einer Bearbeitung war das Secret weiterhin über die öffentliche Änderungshistorie erreichbar. Der Fund macht eine Kompromittierung über diesen Weg plausibel, beweist aber nicht, dass die Angreifer diesen Wert tatsächlich einsetzten. Beobachtete Abfragen von App-Service-Pfaden lieferten ebenfalls keinen belegten Zugangsweg zu den betroffenen Azure-Abonnements.

Die technische Folge der Veröffentlichung ist unabhängig von dieser offenen Frage: Das Entfernen eines Secrets aus dem sichtbaren Beitrag widerruft es nicht. Seine Nutzbarkeit endet erst durch Widerruf oder Rotation; zudem können Kopien in Änderungshistorien, Archiven oder Protokollen fortbestehen. Eine bereinigte Fundstelle ist daher kein Nachweis dafür, dass die zugehörige Anwendungsidentität wieder sicher ist.

Kontrollmatrix für Secrets, Rollen und Wiederherstellung

Die folgende Prüfreihenfolge übersetzt die beobachteten Schritte in konkrete Azure-Artefakte. Sie ist eine redaktionelle Ableitung für die Untersuchung der eigenen Umgebung, keine Aussage über weitere Opfer dieses Vorfalls.

Öffentliche Secret-Spuren: Repositories, Issues und ihre Änderungshistorien auf Client-Secrets, Storage-Schlüssel und Verbindungszeichenfolgen prüfen. Jeder gefundene Wert muss einer Anwendungsidentität zugeordnet und widerrufen oder rotiert werden. Danach lässt sich seine bisherige Verwendung untersuchen; das Löschen des Fundorts ersetzt diesen Schritt nicht.
Service Principals und Rollen: Direkte und über Gruppen vergebene Azure-RBAC-Rechte der betroffenen Identitäten erfassen. Im dokumentierten Fall erlaubte eine gruppenbasierte Storage Account Contributor-Rolle die Storage-Operationen; direkte Contributor-Rechte ermöglichten Löschungen von Anwendungsressourcen. Die Prüfung sollte festhalten, welche dieser Rechte für die jeweilige Anwendung tatsächlich erforderlich sind.
Aktivitäts- und Anmeldeprotokolle: Inventarabfragen, Delete-Aufrufe und ListKeys-Operationen nach Identität, Zielressource, Zeitpunkt und Ergebnis zusammenführen. So bleibt sichtbar, ob eine Identität nur Ressourcen auflistete, ob ein Löschversuch scheiterte oder ob ein Schlüsselabruf erfolgreich war. Die Reihenfolge der Vorgänge ist aussagekräftiger als ein isolierter Aufruf.
Sperren und Wiederherstellungsschutz: Ressourcensperren, Löschschutz sowie Berechtigungen für Azure Backup und Azure Site Recovery gemeinsam prüfen. In diesem Fall verhinderten Schutzmechanismen einige Löschungen, während die Angreifer zugleich versuchten, Sperren für Wiederherstellungsressourcen zu entfernen. Entscheidend ist auch, wer diese Schutzmechanismen ändern darf.
Abgerufene Storage-Schlüssel: Erfolgreiche ListKeys-Aufrufe den jeweiligen Konten zuordnen und die betroffenen Schlüssel nach Prüfung der betrieblichen Abhängigkeiten rotieren. Verfügbare Datenzugriffsprotokolle können anschließend zeigen, ob mit den Schlüsseln Inhalte gelesen wurden. Der Schlüsselabruf allein reicht für diesen Schluss nicht aus.

Was der Befund noch offenlässt

Für den untersuchten Tenant stehen die kompromittierten Anwendungsidentitäten, erfolgreiche Ressourcenlöschungen und Abrufe von Storage-Schlüsseln fest. Der genaue Erstzugang ist ebenso offen wie eine mögliche spätere Datenabfuhr. Weitere Erkenntnisse zu diesen Punkten enthält die veröffentlichte Fallrekonstruktion nicht; auch aus den fehlgeschlagenen Löschversuchen lässt sich kein größerer Schaden ableiten, als die beobachteten Ergebnisse belegen.

Lesen Sie auch: