Microsoft Threat Intelligence beschreibt Storm-3168 als Aktivität rund um kompromittierte Service Principals in Azure. Der Microsoft Security Blog vom 25. September 2026 ordnet die Beobachtung JADEPUFFER zu und meldet Azure-zentrierte Lösch-, Aufklärungs- und Credential-Collection-Aktivität. Für KMU ist das relevant, sobald Anwendungen, Automationen oder Backups mit dauerhaft gültigen Geheimnissen arbeiten: Ein veröffentlichtes oder zu weit berechtigtes Service-Principal-Secret kann nach Microsofts Beschreibung weiter nutzbar bleiben, bis es widerrufen oder rotiert wurde.
Was Microsoft am 25. September 2026 meldet
Microsoft beobachtete zwei kompromittierte Service Principals in demselben Tenant. Ein Principal führte über etwa 15 Stunden und 30 Minuten mehr als 300 erfolgreiche Leseoperationen aus. Ein zweiter Principal enumerierte Ressourcen in zwei Subscriptions in fünf Sekunden, suchte Konfigurationsdaten und begann danach mit destruktiven Aktionen. Microsoft nennt Azure Storage Accounts, SQL-Datenbanken, Key Vaults, Function Apps, Recovery-Schutzmechanismen, Virtual Machines und App Services als betroffene Zieltypen.
Der Bericht ist kein allgemeiner Produktlaunch und enthält keinen künftigen Stichtag. Die konkrete Handlung besteht darin, exponierte Geheimnisse sofort als kompromittiert zu behandeln, Workload-Identitäten zu prüfen und kritische Azure-Ressourcen gegen Löschung und Missbrauch abzusichern.
Warum Service Principals ein KMU-Risiko sind
Service Principals werden häufig für Skripte, Integrationen, Backup-Werkzeuge, CI/CD-Pipelines oder Verwaltungsaufgaben genutzt. Sie melden sich nicht wie normale Benutzer an, besitzen aber oft weitreichende Rechte. Microsoft beschreibt im Storm-3168-Fall, dass ein Client-ID-, Client-Secret- und Tenant-ID-Satz zuvor in Klartext in einem öffentlichen GitHub-Issue sichtbar war. Das Issue wurde später bearbeitet, doch Microsoft betont: Entfernen oder Schwärzen der Stelle macht das Secret nicht ungültig.
- Öffentlich gewordene Secrets müssen widerrufen oder rotiert werden, nicht nur aus der Fundstelle entfernt.
- Rollen auf Subscription- oder Resource-Group-Ebene können destruktive Aktionen ermöglichen, wenn der Principal kompromittiert wird.
- Konfigurationsspeicher, Storage Keys und Key Vaults werden interessant, weil sie weitere Zugänge eröffnen können.
- Backup- und Recovery-Schutzmechanismen gehören in dieselbe Prüfung wie Produktionsressourcen.
Dringlichkeit: sofort prüfen statt Frist abwarten
Microsoft nennt bei Storm-3168 keine Deadline, sondern beobachtete eine schnelle Abfolge nach der Aufklärung. Die destruktive Sequenz dauerte laut Blog etwa sieben Minuten und umfasste mehr als 100 Löschversuche gegen Storage Accounts. Insgesamt versuchte der kompromittierte Principal innerhalb von 35 Minuten mehr als 150 destruktive oder credentialbezogene Operationen. Für kleinere Teams bedeutet das: Ein monatlicher Rechtecheck reicht nicht, wenn ein lang gültiges Secret bereits außerhalb der Umgebung liegt.
Die erste Prüfung sollte deshalb auf vorhandene Secrets, ungewöhnliche Anmelde- und ARM-Aktivität sowie breite Rollenvergaben zielen. Microsoft Entra ID und Microsoft Entra Workload ID liefern den Identitätsrahmen; Microsoft Defender und Defender for Cloud liefern Signale zu Ressourcen, Storage, Key Vault, App Service und Resource Manager.
Welche Schutzmaßnahmen Microsoft nennt
Microsofts Empfehlungen sind ungewöhnlich praktisch: Workload-Identitäten und Secrets schützen, Least Privilege durchsetzen, Recovery-Ressourcen absichern und passende Defender-for-Cloud-Pläne für kritische Workloads aktivieren. Microsoft Learn beschreibt Entra Workload ID als Dienst, um Identitäten für digitale Workloads wie Apps und Dienste zu verwalten und abzusichern. Die Azure-RBAC-Best-Practices empfehlen, nur den Zugriff zu vergeben, den Benutzer oder Sicherheitsprinzipale wirklich benötigen, und breite Rollen an breiten Scopes zu vermeiden.
Defender for Cloud ist laut Microsoft Learn eine Cloud-Native-Application-Protection-Platform mit CSPM- und Workload-Schutzfunktionen. Im Storm-3168-Kontext nennt Microsoft unter anderem Defender for Resource Manager, Storage, Key Vault, App Service und Databases als relevante Abdeckung.
Konkrete nächste Schritte für Administratoren
- Alle App-Registrierungen und Service Principals mit aktiven Client Secrets exportieren und nach Alter, Nutzung und Berechtigungsumfang sortieren.
- Öffentlich oder intern falsch abgelegte Secrets sofort widerrufen, rotieren und rückwirkend auf Verwendung untersuchen.
- Contributor-, Owner-, Storage- und SQL-Rollen für Service Principals auf Subscription- und Resource-Group-Ebene reduzieren.
- Resource Locks, Löschschutz und Backup-Schutz für kritische Storage-, Key-Vault-, Datenbank- und Recovery-Ressourcen prüfen.
- Defender-for-Cloud-Warnungen zu Resource Manager, Storage, Key Vault, App Service und Databases mit den betroffenen Identitäten korrelieren.
In einem Microsoft Security Assessment lässt sich daraus ein klarer Testfall ableiten: Welche Workload-Identitäten könnten heute produktive oder wiederherstellungsrelevante Ressourcen löschen, und würden entsprechende Aktivitäten rechtzeitig auffallen?
Offizielle Microsoft-Quellen
- Microsoft Security Blog: Storm-3168 and compromised service principals
- Microsoft Learn: Microsoft Entra Workload ID documentation
- Microsoft Learn: Microsoft Defender for Cloud overview
- Microsoft Learn: Best practices for Azure RBAC
Wenn Sie prüfen möchten, ob Ihre Workload-Identitäten, Secrets und Defender-Signale gegen solche Cloud-Angriffe ausreichend abgesichert sind, unterstützen wir bei einem fokussierten Review – sprechen Sie uns an.
Was bedeutet das für Ihre Umgebung?
Ordnen Sie das Thema im Kontext Ihrer Microsoft-365-Umgebung ein und legen Sie einen sinnvollen nächsten Schritt fest.
Sie sprechen direkt mit Sebastian Kerssen – seit 2014 im Microsoft-Umfeld, mit persönlicher Beratung und direktem Ansprechpartner.
