Cloudbasierte Ransomware in Microsoft-Umgebungen (Storm-0501)
Ransomware fühlt sich für viele noch nach befallenen Laptops, blinkenden Serverkonsolen und verschlüsselten Dateifreigaben an. Doch der Takt hat sich geändert. Der von Microsoft als Storm-0501 gefasste Akteur zeigt, wie Erpressung heute in Microsoft 365 und Microsoft Azure funktioniert: ohne klassische Payloads, stattdessen mit legitimen Cloud-Operationen. Die Angreifer verschaffen sich Identitäts- und Verwaltungsrechte, exfiltrieren große Datenmengen direkt aus Azure Storage, löschen Snapshots, Backups und ganze Storage Accounts oder verschlüsseln Daten mit eigens angelegten Key Vault-Schlüsseln. Die Lösegeldforderung landet am Ende ganz unaufgeregt in Microsoft Teams.
Microsoft Threat Intelligence
Dieses Vorgehen ist kein Randphänomen. Je mehr Organisationen hybride oder vollständig cloudbasierte Infrastrukturen betreiben, desto attraktiver werden Identitäten, Rollen und Verwaltungs-APIs als Angriffsfläche. Storm-0501 nutzt genau das aus: Die Übergänge zwischen Active Directory, Microsoft Entra ID, Azure-Ressourcen und den Sicherheitsgrenzen dazwischen.
Warum das für Microsoft-Umgebungen besonders relevant ist
Die klassische Endpoint-Sicht reicht in einer M365/Azure-Welt nicht mehr. Ein kompromittiertes Notebook ist lästig, ein kompromittiertes Global Administrator-Konto ist existenzbedrohend. In Microsoft-Tenant-Strukturen hängen Identitäten, Anwendungen und Daten eng zusammen: Entra ID autorisiert den Zugriff, Azure Resource Manager setzt die Befehle um, Storage und Compute beherbergen die Werte. Wer in dieser Kette nach oben gelangt, hat Hebelwirkung über alles darunter.
Storm-0501 illustriert das sehr konkret. Der Einstieg gelingt oft on-premises – beispielsweise über bereits erlangte Domain-Admin-Rechte. Über Entra Connect Sync (und dessen Directory Synchronization Account) verschiebt sich das Geschehen in die Cloud. Dort reicht ein einziges privilegiertes, schwach geschütztes Konto, um das Tor weit aufzumachen. In der Praxis sah das so aus: Ein nicht-menschliches, aus AD synchronisiertes Konto trug die Global Administrator-Rolle – ohne registrierte MFA. Nach einer Passwortänderung on-prem und der Synchronisierung nach Entra ID konnte die Gegenseite MFA selbst registrieren und war damit "policy-konform" handlungsfähig.
Ab diesem Moment greifen die Cloud-Spezifika: Mit elevateAccess verschaffen sich die Angreifer User Access Administrator auf allen Subscriptions, weisen sich anschließend Owner zu und operieren mit legitimen Azure-API-Operationen. Sichtbar wird das in Protokollen wie CloudAuditEvents und dem Azure Monitor Activity Log, wenn man sie denn zentral und vollständig auswertet.
Wie die Angriffskette in Microsoft 365/Azure aussieht
Der technische Ablauf liest sich weniger wie "Malware ausrollen" und mehr wie "Cloud administrieren - nur böswillig".
Zunächst analysieren die Angreifer in der On-Prem-Domäne, bewegen sich bevorzugt über schlecht überwachte Systeme und setzen Werkzeuge wie Evil-WinRM für Remote-Befehle ein. Ein DCSync liefert Hashes und damit die Option, weitere Konten zu übernehmen. Entscheidend ist der Sprung: Ein kompromittierter Entra Connect-Server dient als Brücke in den Tenant.
In Microsoft Entra ID beginnt die Ausweitung. Tools wie AzureHound kartieren Rollen, Gruppen, App-Registrierungen und Pfade zu höheren Privilegien. Schlägt Conditional Access erste Anmeldeversuche ab, wird so lange seitlich manövriert, bis sich eine Anmeldung von einem hybrid-joined Gerät realisieren lässt. Ist der Global Admin einmal interaktiv im Azure-Portal, baut Storm-0501 Persistenz auf, etwa über eine böswillig hinzugefügte Federated Domains. Mit AADInternals wird ein eigener Tenant samt Root-Zertifikat als vertrauenswürdig registriert. Ergebnis: Die Angreifer können SAML-Tokens ausstellen und sich als nahezu beliebiger Benutzer im Opfer-Tenant ausgeben, einschließlich seiner Entra-Rollen.
In Azure beginnt danach der eigentliche Schaden. Speicher-Konten werden so konfiguriert, dass sie aus dem Internet erreichbar sind. Über listKeys greifen die Angreifer die Zugangsschlüssel ab und kopieren Daten mit AzCopy ab. Anschließend löschen sie, was die Wiederherstellung erschweren soll: Storage Accounts, Snapshots, Restore Point Collections, Recovery Services-Container. Treffen sie auf Schutzmechanismen - Resource Locks oder Blob-Immutability -, versuchen sie, diese zu entfernen. Wo das nicht möglich ist, wird verschlüsselt: Ein neuer Key Vault wird angelegt, ein Customer-Managed Key erzeugt und über Encryption Scopes auf die verbleibenden Storage-Objekte gelegt. Wird der Schlüssel danach gelöscht, schützt in Azure üblicherweise die Soft-Delete/Purge-Protection, sofern sie aktiviert ist. Ohne diese Basismaßnahmen wäre die Datenlage an dieser Stelle oft irreversibel.
Der letzte Schritt ist unspektakulär und effektiv: Die Erpressung erfolgt über bekannte Kommunikationskanäle, etwa eine Nachricht in Microsoft Teams aus einem bereits kompromittierten Konto. Technisch ist das simpel, psychologisch wirkt es maximal glaubwürdig.
Was Organisationen konkret tun sollten
Die Gegenmaßnahmen lesen sich schnell als Checkbox-Liste, in der Praxis sind sie ein Programm. Entscheidend ist, sie in Microsoft-Umgebungen zusammenhängend zu denken.
Sichtbarkeit: Beginnen sollte man bei der Sichtbarkeit. Defender for Endpoint oder alternative Lösungen gehört auf alle Windows- und Linux-Systeme, auch auf Entra Connect Server. EDR im Blockmodus und Tamper Protection verhindern, dass Angreifer Schutzdienste gezielt abschalten. In der Cloud übernimmt Defender for Cloud die Überwachung von Resource Manager-Operationen, Defender for Storage erkennt verdächtige Zugriffe, und Defender for Key Vault meldet ungewöhnliche Schlüssel-Operationen. Diese Telemetrie muss im Defender-Portal (bzw. in Advanced Hunting) zusammengeführt werden, damit Korrelationen, vom riskanten Sign-in bis zur Storage-Löschung, sichtbar werden.
Identitätshygiene: MFA ist Pflicht, für alle, für Administratoren in phishing-resistenter Ausprägung. Privileged Konten sollten cloud-nativ sein, nicht mit AD synchronisiert, und mit least privilege betrieben werden. Privileged Identity Management (PIM) begrenzt die Zeit im Admin-Status. Für Directory Synchronization Accounts empfiehlt sich die aktuelle App-basierte Authentifizierung der Entra Connect-Version, kombiniert mit Conditional Access für Workload-Identitäten und einer CA-Policy, die den Zugriff der Sync-Konten auf definierte IP-Ranges einschränkt. Wichtig ist zudem, dass privilegierte Konten bereits registrierte MFA-Methoden besitzen, damit Angreifer keine eigene Methode ergänzen können.
Azure spezifisch: In Azure Storage sollten Immutability Policies gesetzt und wo möglich, locked sein. Private Endpoints und deaktivierte Public Network Access reduzieren Exfiltrationsoptionen dramatisch. Resource Locks auf Recovery-Ressourcen sind lästig im Alltag, aber Gold wert im Ernstfall. Azure Backup mit geo-redundanten Recovery Vaults schafft Wiederherstellungspunkte außerhalb der Primärsubscription. In Key Vault gehört Soft-Delete plus Purge-Protection zum Pflichtprogramm; nur so verpufft der Versuch, nachträglich verschlüsselte Daten durch Schlüssel-Löschung unzugänglich zu machen.
Azure Policies stellen Grundregeln sicher, etwa "kein anonymer Blob-Zugriff", "Public Access aus", "Defender for Storage aktiv". Azure Monitor und Log Analytics sammeln die entsprechenden Logs, CloudAuditEvents liefert die Control-Plane-Historie. Wer zusätzlich Microsoft Security Exposure Management nutzt, erkennt kritische Assets (z. B. besonders sensitive Storage-Konten) und Attack Paths, häufig die schnellste Möglichkeit, Prioritäten im Hardening zu setzen.
