Ein Azure-Einbruch Schritt für Schritt (fiktiver Fall)
Ein fiktiver Azure-Einbruch von Anfang bis Ende: abgeflossenes Geheimnis, Selbstzuweisung, Run Command, gestohlenes Token, Key Vault- und Blob-Diebstahl.
Kurz gesagt. Dieser Fall ist fiktiv. Kestrel Freight gibt es nicht; Mandant, Identitäten und IP-Adressen (Dokumentationsbereiche nach RFC 5737) sind erfunden, und die Logs wurden in den echten Azure-Exportformaten für die Schaltfläche Beispiel ausprobieren des Analyzers erzeugt. In 41 Minuten an einem Sonntagabend weist sich ein CI/CD-Dienstprinzipal mit abgeflossenem Geheimnis Contributor zu, führt ein Skript auf einer VM aus, verwendet das Token der verwalteten Identität der VM wieder, trägt sich in die Zugriffsrichtlinie eines Key Vault ein, liest alle 12 Secrets, erzeugt eine Konto-SAS, lädt 330 Datenbank-Backups herunter (rund 48,6 GB) und löscht dann die Diagnoseeinstellung des Tresors und den Activity-Log-Export. Der Analyzer liefert Kompromittiert mit 11 Befunden hohen Schweregrads.
Echte Vorfälle sind unordentlich, lückenhaft und vertraulich. Ein synthetischer Fall erlaubt es, jeden Schritt mit den Belegen vor Augen zu zeigen. Laden Sie ihn selbst: Öffnen Sie den Azure Forensics Analyzer und klicken Sie auf Beispiel ausprobieren. Die Seite blendet einen Hinweis ein, dass es sich um das fiktive Beispiel handelt.
Die Ausgangslage
Kestrel Freight (fiktiv) betreibt ein Webportal auf vm-app-01 in rg-prod-app. Die VM hat eine systemseitig zugewiesene verwaltete Identität, die stündlich ihre Datenbank-Verbindungszeichenfolge aus dem Key Vault kv-kestrel-prod und ihre Einstellungen aus dem Speicherkonto stkestrelbackups liest, in das auch die nächtlichen Datenbank-Backups geschrieben werden. Ein CI/CD-Dienstprinzipal, sp-gh-deploy, stellt das Portal jeden Morgen von zwei Runner-IPs aus bereit. Aus Bequemlichkeit überprivilegiert, hat er User Access Administrator.
Der Export umfasst den 2026-09-07 bis 2026-09-14: eine Woche normaler Aktivität (der Lernzeitraum), dann den Vorfall. Er enthält:
| Datei / Ordner | Quelle | Format |
|---|---|---|
insights-activity-logs/…/PT1H.json | Activity Log | Speicherexport, JSON Lines |
activity-log-az-cli.json | Activity Log, Tag des Vorfalls | az monitor activity-log list (REST-Schema) |
insights-logs-auditevent/… | Key Vault AuditEvent | JSON Lines |
insights-logs-storageread/…, …storagewrite/… | Blob-Logs | JSON Lines |
insights-logs-flowlogflowevent/… | VNet-Flow-Logs | {"records": […]} |
insights-logs-networksecuritygroupflowevent/… | NSG-Flow-Logs v2 | {"records": […]} |
defender-alerts.json | Defender for Cloud | REST {"value": […]} |
Speicher- und CLI-Export überschneiden sich am Tag des Vorfalls: Der Analyzer führt 11 doppelte Ereignisse zusammen.
Zuerst die Abdeckung
Alle fünf Quellen sind vorhanden. Das Activity Log hat 99 Ereignisse, Key Vault 186, Storage 509, Flows 88, Defender 1. Der Lernzeitraum reicht aus, also laufen die Erstauftreten-Regeln. Gut: Ein Urteil auf diesen Daten ist für Steuerungs- und Datenebene aussagekräftig.
Die Zeitleiste, Minute für Minute (UTC, 2026-09-14)
| Zeit | Ereignis | Quelle | Befund(e) |
|---|---|---|---|
| 02:14:05 | sp-gh-deploy ruft ARM von 203.0.113.66 auf – nie zuvor gesehen – und weist sich selbst Contributor auf dem Abonnement zu | Activity Log | AZ-ID-001, AZ-RBAC-002, AZ-RBAC-003 |
| 02:19:40 | runCommand/action auf vm-app-01, derselbe Prinzipal, dieselbe IP | Activity Log | AZ-VM-001 |
| 02:20:05 | VM 10.10.1.4 verbindet sich mit 203.0.113.66:80 (812 B gesendet, 46.338 B empfangen), dann :443 | VNet-Flow-Log | AZ-NET-004 |
| 02:22:10 | Die verwaltete Identität der VM liest db-conn-string von 203.0.113.66 mit curl/8.5.0 | Key Vault | AZ-ID-002 |
| 02:23:30 | Der Prinzipal schreibt die Zugriffsrichtlinie des Tresors (Secrets get / list für sich selbst) | Activity Log + Key Vault | AZ-KV-003 |
| 02:24:10–02:25:14 | SecretList, dann 12 verschiedene SecretGet durch den Prinzipal, Python-SDK | Key Vault | AZ-KV-001, AZ-KV-002 |
| 02:25:03 | Defender for Cloud-Warnung zur VM (Erzeugungszeit; die Startzeit der Warnung ist 02:21) | Defender | AZ-DEF-001 |
| 02:31:02 | listAccountSas/action auf stkestrelbackups: Blob, Lesen + Auflisten, 7 Tage gültig | Activity Log | AZ-ST-001 |
| 02:33:00–02:51:29 | 330 verschiedene Backup-Blobs mit dieser SAS von 203.0.113.66 heruntergeladen, AzCopy-User-Agent, ~48,6 GB | Storage | AZ-ST-005 |
| 02:55:12 | Diagnoseeinstellung kv-audit-to-storage des Key Vault gelöscht | Activity Log | AZ-DE-001 |
| 02:55:40 | Diagnoseeinstellung export-activity-to-storage des Abonnements gelöscht | Activity Log (nur CLI-Export) | AZ-DE-002 |
Einige Punkte verdienen Aufmerksamkeit, weil sie sich auf echte Fälle übertragen lassen.
Das erste Ereignis ist die Selbstzuweisung, nicht die Anmeldung. Das Activity Log beginnt dort, wo der Angreifer ARM zum ersten Mal berührt. Wie das Geheimnis des Prinzipals abgeflossen ist, ist eine Entra ID-Frage (Anmeldungen von Dienstprinzipalen, Änderungen an Anmeldeinformationen) für m365forensics.com.
Das Token der verwalteten Identität taucht zwei Minuten nach dem Run Command auf. Das Skript hat den Instance Metadata Service abgefragt und das Token nach außen geschickt. Die einzige sichtbare Spur ist dieselbe Objekt-ID, über ihre xms_mirid-Claim an vm-app-01 gebunden, die Key Vault von der Angreifer-IP statt von der 10.10.1.4 der VM aufruft. Das ist AZ-ID-002, erklärt unter Missbrauch verwalteter Identitäten.
Die Ausweitung über die Zugriffsrichtlinie braucht keine zusätzliche Rolle. Contributor genügte, um eine Zugriffsrichtlinie hinzuzufügen. Siehe Key Vault-Audit-Logs.
Die SAS ist der Prinzipal des Downloads. Die 330 GetBlob-Anfragen tragen weder Benutzer noch App-ID, nur SAS-Authentifizierung und den Hash der SAS-Signatur. Der Analyzer zeigt sie als einen einzigen sas:…-Prinzipal mit einer IP und einer Bytesumme (Exfiltration aus Storage).
Der Activity-Log-Export stirbt um 02:55:40, das Activity Log nicht. Das in den Speicher exportierte Activity Log enthält nach 02:55:40 nichts mehr. Die Löschung des Exports selbst ist nur sichtbar, weil der Ermittler zusätzlich az monitor activity-log list ausgeführt hat, das Azures eigene 90-Tage-Kopie liest (Defense Evasion).
Ein ehrlicher Vorbehalt zum Beispiel: Sein Run-Command-Ereignis enthält den Anforderungstext mit dem Skript. Echte Activity-Log-Einträge zu Run Command enthalten den Skriptinhalt in der Regel nicht, wie Mandiants Recherche zeigt; Sie müssten ihn von der VM sichern (Run Command-Angriffe).
Das Urteil
Elf Befunde mit hohem Schweregrad (AZ-RBAC-002, AZ-RBAC-003, AZ-VM-001, AZ-NET-004, AZ-ID-002, AZ-KV-001, AZ-KV-002, AZ-ST-001, AZ-ST-005, AZ-DE-001, AZ-DE-002) und drei mittlere (AZ-ID-001, AZ-KV-003, AZ-DEF-001): Kompromittiert. Dazu kommt ein niedriger Befund aus der Lernwoche: Die Plattform-Administratorin listet am 2026-09-09 die Schlüssel des Speicherkontos auf (AZ-ST-002). Das ist legitim, und das Urteil ignoriert es – eine nützliche Erinnerung daran, dass niedrige Befunde Kontext sind, keine Anschuldigungen.
Die Entitätenansicht
Ein Pivot auf 203.0.113.66 im Reiter Entitäten bündelt alle Ereignisse dieser Adresse: die ARM-Aufrufe des Prinzipals, den Key Vault-Zugriff der verwalteten Identität, die Secret-Zugriffe des Prinzipals und die SAS-Downloads. Die Zeile der IP enthält außerdem die Flow-Summen aus den VNet-Flow-Logs. Dieser eine Filter ist der Vorfall.
Ein Pivot auf die Objekt-ID des Prinzipals zeigt den Kontrast zu seiner Referenz: eine Woche täglicher Bereitstellungen um 10:00 von zwei Runner-IPs, dann eine 41-minütige Salve von einer neuen IP mit Aktionen, die er nie zuvor ausgeführt hat.
Die erzeugte Behebungs-Checkliste
Der Reiter Behebung ordnet die Schritte anhand der Befunde:
- Während des Vorfalls erstellte Rollenzuweisungen entfernen; prüfen, wer Owner / User Access Administrator hat.
- Anmeldeinformationen des Prinzipals rotieren und Sitzungen widerrufen; die Identitätsseite in Entra ID untersuchen.
vm-app-01isolieren, Snapshots der Datenträger erstellen, neu aufbauen; Erweiterungen und Run-Command-Verlauf prüfen.- 203.0.113.66 sperren und anderswo danach suchen.
- Alle 12 aus
kv-kestrel-prodgelesenen Secrets rotieren; den Tresor auf Azure RBAC umstellen; die bösartige Zugriffsrichtlinie entfernen. - Beide Speicherkontoschlüssel rotieren (damit ist die SAS ungültig); genau ermitteln, welche Backups abgeflossen sind, für die Meldung.
- Die gelöschten Diagnoseeinstellungen wiederherstellen und mit Azure Policy schützen.
- Die Defender-Warnung untersuchen.
Was dieser Fall nicht zeigt
- Den Erstzugriff. Der Abfluss des Geheimnisses liegt außerhalb dieser Logs.
- Was das Skript auf der VM getan hat, abgesehen von den Netzwerkflüssen und der Token-Nutzung. Dafür braucht es den Datenträger.
- Irgendetwas nach 02:55:12 in Key Vault. Die Protokollierung des Tresors ist ab diesem Moment weg; wäre der Angreifer um 03:10 zurückgekommen, würde das Key Vault-Log es nicht zeigen.
Für den Prozess rund um einen solchen Fall beginnen Sie mit dem Leitfaden zur Reaktion; für das Werkzeug selbst mit der Schritt-für-Schritt-Anleitung.