Kurz gesagt. Exportieren Sie das Activity Log (plus Key Vault, Storage und Flow-Logs, falls vorhanden), öffnen Sie den Azure Forensics Analyzer, legen Sie die Dateien oder ein ZIP ab und lesen Sie in dieser Reihenfolge: Abdeckung → Urteil → Befunde → Zeitleiste → Entitäten → Behebung. Alles läuft lokal als WebAssembly in einem Web Worker; nichts verlässt den Browser. Planen Sie für einen ersten Durchgang bei einem typischen Abonnement 30 Minuten ein.

So gehe ich vor, wenn mir jemand einen Ordner mit Azure-Exporten gibt und fragt: „Wurden wir angegriffen?“ Das Werkzeug liefert eine schnelle erste Antwort; die folgenden Schritte dienen dazu, diese Antwort kritisch zu lesen.

Bevor Sie beginnen: was Sie laden

Der Analyzer liest diese Quellen und erkennt jedes Format automatisch:

Quelle	Akzeptierte Formate
Activity Log	`az` CLI-/REST-JSON, Export in ein Speicherkonto oder Event Hubs (`insights-activity-logs`, JSON Lines oder `{"records": […]}`), Log Analytics `AzureActivity` (CSV oder JSON), „Download as CSV“ aus dem Portal (nach bestem Bemühen)
Key Vault	`AuditEvent` aus dem Speicherexport oder `AzureDiagnostics`
Storage	`StorageRead` / `StorageWrite` / `StorageDelete` oder `StorageBlobLogs`
Netzwerk	NSG-Flow-Logs v1 und v2, VNet-Flow-Logs
Defender for Cloud	REST-Export `{"value": […]}` oder `SecurityAlert`

Einzelne Dateien, ganze Ordner (die resourceId=/…/PT1H.json-Bäume), ZIPs und .gz-Dateien funktionieren unverändert. Wenn Sie noch keine Exporte haben, finden Sie die Befehle unter Azure Activity Log und Ressourcenlogs exportieren.

Nehmen Sie mindestens eine Woche vor dem vermuteten Beginn mit. Mehrere Regeln sind „Erstauftreten“-Regeln, die in den ersten 72 Stunden der Daten lernen, was normal ist; ohne diesen Verlauf können sie nicht laufen.

Schritt 1: Dateien laden

Öffnen Sie den Analyzer. Ziehen Sie Dateien auf die Ablagefläche oder verwenden Sie Dateien auswählen / Ordner auswählen. ZIPs werden im Browser entpackt. Jede Datei wird in Blöcken von 4 MB gelesen und an den Rust-Analyzer gestreamt, sodass ein Export von mehreren Gigabyte nicht doppelt in den Speicher passen muss.

Um zuerst zu sehen, wie ein Ergebnis aussieht, klicken Sie auf Beispiel ausprobieren. Das lädt einen synthetischen Export eines fiktiven Unternehmens (Kestrel Freight), der auf dem Bildschirm als solcher gekennzeichnet ist. Der fiktive Fall Schritt für Schritt erklärt dieses Beispiel Befund für Befund.

Schritt 2: Die Abdeckung vor dem Urteil prüfen

Der Block Abdeckung ist das Wichtigste auf der Seite – und wird am häufigsten übersprungen. Er listet je Quelle (Activity Log, Key Vault, Storage, NSG-/VNet-Flow-Logs, Defender for Cloud) die Anzahl der Ereignisse und den Zeitraum oder „nicht bereitgestellt“.

Darunter listet das Werkzeug die Erkennungen, die nicht laufen konnten, mit Begründung:

Logquelle nicht bereitgestellt – zum Beispiel alle Key Vault-Regeln, wenn kein AuditEvent-Log geladen wurde;
benötigt mehr als 72 h Verlauf – Erstauftreten-Regeln bei einem zu kurzen Export.

Ein Urteil „Unauffällig“, bei dem Key Vault und Storage als „nicht bereitgestellt“ markiert sind, bedeutet „die Steuerungsebene wirkt unauffällig“; über Datenzugriffe sagt es nichts. Der Artikel zu den Grenzen vertieft das.

Sehen Sie sich auch den Reiter Dateien an: Jede übersprungene Datei wird begründet (leer, kein Log, Avro, Parquet, UTF-16, nicht lesbares ZIP), und Duplikate zwischen Exporten werden gezählt und zusammengeführt.

Schritt 3: Urteil und Befunde lesen

Das Urteil ist bewusst einfach und dokumentiert:

Urteil	Regel
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“ in den bereitgestellten Logs

Warum listet die Regel-IDs hinter dem Urteil. Jeder Befund zeigt dann:

Titel und Schweregrad der Regel sowie eine stabile Regel-ID (AZ-RBAC-003, AZ-VM-001 …), die Sie in einem Bericht zitieren können;
wie viele unterschiedliche Aktionen gegriffen haben, erstes und letztes Auftreten;
die beteiligten Prinzipale, IPs und Ressourcen;
Gruppen bei Schwellenwertregeln (zum Beispiel ein Aufrufer, der innerhalb einer Stunde 12 verschiedene Secrets liest);
Netzwerkflüsse bei Flow-Regeln;
MITRE ATT&CK-Techniken mit Link.

Lesen Sie die Belege jedes hohen Befunds. Eine Regel ist eine Heuristik: Ein Plattformteam, das Owner vergibt, oder ein Backup-Job, der Hunderte Blobs liest, kann greifen. Die Tabelle der Erkennungen auf der Werkzeugseite listet jede Regel, und die Regeldatei selbst dokumentiert die bekannten False Positives jeder Regel.

Schritt 4: Die Zeitleiste durchgehen

Der Reiter Zeitleiste listet jedes Ereignis hinter einem mittleren, hohen oder kritischen Befund in chronologischer Reihenfolge. Hier wird eine Angriffskette lesbar: Rollenzuweisung, dann Run Command, dann ein von außen verwendetes Token einer verwalteten Identität, dann gelesene Secrets, dann eine erzeugte SAS, dann gelöschte Protokollierung.

Klicken Sie ein Ereignis an, um die normalisierten Felder (Operation, Aufrufer, Aufrufertyp, Anwendungs-ID, Objekt-ID, IP, Ressource, User Agent, Korrelations-ID, Quelldatei) und den Originaldatensatz genau so zu sehen, wie er exportiert wurde. Wechseln Sie mit dem Umschalter zwischen UTC und Lokal; berichten Sie in UTC.

Die correlationId ist wichtig: Das Activity Log schreibt für einen Vorgang mehrere Ereignisse (Started, Accepted, Succeeded). Der Analyzer zählt unterschiedliche Aktionen, doch wenn Sie ein Ereignis in einem Bericht zitieren, nennen Sie auch die Korrelations-ID.

Schritt 5: Über Prinzipale, IPs und Ressourcen pivotieren

Der Reiter Entitäten ist die Pivot-Tabelle der Untersuchung:

Prinzipale: Benutzer, Dienstprinzipale, verwaltete Identitäten, SAS-Token (über einen Hash identifiziert) und anonyme Zugriffe, mit erstem und letztem Auftreten und Anzahl der Befunde.
IP-Adressen: öffentlich oder privat, mit gesendeten und empfangenen Summen aus Flow-Logs, sofern geladen.
Ressourcen: filterbar nach Key Vaults, Speicherkonten, VMs und Netzwerk.
Abonnements.

Klicken Sie auf eine beliebige Zeile, um die Tabelle Ereignisse darauf zu filtern. Die Frage an eine Angreifer-IP lautet: „Was hat sie sonst noch getan?“ Die Frage an eine kompromittierte Identität: „Wann hat sie begonnen, sich anders zu verhalten?“

Die Ereignistabelle unterstützt außerdem Freitextfilter (Operation, Prinzipal, IP, Ressource, Regel), Filter nach Quelle und Ergebnis sowie einen Schalter Nur markierte.

Schritt 6: Behebung und Export

Der Reiter Behebung macht aus den Befunden eine geordnete Checkliste: Anmeldeinformationen rotieren, Rollenzuweisungen entfernen, VMs isolieren, Key Vault-Secrets und Speicherschlüssel rotieren, Protokollierung und Defender-Pläne wiederherstellen, IPs sperren, die Identitätsseite in Entra ID untersuchen. Häkchen bleiben nur in der Seite gespeichert.

Für die Fallakte:

CSV exportiert die Ereignistabelle (mit Schutz gegen Formelinjektion in Tabellenkalkulationen);
JSON-Bericht exportiert das vollständige Ergebnis: Urteil, Befunde, Zeitleiste, Entitäten, Abdeckung.

Was das Werkzeug Ihnen nicht abnimmt

Es sieht nichts, was Sie nicht exportiert haben. Keine API-Aufrufe, kein Zugriff auf Ihren Mandanten.
Es analysiert keine Entra ID-Anmeldungen oder App-Anmeldeinformationen; das ist Aufgabe des Schwesterwerkzeugs m365forensics.com.
Es beweist keine Abwesenheit. Ein vorsichtiger Angreifer kann unter einem Schwellenwert bleiben.

Für den Prozess rund um das Werkzeug – was zuerst zu sichern ist, wie man eindämmt – beginnen Sie mit dem Leitfaden zur Reaktion.

Azure Activity Log Schritt für Schritt analysieren