Azure-Abonnement kompromittiert? Leitfaden zur Reaktion

Kurz gesagt. Behandeln Sie die Frage „Ist unser Azure-Abonnement kompromittiert?“ als drei Fragen: Welche Identität hat gehandelt, was hat sie auf der Steuerungsebene getan (Activity Log) und welche Daten hat sie berührt (Key Vault, Storage und Flow-Logs). Exportieren Sie alles, bevor die Aufbewahrung zuschlägt – das Activity Log wird 90 Tage aufbewahrt. Suchen Sie zuerst nach einer kurzen Liste von Operationen: roleAssignments/write, elevateAccess/action, runCommand/action, listAccountSas/action, accessPolicies/write, diagnosticSettings/delete. Wenn Sie heute nur eines tun können, exportieren Sie das Activity Log jedes betroffenen Abonnements und laden Sie es in den Azure Forensics Analyzer, der in Ihrem Browser läuft.

Die meisten Azure-Vorfälle, die ich sehe, beginnen gleich: Jemand bemerkt eine Kostenspitze, eine Warnung von Defender for Cloud oder eine Rollenzuweisung, an deren Erstellung sich niemand erinnert. Die Versuchung ist groß, das Portal zu öffnen und herumzuklicken. Widerstehen Sie zehn Minuten lang. Klicken sichert keine Beweise, und die Portalansichten sind standardmäßig gefiltert. Dieser Leitfaden beschreibt die Reihenfolge, die ich einhalte.

Was „kompromittiert“ in Azure bedeutet

Ein Azure-Abonnement hat zwei Ebenen, und Angreifer nutzen beide.

Microsoft Learn ist bei dieser Trennung eindeutig: Das Activity Log erfasst Vorgänge der Steuerungsebene, während Ressourcenlogs die Datenebene abbilden und standardmäßig nicht erfasst werden. Wurde die Key Vault-Protokollierung nie aktiviert, kann Ihnen niemand sagen, welche Secrets gelesen wurden. Das ist die erste ehrliche Grenze jeder Azure-Untersuchung; der Artikel zu den Grenzen geht tiefer darauf ein.

Schritt 1: Sichern, bevor Sie untersuchen

Zwei Dinge zerstören Beweise in Azure: die Zeit und der Angreifer.

• Die Zeit. Azure bewahrt Activity-Log-Ereignisse 90 Tage auf und löscht sie dann. Hat der Einbruch vor 80 Tagen begonnen, bleiben Ihnen zehn.
• Der Angreifer. Wird eine Diagnoseeinstellung gelöscht, sendet die Ressource ab diesem Moment keine Logs mehr. Das gehört zu den ersten Handgriffen eines vorsichtigen Eindringlings (Defense Evasion in Azure).

Deshalb, vor allem anderen:

1. Exportieren Sie das Activity Log jedes betroffenen Abonnements für den verdächtigen Zeitraum plus mindestens eine Woche davor. Diese Woche ist die Referenz, die Normales von Auffälligem trennt.
2. Kopieren Sie die Container des Speicherkontos, in die Diagnoseeinstellungen schreiben: insights-activity-logs, insights-logs-auditevent, insights-logs-storageread, insights-logs-networksecuritygroupflowevent, insights-logs-flowlogflowevent.
3. Exportieren Sie Log Analytics-Tabellen, falls vorhanden: AzureActivity, AzureDiagnostics (Key Vault), StorageBlobLogs.
4. Exportieren Sie auch das mandantenweite Log (Directory Activity): elevateAccess landet dort, nicht im Log des Abonnements.

Die genauen Befehle – einschließlich des Standardwerts von az monitor activity-log list, der stillschweigend nur 50 Ereignisse liefert – finden Sie unter Azure Activity Log und Ressourcenlogs exportieren.

Schritt 2: Die entscheidenden Operationen finden

Das Activity Log eines aktiven Abonnements besteht überwiegend aus Bereitstellungen und Tag-Schreibvorgängen. Angriffsaktivität versteckt sich in einer Handvoll Operationsnamen. Auf diese stützen sich die Regeln des Analyzers, gruppiert nach dem Ziel des Angreifers:

Keine davon ist für sich genommen bösartig. Ein Plattformteam weist jede Woche Rollen zu. Verdächtig werden sie durch das Wer (ein Dienstprinzipal, der normalerweise eine Web-App bereitstellt), das Woher (eine IP, die im Referenzzeitraum nie auftauchte), das Wann (02:14 UTC an einem Sonntag) und das Was danach (ein Run Command drei Minuten später).

Das ist keine Theorie. Microsofts Analyse zur cloudbasierten Ransomware von Storm-0501 nennt elevateAccess/action, roleAssignments/write, listkeys/action und locks/delete unter den Operationen, die vor der Datenexfiltration und dem Löschen von Ressourcen verwendet wurden.

Schritt 3: Über die Identität pivotieren

Jedes Activity-Log-Ereignis enthält den Aufrufer und in den JSON-Exporten die Token-Claims: Objekt-ID, Anwendungs-ID und bei einer verwalteten Identität eine xms_mirid-Claim, die auf die zugehörige VM oder App verweist. Sobald Sie ein verdächtiges Ereignis gefunden haben, pivotieren Sie:

• Alle Ereignisse desselben Aufrufers, über alle Abonnements und das gesamte Aufbewahrungsfenster. Das erste Auftreten zählt mehr als das lauteste Ereignis.
• Alle Ereignisse von derselben IP-Adresse, unabhängig vom Aufrufer. Angreifer verwenden ihre Infrastruktur für mehrere gestohlene Identitäten.
• Dieselbe Identität in Key Vault- und Storage-Logs, wo sie als Objekt-ID oder bei SAS-Zugriffen als Token-Hash erscheint.
• Dieselbe IP in Flow-Logs, wo eine kompromittierte VM sie erneut kontaktiert.

Die Identität selbst – wie das Geheimnis eines Dienstprinzipals abgeflossen ist, wer wozu eingewilligt hat – ist eine Entra ID-Frage. Diese Untersuchung gehört ins Schwesterwerkzeug m365forensics.com, das Anmeldungen, Überwachungsprotokolle und App-Anmeldeinformationen abdeckt.

Schritt 4: In der richtigen Reihenfolge eindämmen

Eindämmung in Azure ist überwiegend Identitätsarbeit. Die Behebungs-Checkliste des Analyzers ordnet sie ungefähr so:

1. Anmeldeinformationen. Rotieren Sie Geheimnisse und Zertifikate der beteiligten Dienstprinzipale; widerrufen Sie die Sitzungen der Benutzer. Ein rotiertes Geheimnis macht bereits ausgestellte Zugriffstoken nicht ungültig – rechnen Sie mit einem kurzen Nachlauf an Aktivität.
2. Rollenzuweisungen. Entfernen Sie alle während des Vorfalls erstellten Zuweisungen und die User Access Administrator-Zuweisung im Stammbereich (/), falls elevateAccess verwendet wurde.
3. VMs. Isolieren Sie sie mit einer NSG, die alles verweigert, erstellen Sie Snapshots der Datenträger für die Forensik und bauen Sie sie aus einem vertrauenswürdigen Image neu auf. Eine VM, die das Skript eines Angreifers ausgeführt hat, wird durch Löschen des Skripts nicht „sauber“.
4. Secrets und Schlüssel. Rotieren Sie alles, was aus den betroffenen Tresoren gelesen wurde, sowie beide Speicherkontoschlüssel (damit werden Konto- und Dienst-SAS ungültig).
5. Protokollierung. Stellen Sie gelöschte Diagnoseeinstellungen und Defender-Pläne wieder her und schützen Sie sie mit einer Sperre oder Azure Policy.

Microsofts Übersicht über die Reaktion auf Vorfälle für Azure ist die offizielle Referenz für den Gesamtprozess.

Schritt 5: Schnell zu einem ersten Urteil kommen

Eine erste Triage sollte Minuten dauern, nicht eine Woche KQL. Der Azure Forensics Analyzer liest Activity-Log-Exporte (Portal-CSV, az CLI-/REST-JSON, Log Analytics, Export in ein Speicherkonto), Key Vault AuditEvent, StorageBlobLogs, NSG- und VNet-Flow-Logs sowie Warnungen von Defender for Cloud. Er wendet 35 dokumentierte Regeln an und liefert ein Urteil:

• Kompromittiert: mindestens zwei Befunde mit hohem Schweregrad oder einer mit kritischem.
• Verdächtig: mindestens ein mittlerer oder hoher Befund.
• Unauffällig: nichts oberhalb von „niedrig“ – was nur heißt, dass in den bereitgestellten Logs nichts gegriffen hat.

Alles läuft als WebAssembly in einem Web Worker: kein Upload. Die Schritt-für-Schritt-Anleitung zeigt, wie Sie Befunde, Zeitleiste und Entitäten-Pivot lesen, und der fiktive Fall Schritt für Schritt zeigt eine vollständige Kette mit synthetischen Daten.

FAQ

Was ist der erste Schritt, wenn ein Azure-Abonnement kompromittiert ist?

Die Logs sichern, bevor sie ablaufen (das Activity Log wird 90 Tage aufbewahrt), und dann eindämmen: Anmeldeinformationen der beteiligten Prinzipale rotieren, von ihnen erstellte Rollenzuweisungen entfernen und betroffene VMs isolieren. Die Untersuchung läuft parallel, nicht danach.

Zeigt das Activity Log, wer meine Key Vault-Secrets oder Blobs gelesen hat?

Nein. Das Activity Log erfasst Vorgänge der Steuerungsebene über Azure Resource Manager. Das Lesen eines Secrets oder der Download eines Blobs sind Vorgänge der Datenebene und stehen nur in den Ressourcenlogs von Key Vault und Storage – und nur, wenn vor dem Vorfall eine Diagnoseeinstellung aktiv war.

Wo untersuche ich, wie der Angreifer an die Anmeldeinformationen kam?

In Microsoft Entra ID: Anmeldeprotokolle, Überwachungsprotokolle, neue Anwendungsgeheimnisse und Einwilligungen. Azure-Ressourcenlogs zeigen, was die Identität mit ihrem Zugriff getan hat, nicht wie sie ihn erlangt hat.

Weiterführende Links

• Aktivitätsprotokoll in Azure Monitor – Aufbewahrung, Export, mandantenweite Ereignisse.
• Übersicht über die Reaktion auf Vorfälle für Azure – der Prozess aus Sicht von Microsoft.
• Azure Threat Research Matrix – Microsofts Katalog von Azure-Angriffstechniken.
• Storm-0501's evolving techniques lead to cloud-based ransomware – Microsoft Threat Intelligence (Englisch).

Verwandte Artikel

• Azure Activity Log und Ressourcenlogs exportieren
• Azure Activity Log Schritt für Schritt analysieren
• Ein Azure-Einbruch Schritt für Schritt (fiktiver Fall)