Storm-3168: KI Angriff löscht Azure Ressourcen

Microsoft warnt vor einer neuen Form hochautomatisierter Cloud Angriffe. Die von Microsoft als Storm-3168 bezeichnete Gruppe nutzte kompromittierte Azure Service Principals, um eine Unternehmensumgebung zunächst umfassend auszuspähen und anschließend zahlreiche Cloud Ressourcen anzugreifen. Besonders bemerkenswert ist die Geschwindigkeit: Ein großer Teil der zerstörerischen Aktionen lief nach Angaben von Microsoft innerhalb von rund sieben Minuten ab.

Der Fall zeigt, wie gefährlich kompromittierte Maschinenidentitäten inzwischen sein können. Während klassische Angriffe häufig Benutzerkonten und Kennwörter in den Mittelpunkt stellen, richtete sich dieser Angriff gegen sogenannte Workload Identitäten. Für Administratoren bedeutet das, dass nicht nur Benutzerkonten, sondern auch Anwendungen, Service Principals, Geheimnisse und Azure Rollen konsequent geschützt werden müssen.

Storm-3168 greift Azure Ressourcen automatisiert an

Microsoft hat die Untersuchung am 25. September 2026 veröffentlicht. Storm-3168 wird mit dem Bedrohungsakteur JADEPUFFER in Verbindung gebracht, der bereits durch stark automatisierte und agentenbasierte Angriffe aufgefallen ist. Microsoft beschreibt den aktuellen Vorfall als umfangreiche Azure Aktivität mit Aufklärung, Ressourcenerkennung, Löschaktionen und dem Sammeln von Zugangsdaten.

Die vollständige technische Analyse findest Du im offiziellen Microsoft Security Blog zu Storm-3168. Die Untersuchung ist auch deshalb interessant, weil Microsoft zeigt, wie schnell automatisierte Angriffe nach einer erfolgreichen Kompromittierung skalieren können.

Was ist ein Azure Service Principal?

Ein Service Principal ist vereinfacht gesagt eine Identität für Anwendungen und automatisierte Prozesse. Eine Software kann damit auf Azure Ressourcen zugreifen, ohne dass sich jedes Mal ein menschlicher Benutzer anmelden muss. Solche Identitäten sind für Automatisierung, Skripte, Cloud Dienste und Schnittstellen sehr wichtig.

Genau darin liegt jedoch auch das Risiko. Besitzt ein Service Principal weitreichende Rechte und gelangt ein Angreifer an dessen Geheimnis oder andere Zugangsdaten, kann er mit denselben Berechtigungen arbeiten wie die legitime Anwendung. Das unterscheidet sich deutlich von klassischen Benutzerangriffen, wie wir sie beispielsweise beim EvilTokens Device Code Phishing beschrieben haben.

So lief der Storm-3168 Angriff ab

Microsoft beobachtete zwei kompromittierte Service Principals innerhalb desselben Azure Tenants. Einer davon wurde überwiegend für die Aufklärung der Umgebung eingesetzt. Über etwa 15 Stunden und 30 Minuten wurden mehr als 300 erfolgreiche Leseoperationen durchgeführt, mit denen virtuelle Maschinen, Abonnements, Ressourcengruppen und weitere Azure Komponenten erfasst wurden.

Der zweite Service Principal arbeitete wesentlich aggressiver. Er konnte innerhalb weniger Sekunden virtuelle Maschinen und Ressourcengruppen in zwei Azure Abonnements erfassen. Später wurden Konfigurationsspeicher von Azure App Services untersucht, vermutlich um weitere Zugangsdaten oder Geheimnisse zu finden.

Phase	Beobachtete Aktivität
Aufklärung	Azure Ressourcen, VMs, Abonnements und Ressourcengruppen wurden erfasst
Automatisierung	Mehrere Service Principals und Tokens arbeiteten parallel
Zerstörung	Mehr als 100 Löschversuche gegen Storage Accounts
Weitere Ziele	Key Vault, Function App, App Service und SQL Datenbanken
Recovery	Auch Schutzmechanismen für Backup und Wiederherstellung wurden angegriffen
Zugangsdaten	Storage Account Schlüssel wurden automatisiert abgefragt

100 Löschversuche innerhalb weniger Minuten

Besonders kritisch wurde der Angriff kurz nach Abschluss der Erkundungsphase. Microsoft beobachtete innerhalb von etwa 35 Minuten mehr als 150 zerstörerische oder auf Zugangsdaten ausgerichtete Aktionen. Der eigentliche Löschvorgang konzentrierte sich dabei auf einen Zeitraum von ungefähr sieben Minuten.

Storm-3168 versuchte mehr als 100 Azure Storage Accounts zu löschen. Ein großer Teil dieser Löschversuche war erfolgreich. Zusätzlich wurden unter anderem ein Azure Key Vault, eine Function App und ein App Service Plan entfernt. Versuche, mehrere Azure SQL Datenbanken zu löschen, scheiterten dagegen, weil eine nicht unterstützte API Version verwendet wurde.

Azure Resource Locks konnten einen Teil des Angriffs stoppen

Der Vorfall zeigt gleichzeitig, dass zusätzliche Schutzebenen Wirkung haben können. Einige Storage Accounts konnten aufgrund vorhandener Resource Locks und Löschschutzmechanismen nicht entfernt werden. Genau solche unabhängigen Schutzmaßnahmen sind wichtig, wenn eine kompromittierte Identität bereits umfangreiche Berechtigungen besitzt.

Dieses Prinzip gilt auch außerhalb von Azure. Eine einzelne Schutzfunktion reicht selten aus. Wie wichtig mehrere Sicherheitsebenen sind, erklären wir ausführlich in unserem Beitrag zur Windows Sicherheit. Auch dort greifen Geräteschutz, Identitätsschutz und Benutzerrechte ineinander.

Möglicherweise öffentlich sichtbares Client Secret

Besonders interessant ist die mögliche Ursache der Kompromittierung. Microsoft stellte fest, dass Client ID, Client Secret und Tenant ID eines betroffenen Service Principals zuvor im Klartext in einem öffentlichen GitHub Issue veröffentlicht worden waren. Der Eintrag wurde später bearbeitet und das Geheimnis entfernt, blieb jedoch über die öffentliche Änderungshistorie weiterhin auffindbar.

Microsoft konnte nicht bestätigen, dass genau dieses Secret für den Angriff verwendet wurde. Der Fall zeigt trotzdem ein entscheidendes Problem: Ein veröffentlichtes Geheimnis gilt als kompromittiert. Es reicht nicht aus, den Text später zu löschen. Das Secret muss widerrufen beziehungsweise ersetzt und seine bisherige Nutzung untersucht werden.

Warum klassische MFA hier nicht hilft

Bei Service Principals handelt es sich nicht um normale Benutzerkonten. Deshalb schützt eine klassische Multi Faktor Authentifizierung solche Workload Identitäten nicht automatisch. MFA bleibt für Administratoren und Benutzer weiterhin unverzichtbar, wie wir in unserer Anleitung zur Zwei Faktor Authentifizierung erklären.

Unternehmen sollten gleichzeitig verstärkt auf phishingresistente Anmeldeverfahren setzen. Microsoft baut diese Strategie derzeit deutlich aus. Unsere aktuelle Übersicht zur Microsoft Entra SMS Abschaltung und Passkey Umstellung zeigt, wohin sich die Benutzeranmeldung entwickelt. Auch Windows Hello kann dabei ein wichtiger Bestandteil moderner Authentifizierung sein.

Storm-3168 Schutz Schritt für Schritt vorbereiten

Schritt 1: Service Principals erfassen

Erstelle zunächst eine vollständige Übersicht über die Service Principals und Anwendungen in Deinem Entra Tenant. Wichtig sind insbesondere Besitzer, letzte Nutzung, zugewiesene Rollen und vorhandene Secrets. Alte oder nicht mehr benötigte Identitäten solltest Du prüfen und gegebenenfalls entfernen.

Schritt 2: Secrets und Zugangsdaten kontrollieren

Suche nach Client Secrets, Storage Keys, Connection Strings und anderen Zugangsdaten in Skripten, Konfigurationsdateien, Ticketsystemen und Quellcode Repositories. Sobald Zugangsdaten öffentlich sichtbar waren, solltest Du davon ausgehen, dass sie kompromittiert sind. Das reine Löschen einer Datei oder eines GitHub Eintrags reicht nicht aus.

Schritt 3: Kompromittierte Secrets sofort austauschen

Ersetze betroffene Geheimnisse sofort und untersuche anschließend die bisherige Nutzung der Identität. Prüfe Anmeldeereignisse, Azure Aktivitäten und ungewöhnliche Zugriffe. Gerade bei automatisierten Angriffen kann der Zeitraum zwischen Kompromittierung und Missbrauch sehr kurz sein.

Schritt 4: Least Privilege konsequent umsetzen

Service Principals sollten nur die Rechte besitzen, die ihre jeweilige Anwendung tatsächlich benötigt. Ein Contributor Recht auf große Bereiche einer Azure Umgebung kann im Fall einer Kompromittierung erheblichen Schaden ermöglichen. Kontrolliere deshalb Azure RBAC Rollen regelmäßig und entferne unnötig breite Berechtigungen.

Schritt 5: Backup und Recovery getrennt absichern

Storm-3168 griff laut Microsoft auch Schutzmechanismen für Wiederherstellung und Backup an. Deshalb sollten Backup Systeme möglichst getrennte Berechtigungen und zusätzliche Schutzmechanismen besitzen. Ein Angreifer, der Produktivdaten löschen kann, sollte nicht gleichzeitig problemlos auch sämtliche Wiederherstellungsoptionen entfernen können.

Schritt 6: Defender und zentrale Überwachung nutzen

Microsoft empfiehlt, passende Defender for Cloud Schutzfunktionen für kritische Azure Workloads zu aktivieren. Gleichzeitig sollten Sicherheitsereignisse zentral ausgewertet werden. Genau in diese Richtung geht auch das neue Microsoft Defender ISOC, das Defender, SIEM und KI gestützte Analyse enger miteinander verbinden soll.

Auf Windows Endpunkten bleibt Microsoft Defender ebenfalls eine wichtige Schutzebene. Hinweise zu Plattform und Updates findest Du in unserer Anleitung zum Windows Defender Download und Update. Unternehmen mit Defender for Endpoint sollten zusätzlich sicherstellen, dass alle vorgesehenen Systeme korrekt eingebunden sind. Bei Problemen hilft unser Beitrag zum Defender for Endpoint Setup Fehler.

Aus der Administratorpraxis: Maschinenidentitäten nicht vergessen

In vielen Umgebungen werden Benutzerkonten inzwischen regelmäßig überprüft, Service Principals dagegen deutlich seltener. Genau hier können über Jahre alte Berechtigungen und Secrets bestehen bleiben. Bewährt hat sich deshalb, Maschinenidentitäten ähnlich streng zu behandeln wie privilegierte Benutzerkonten.

Dazu gehören ein klarer Besitzer, dokumentierter Einsatzzweck, möglichst kurze Laufzeiten für Geheimnisse und regelmäßige Berechtigungsprüfungen. Auch bei klassischen Windows Umgebungen ist das Prinzip der geringstmöglichen Rechte entscheidend. Funktionen wie Windows Credential Guard schützen zwar andere Arten von Zugangsdaten, zeigen aber denselben Grundgedanken: Kritische Identitäten und Geheimnisse sollten nicht unnötig breit verfügbar sein.

Praxistipp: Ein öffentliches Secret immer als kompromittiert behandeln

Findest Du ein Kennwort, Token oder Client Secret in einem öffentlichen Repository, Ticket oder Chat, solltest Du es nicht einfach nur entfernen. Gehe davon aus, dass es bereits kopiert wurde. Tausche das Secret aus, widerrufe alte Zugangsdaten und prüfe anschließend, ob die Identität in der Vergangenheit ungewöhnlich verwendet wurde.

Genau dieser Punkt ist eine der wichtigsten Lehren aus Storm-3168. Sichtbare Zugangsdaten können auch dann noch missbraucht werden, wenn der ursprüngliche Eintrag längst verschwunden ist. Änderungshistorien, Zwischenspeicher und bereits angefertigte Kopien lassen sich nicht zuverlässig kontrollieren.

FAQ zum Storm-3168 Azure Angriff

Was ist Storm-3168?

Storm-3168 ist die Microsoft Bezeichnung für Aktivitäten des Bedrohungsakteurs JADEPUFFER. Microsoft beobachtete bei dem aktuellen Vorfall einen stark automatisierten Angriff auf Azure Ressourcen.

Was wurde bei dem Angriff kompromittiert?

Microsoft beobachtete zwei kompromittierte Azure Service Principals. Diese wurden unter anderem zur Aufklärung, zum Löschen von Ressourcen und zum Sammeln von Zugangsdaten eingesetzt.

Wie schnell lief der Angriff ab?

Der eigentliche zerstörerische Teil des Angriffs konzentrierte sich laut Microsoft auf ungefähr sieben Minuten. Insgesamt wurden innerhalb von etwa 35 Minuten mehr als 150 zerstörerische oder auf Zugangsdaten gerichtete Aktionen versucht.

Welche Azure Ressourcen waren betroffen?

Zu den Zielen gehörten unter anderem Azure Storage Accounts, Key Vaults, Function Apps, App Services, SQL Datenbanken sowie Backup und Recovery Schutzmechanismen.

Hat Storm-3168 Daten erpresst?

Microsoft bewertet die beobachteten Aktionen als mit Ransomware und Erpressung vereinbar. Bei dem untersuchten Vorfall wurde jedoch keine Lösegeldforderung und keine erfolgreiche Datenexfiltration bestätigt.

Wie schützt man Service Principals?

Wichtig sind möglichst geringe Berechtigungen, kurze Lebenszeiten von Secrets, regelmäßige Rotation, eine klare Zuordnung zu verantwortlichen Personen und die Überwachung ungewöhnlicher Aktivitäten.

Reicht es aus, ein veröffentlichtes Secret zu löschen?

Nein. Ein öffentlich sichtbares Secret sollte sofort als kompromittiert betrachtet und ersetzt oder widerrufen werden. Anschließend sollte geprüft werden, ob es bereits missbraucht wurde.

Fazit zum Storm-3168 Angriff

Storm-3168 zeigt, wie schnell moderne Cloud Angriffe durchgeführt werden können. Sobald ein Service Principal mit umfangreichen Berechtigungen kompromittiert ist, lassen sich Aufklärung, Löschaktionen und Zugangsdatenabfragen weitgehend automatisieren. Innerhalb weniger Minuten kann dadurch erheblicher Schaden entstehen.

Für Administratoren sollte der Vorfall deshalb vor allem ein Anlass sein, Maschinenidentitäten, Secrets und Azure Rollen zu überprüfen. Least Privilege, getrennt geschützte Backups, Resource Locks und eine konsequente Überwachung können den Schaden deutlich begrenzen. Moderne Cloud Sicherheit endet nicht bei Benutzerkonten, sondern muss jede Identität berücksichtigen, die auf Unternehmensressourcen zugreifen darf.