Angriff auf Microsoft Azure : Storm-3168 missbraucht Azure Service Principals

Microsoft hat zerstörerische Aktivitäten in einer Azure-Umgebung untersucht, die das Unternehmen unter Storm-3168 verfolgt und mit JADEPUFFER verbindet. Der Angriff erstreckte sich Anfang Juni 2026 über ungefähr 18 Stunden. Im Mittelpunkt standen zwei kompromittierte Service Principals: technische Identitäten, mit denen Anwendungen auf Cloud-Ressourcen zugreifen. Die Analyse von Microsoft beschreibt damit vor allem den Missbrauch vorhandener Zugriffsrechte.

Warum eine Anwendungsidentität so viel Schaden anrichten kann

Ein Service Principal repräsentiert eine Anwendung innerhalb eines Mandanten, also des Identitätsverzeichnisses einer Organisation. Er ermöglicht es beispielsweise einem automatisierten Prozess, Ressourcen bereitzustellen oder Konfigurationen auszulesen, ohne dass sich dafür ein Mensch interaktiv anmelden muss.

Dabei sind Identität und Berechtigung getrennte Fragen: Die Anmeldung weist nach, welche Anwendung zugreift. Die zugewiesenen Rollen bestimmen, welche Aktionen sie ausführen darf. Microsoft erläutert dieses Verhältnis in seiner Dokumentation zu Anwendungen und Service Principals.

Ein Client Secret dient dabei als geheimer Anmeldenachweis. Die Client-Kennung bezeichnet die Anwendung, die Mandantenkennung das zugehörige Verzeichnis. Diese beiden Kennungen sind für sich genommen keine Passwörter. Zusammen mit einem gültigen Secret können sie jedoch die Anmeldung unter der Anwendungsidentität ermöglichen.

Der Schaden hängt anschließend vom Umfang der Rollen ab. Die rollenbasierte Zugriffskontrolle, englisch Role-Based Access Control (RBAC), kann Berechtigungen auf einzelne Ressourcen begrenzen oder über große Teile einer Umgebung erstrecken. Microsoft empfiehlt deshalb, sowohl erlaubte Aktionen als auch deren Geltungsbereich möglichst eng zu fassen. Ein Automatisierungsprozess sollte nicht vorsorglich eine ganze Subscription verwalten dürfen, wenn er nur eine einzelne Ressource benötigt. Eine Subscription bildet in Azure einen Verwaltungs- und Abrechnungsbereich. Die RBAC-Empfehlungen zielen darauf, den möglichen Schaden einer kompromittierten Identität einzugrenzen.

Lange Erkundung, kurze Zerstörungsphase

Die beiden Identitäten teilten sich die Arbeit. Eine sammelte fast 16 Stunden lang mit mehr als 300 Leseoperationen Informationen über die Umgebung. Die zweite führte anschließend innerhalb von 35 Minuten über 150 zerstörerische oder auf Zugangsdaten gerichtete Operationen aus. Die eigentliche Löschserie dauerte etwa sieben Minuten und umfasste mehr als 100 Löschversuche gegen Speicherkonten.

Zum erfassten Zielspektrum gehörten:

• Azure-Speicherkonten;
• Azure-Datenbanken für Structured Query Language (SQL);
• Azure Key Vaults zur Verwaltung von Geheimnissen und Schlüsseln;
• Azure Function Apps;
• Schutzsperren für die Wiederherstellung;
• virtuelle Maschinen;
• Azure App Services.

Das Zielspektrum ist nicht mit einer Liste erfolgreich gelöschter Ressourcen gleichzusetzen. „Die meisten angegriffenen Azure-Speicherkonten wurden erfolgreich gelöscht“, berichtet Microsoft. Die SQL-Löschversuche scheiterten dagegen an einer nicht unterstützten Version der Programmierschnittstelle (API).

Ein API-Versionsfehler ist allerdings keine belastbare Schutzmaßnahme: Er beschreibt einen Fehler in der Angriffsausführung. Korrigierte Aufrufe könnten bei unveränderten Berechtigungen erneut gefährlich werden.

Öffentliches Secret als mögliche Eintrittsstelle

Microsoft fand Client-Kennung, Mandantenkennung und Secret zuvor im Klartext in einem öffentlichen GitHub-Issue. Ein Beschäftigter hatte sie dort veröffentlicht. Zwar wurde der Beitrag bearbeitet, doch das Secret blieb über die Änderungshistorie abrufbar. Ob genau dieser Fund den Erstzugriff ermöglichte, konnte Microsoft nicht bestätigen.

Die Angriffe nutzten bestehende Rollen: Gruppenvermittelte Speicherrechte ermöglichten Löschungen, direkte Contributor-Rechte weitere Eingriffe. Zusätzlich beobachtete Microsoft später mehr als 30 erfolgreiche ListKeys-Aufrufe, mit denen Speicherkontenschlüssel abgefragt wurden.

Das erklärt, weshalb die Untersuchung nach dem letzten Löschversuch nicht enden darf. Ein Speicherkontenschlüssel kann einen eigenständigen Zugang zu Daten eröffnen. Nach der Dokumentation zur Schlüsselverwaltung ermöglichen solche Schlüssel weitreichenden Datenzugriff. Werden sie entwendet, genügt es nicht, nur das ursprünglich kompromittierte Anwendungs-Secret zu ersetzen.

Das Entfernen einer Veröffentlichung macht einen bereits kopierten Zugangsnachweis ebenfalls nicht ungültig. Bei einer Offenlegung müssen deshalb die betroffenen Geheimnisse ersetzt beziehungsweise widerrufen und ihre bisherige Verwendung untersucht werden. Für unterstützte Anwendungen bieten verwaltete Identitäten einen strukturellen Vorteil: Entwickler müssen keine eigenen langlebigen Anmeldegeheimnisse verwalten. Die Berechtigungen dieser Identitäten müssen dennoch begrenzt bleiben.

Löschsperren schützen nicht automatisch sämtliche Daten

Einige Löschversuche wurden durch zusätzliche Schutzfunktionen für Ressourcen und Speicherkonten blockiert. Diese können Schäden verhindern. Betreiber müssen jedoch wissen, welche Löschaktionen sie tatsächlich unterbinden und welche weiterhin möglich bleiben.

Der Azure Resource Manager (ARM) verwaltet Ressourcen und deren Konfiguration. Eine dort gesetzte CannotDelete-Sperre verhindert das Löschen eines Speicherkontos, lässt aber Änderungen seiner Konfiguration zu. Eine ReadOnly-Sperre beschränkt auch solche Änderungen. Microsoft beschreibt beide Varianten in der Dokumentation zu Speicherkontensperren.

Diese Sperren wirken auf der Verwaltungsebene. Sie verhindern nicht automatisch, dass Dateien beziehungsweise Speicherobjekte innerhalb eines weiter bestehenden Kontos gelöscht oder überschrieben werden. Dafür sind zusätzliche Datensicherungsmechanismen erforderlich.

Auch beim Schlüsselzugriff ist die Abgrenzung relevant: Eine ReadOnly-Sperre kann neue ListKeys-Abfragen blockieren. Bereits bekannte Kontenschlüssel werden dadurch aber nicht ungültig. Ressourcenschutz, Datenzugriff und Schlüsselrotation müssen daher gemeinsam betrachtet werden.

Für Backups empfiehlt Microsoft unter anderem getrennte Sicherheitszuständigkeiten und zusätzliche Schutzmechanismen gegen destruktive Änderungen. Die Sicherheitsempfehlungen für Azure Backup erläutern entsprechende Maßnahmen. Praktisch bedeutet das: Die Identität, die produktive Ressourcen verwaltet, sollte nicht zugleich ungehindert deren letzte Wiederherstellungsmöglichkeit beseitigen können.

Was die Verbindung zu JADEPUFFER aussagt

Die Zuordnung ist auch deshalb bemerkenswert, weil Sysdig JADEPUFFER zuvor als KI-gestützte Erpressungsoperation beschrieben hatte. In der ersten Untersuchung diente die bekannte Schwachstelle CVE-2025-3248 in Langflow als Einstieg. Es folgten das Sammeln von Zugangsdaten, weitere Zugriffe und die Verschlüsselung von Nacos-Konfigurationsdaten mithilfe der eingebauten MySQL-Funktion AES_ENCRYPT(). Originaltabellen wurden gelöscht und eine Bitcoin-Lösegeldforderung hinterlassen.

Sysdig ordnete den Einsatz eines großen Sprachmodells (LLM) als verbindendes Element der Angriffsschritte ein. „Keine der einzelnen Techniken war neuartig oder ausgefeilt“, lautete die Bewertung. Die Bedeutung lag demnach in der automatisierten Kombination bekannter Methoden zu einer vollständigen Operation.

Bei einem späteren Angriff auf dieselbe Langflow-Instanz setzte der JADEPUFFER-Akteur eine weitere Schadsoftware ein: die in Go entwickelte Ransomware ENCFORGE. Wie Sysdig in einem Folgebericht erläutert, ist sie auf die Verschlüsselung von Dateien aus KI-Umgebungen ausgerichtet. Sie sucht nach knapp 180 Dateiendungen, darunter:

• Modell-Zwischenstände;
• Vektordatenbanken;
• Trainingsdatensätze;
• Embedding-Indizes;
• macOS-Schlüsselbunddateien;
• Xcode-Projektdateien;
• Apple-Pages-Dokumente;
• Apple-Numbers-Dokumente.

Die früheren Untersuchungen zeigen, welche Methoden JADEPUFFER bereits eingesetzt hat. Ob beim Azure-Angriff ebenfalls ENCFORGE, dieselbe Sicherheitslücke oder dieselbe Verschlüsselungsmethode verwendet wurden, ist jedoch nicht belegt.

Automatisierte Abläufe, aber kein belegter Erpressungsversuch

Die Aktionen folgten schnell aufeinander und wurden teilweise gleichzeitig mit mehreren digitalen Zugangsnachweisen, sogenannten Tokens, ausgeführt. Das spricht laut Microsoft für automatisierte Abläufe. Ob dabei ein System mit Künstlicher Intelligenz Entscheidungen traf oder vorbereitete Skripte abgearbeitet wurden, lässt sich daraus allein nicht erkennen.

Auch das Ziel der Angreifer ist nicht abschließend geklärt. Das Löschen von Ressourcen, die Angriffe auf Wiederherstellungsfunktionen und das Sammeln von Zugangsschlüsseln könnten eine Erpressung vorbereiten. Microsoft beobachtete bei diesem Vorfall jedoch weder eine Lösegeldforderung noch einen nachgewiesenen Datenabfluss.

Für Unternehmen zeigt der Angriff vor allem, wie gefährlich zu weitreichende Anwendungsrechte sind. Gelangen die Zugangsdaten in fremde Hände, können Angreifer die erlaubten Funktionen zum Ausspähen oder Löschen missbrauchen. Anwendungen sollten deshalb streng nur die Rechte erhalten, die sie tatsächlich benötigen. Backups müssen zusätzlich vor solchen Zugriffen geschützt und Zugangsschlüssel sicher verwaltet werden. Gemeinsam können diese Maßnahmen den Schaden eines gestohlenen Anwendungszugangs begrenzen.