Datenexfiltration aus Azure Storage: SAS-Token und Blob-Logs
Datenexfiltration aus Azure Storage untersuchen: listAccountSas und listKeys im Activity Log, GetBlob-Salven in Blob-Logs, SAS-Hashes und was zu rotieren ist.
Kurz gesagt. Exfiltration aus Speicherkonten hinterlässt zwei Arten von Spuren. Im Activity Log: listKeys/action, listAccountSas/action, listServiceSas/action sowie Konfigurationsänderungen, die das Konto öffnen (allowBlobPublicAccess: true, Firewall mit defaultAction: Allow). In den Storage-Ressourcenlogs (StorageRead / StorageBlobLogs, nur wenn aktiviert): GetBlob-Anfragen mit IP des Aufrufers, Authentifizierungstyp, einem Hash der SAS bzw. des Tokens, dem Objektschlüssel und den zurückgegebenen Bytes. Eine clientseitig mit einem Kontoschlüssel signierte SAS wird bei der Erstellung nie protokolliert; Sie sehen sie erst, wenn sie verwendet wird. Das Rotieren beider Kontoschlüssel widerruft Konto- und Dienst-SAS.
Im Speicherkonto liegen die Daten. Nach einer Cloud-Kompromittierung lautet die Frage fast immer: „Was haben sie mitgenommen?“ Für Blob Storage lässt sie sich beantworten – vorausgesetzt, die richtige Diagnoseeinstellung existierte.
Wie Angreifer an die Daten kommen
| Weg | Spur auf der Steuerungsebene (Activity Log) | Spur auf der Datenebene (Storage-Log) |
|---|---|---|
| Kontoschlüssel lesen und offline eigene SAS signieren | Microsoft.Storage/storageAccounts/listKeys/action | GetBlob mit Authentifizierung SAS oder AccountKey |
| Azure Resource Manager eine Konto- oder Dienst-SAS erzeugen lassen | listAccountSas/action / listServiceSas/action | GetBlob mit SAS-Authentifizierung, statusText SASSuccess |
| Eine Entra-Identität mit Datenrolle nutzen (Storage Blob Data Reader …) | Eventuell vorher ein roleAssignments/write | GetBlob mit OAuth, Objekt-ID des Anfragenden |
| Einen Container öffentlich machen | storageAccounts/write oder containers/write mit öffentlichem Zugriff | GetBlob mit Anonymous |
| Die Speicher-Firewall öffnen | storageAccounts/write mit defaultAction: Allow oder aktiviertem öffentlichem Netzwerkzugriff | Anfragen von IPs, die vorher blockiert waren |
MITRE ATT&CK führt die Sammlung als T1530 Data from Cloud Storage. Storm-0501 nutzte laut Microsoft Threat Intelligence listkeys/action und exfiltrierte mit AzCopy, bevor massenhaft Speicherkonten gelöscht wurden.
Das SAS-Problem: Die Erstellung ist unsichtbar
Eine Shared Access Signature (SAS) ist eine signierte URL. Microsofts Dokumentation ist unmissverständlich: Die Generierung von SAS-Token lässt sich nicht überwachen, und Azure Storage verfolgt SAS-Token in keiner Weise (SAS-Übersicht). Eine lokal mit einem Kontoschlüssel signierte SAS erzeugt überhaupt kein Ereignis. Sichtbar ist:
listKeys/action– jemand hat die Schlüssel abgerufen (und konnte offline beliebig viele SAS signieren).listAccountSas/action/listServiceSas/action– jemand hat ARM eine SAS signieren lassen. Der Anforderungstext zeigt angeforderte Dienste, Berechtigungen, Start und Ablauf.- Jede Verwendung einer SAS in den Storage-Ressourcenlogs, sofern aktiviert.
Microsofts Empfehlung, die Autorisierung mit gemeinsam verwendetem Schlüssel (Shared Key) auf Konten zu unterbinden, die sie nicht brauchen, beseitigt die ganze Kategorie: Ohne Shared Key funktionieren Konto- und Dienst-SAS nicht mehr.
StorageBlobLogs lesen
Die Referenz zur Überwachung von Blob Storage dokumentiert die Felder. Für Exfiltration zählen:
| Feld (Speicherexport) | Beispiel | Warum |
|---|---|---|
operationName | GetBlob, ListBlobs, PutBlob, DeleteBlob | Was passiert ist |
callerIpAddress | 203.0.113.66:51234 | Von wo (achten Sie auf den Port als Suffix) |
identity.type | SAS, AccountKey, OAuth, Anonymous | Wie die Anfrage autorisiert wurde |
identity.tokenHash | key1(…),SasSignature(…) | Welcher Schlüssel die SAS signiert hat, plus SHA-256 der SAS selbst |
identity.requester.objectId | GUID | Die Entra-Identität bei OAuth |
properties.objectKey | /account/container/blob | Welcher Blob |
properties.responseBodySize | Bytes | Wie viel abgeflossen ist |
properties.userAgentHeader | AzCopy/10.x … | Welches Werkzeug |
statusCode / statusText | 200 / SASSuccess | Erfolg oder Fehlschlag |
Der Hash SasSignature(…) ist Ihr Pivot: Alle Anfragen mit demselben Hash nutzten dasselbe SAS-Token, egal wer es besaß. Der Analyzer verwendet ihn als Prinzipal für SAS-Zugriffe (angezeigt als sas:<Hash-Präfix>), sodass eine abgeflossene SAS als eine einzige Entität mit ihren IPs und der Bytesumme erscheint.
Storage-Logs sind umfangreich. Der Analyzer hält Routine-Lesezugriffe aus der Ereignistabelle heraus, zählt und bewertet aber jeden einzelnen.
Was der Analyzer meldet
| Regel | Erkennt | Stufe |
|---|---|---|
AZ-ST-001 | Konto- oder Dienst-SAS über ARM erzeugt (listAccountSas, listServiceSas) | Hoch |
AZ-ST-002 | Kontoschlüssel aufgelistet oder neu generiert | Niedrig |
AZ-ST-003 | Anonymer Blob-Zugriff auf dem Konto oder einem Container aktiviert | Hoch |
AZ-ST-004 | Speicher-Firewall für alle Netzwerke geöffnet | Mittel |
AZ-ST-005 | Massendownload: mindestens 50 verschiedene Blobs, von derselben Identität und IP innerhalb von 60 Minuten gelesen, mit Bytesumme | Hoch |
AZ-ST-006 | Anonyme Blob-Lesezugriffe | Mittel |
AZ-VM-005 | Datenträger oder Snapshot per SAS-URL exportiert | Hoch |
AZ-ST-002 ist absichtlich niedrig: Der Speicherbrowser im Portal, Function Apps und Backup-Werkzeuge listen ständig Schlüssel auf. Interessant wird es neben anderen Befunden.
Das Ausmaß bestimmen
Die Meldung einer Datenschutzverletzung braucht Fakten, nicht „der Angreifer hatte Zugriff auf das Konto“. Bauen Sie sie aus den Logs auf:
- Listen Sie die gelesenen Blobs des verdächtigen Prinzipals / SAS-Hashes / der IP auf: Objektschlüssel, Größen, Zeitstempel. Der Azure Forensics Analyzer gruppiert sie nach Identität, IP und Konto, mit Bytesumme.
- Trennen Sie Lesen und Auflisten.
ListBlobsverrät Namen,GetBlobInhalte. - Prüfen Sie Teilzugriffe. Ein Feld
downloadRangebedeutet, dass nur ein Teil des Blobs übertragen wurde. - Prüfen Sie Schreib- und Löschvorgänge (
StorageWrite,StorageDelete): Ransomware-Akteure löschen nach dem Kopieren. - Prüfen Sie die anderen Dienste. Blob-Logs decken weder Files noch Queues noch Tables ab; jeder Dienst hat eigene Logkategorien.
Im fiktiven Beispiel der Website liest etwa eine SAS von einer IP aus 330 verschiedene Backup-Blobs in 18 Minuten, insgesamt rund 48,6 GB. Genau diese Zahl, pro Container, brauchen Rechtsabteilungen.
Behebung
- Rotieren Sie beide Speicherkontoschlüssel. Microsoft dokumentiert, dass Konto- und Dienst-SAS mit dem Kontoschlüssel signiert werden; eine Neugenerierung macht sie also ungültig. SAS für die Benutzerdelegierung widerrufen Sie, indem Sie die Benutzerdelegierungsschlüssel widerrufen.
- Deaktivieren Sie anonymen Zugriff und stellen Sie die Firewall wieder her (Standardaktion Deny, private Endpunkte).
- Erwägen Sie, die Shared Key-Autorisierung zu unterbinden.
- Aktivieren Sie jetzt
StorageRead/StorageWrite/StorageDeleteauf dem Blob-Dienst sensibler Konten. - Ermitteln Sie, welche Daten gelesen wurden, für Meldepflichten (etwa die 72-Stunden-Meldung an die Aufsichtsbehörde nach DSGVO, Artikel 33).