Share
Beitragsbild zu Einblick in die Angriffskette: Angriffe auf Azure Blob Storage

Einblick in die Angriffskette: Angriffe auf Azure Blob Storage

24. Oktober 2025

Bedrohungsakteure zielen auf Azure Blob Storage, um Unternehmensrepositorys zu kompromittieren. Microsoft-Forscher identifizierten dabei SharkStealer, einen in Golang geschriebenen Infostealer, der über die Kommunikationstechnik EtherHiding herkömmliche Erkennungssysteme umgeht.

Azure Blob Storage ist ein attraktives Ziel, weil es große Mengen unstrukturierter Daten für unterschiedliche Workloads speichert – von KI- und HPC-Workloads über Analytik, Medien und Backups bis hin zu IoT-Daten. Diese Rolle macht Blob Storage zu einem potenziellen Angriffsvektor mit Auswirkungen auf Datenintegrität und Geschäftskontinuität. Angreifer suchen gezielt nach Umgebungen, die herunterladbare Medien hosten oder umfangreiche Datenrepositorys betreiben, und setzen die Skalierbarkeit von Blob Storage ein, um vielfältige Unternehmen zu treffen.

Microsoft hat mit der Secure Future Initiative (SFI) Sicherheitsprinzipien in die Plattform eingebaut; dennoch müssen Verteidiger grundlegende Sicherheitsrichtlinien befolgen und kundenspezifische Sicherheitsfunktionen nutzen, um mit sich wandelnden Bedrohungen Schritt zu halten. Microsoft Threat Intelligence aktualisiert im Einklang mit dem MITRE ATT&CK-Framework kontinuierlich die Bedrohungsmatrizen, um neue Taktiken gegen Cloud-Umgebungen abzubilden. Während frühere Arbeiten des Teams verstärkt Kubernetes und containerisierte Rechenebenen behandelten, richtet sich dieser Beitrag auf die Datenspeicherebene – speziell auf Azure Blob Storage.

Der Beitrag beschreibt typische Bedrohungen auf der Datenspeicherebene, skizziert relevante Phasen der Angriffskette für Blob Storage und verknüpft diese Risiken mit umsetzbaren Azure-Sicherheitskontrollen und Empfehlungen. Zudem werden Erkennungsmaßnahmen vorgestellt, die mit Microsoft Defender for Cloud und dem Defender for Storage-Plan helfen sollen, Angriffe einzudämmen und zu verhindern. Durch das Verständnis dieser Bedrohungen und gezielte Schutzmaßnahmen können Unternehmen kritische Workloads und Datenrepositorys besser gegen weiterentwickelte Angriffstaktiken absichern.

So funktioniert Azure Blob Storage

Azure Storage verarbeitet Exabytes an Blob-Daten aus zahlreichen Quellen. Blobs speichern alles von Checkpoint- und Modelldateien für KI bis hin zu Parquet-Datensätzen für Analysen. Sie sind in Containern organisiert, die als Gruppierungsmechanismus dienen; ein Speicherkonto kann beliebig viele Container und Blobs enthalten.

Blob Storage unterstützt zudem Szenarien wie HPC, Backup und Disaster Recovery – etwa das Sichern lokaler Ressourcen oder von SQL-Server-Daten auf IaaS-VMs. Azure Data Lake Storage bietet zusätzliche Optimierungen für Dateisystem- und Analyse-Workloads, etwa hierarchische Namespaces und schnelle atomare Operationen. Blob Storage kann auch öffentlich zugängliche Inhalte hosten, etwa statische Dateien – nicht alle Dateien sind jedoch öffentlich zugänglich.

Azure Storage folgt dem Shared-Responsibility-Modell mit Best Practices für Identitäts- und Zugriffsverwaltung, sichere Netzwerke, Datenschutz und kontinuierliche Überwachung. In Kombination mit cloudnativen Diensten wie Microsoft Entra ID und Defender for Cloud unterstützt es minimierte Berechtigungen über RBAC und feinere Kontrollen via ABAC. Daten werden während der Übertragung durch Netzwerkschutz (Netzwerksicherheitsperimeter, private Endpunkte/Private Link, virtuelle Netzwerke) und TLS verschlüsselt. Auf Serviceebene verschlüsselt Azure Storage alle Daten automatisch mit serverseitiger 256-Bit-AES-Verschlüsselung; diese Verschlüsselung ist obligatorisch. Optional kann eine zusätzliche 256-Bit-AES-Verschlüsselung auf Infrastrukturebene aktiviert werden.

Azure Storage ist in Azure Backup und Microsoft Defender integriert, bietet Schutz gegen Ransomware und Malware und unterstützt Datenschutzfunktionen wie Unveränderlichkeitseinstellungen, Soft Delete und Versionierung zur Wiederherstellung nach Lösch- oder Überschreibungsereignissen.

Ein Blick auf die Angriffskette

Um passende Kontrollen und Empfehlungen entlang der Angriffskette anzuwenden, betrachten wir die einzelnen Phasen.

Grafik Quelle: Microsoft

Aufklärung

Angreifer durchsuchen Blob Storage nach öffentlich zugänglichen Daten und Anmeldedaten, die später in der Angriffskette genutzt werden können. Übliche Taktiken sind DNS- und HTTP-Header-Probing, um gültige *.blob.core.windows.net-Subdomänen zu finden. Sprachmodelle werden inzwischen eingesetzt, um plausible Speicherkonten- oder Containernamen zu erzeugen und Brute-Force-Angriffe effektiver zu machen.

Tools wie Goblob sind auf GitHub verfügbar; Bedrohungsakteure nutzen zudem andere Tools wie QuickAZ, das Speicheraufzählung mit weiteren Azure-Aufklärungsfunktionen kombiniert. PowerShell-Scanner mit Permutationswörterbüchern ermöglichen stundenlange Brute-Force-Tests von Präfix- und Suffix-Kombinationen. Spezielle Indexer katalogisieren Zehntausende öffentlich zugänglicher Container.

Werden sensible Anmeldedaten—etwa Speicherkontoschlüssel, Shared Access Signatures (SAS) oder Microsoft Entra ID-Anmeldeinformationen—in Quellcode-Repositorys oder Konfigurationsdateien (inklusive Versionshistorien) gefunden, erleichtert das den Erstzugang. Speicherkontoschlüssel sind besonders kritisch, da sie vollen Lese-, Schreib- und Löschzugriff gewähren; damit können Angreifer Berechtigungen erweitern, seitliche Bewegungen durchführen oder direkt Daten exfiltrieren.

Ressourcenentwicklung: Angriffsszenarien rund um Azure Blob Storage

Angreifer nutzen Fehlkonfigurationen und mangelnde Identitätskontrollen, um bösartige Ressourcen in Azure Blob Storage zu platzieren und ihre Operationen zu unterstützen. Dazu zählt das Hosten gefälschter Anmeldeseiten – teils so gestaltet, dass SSL-Prüfungen allein keine eindeutige Erkennung erlauben – sowie das Ablegen ausführbarer Dateien oder makrofähiger Dokumente in Containern mit anonymem Zugriff oder schwachen/kompromittierten SAS-Tokens. Nutzer könnten solche Inhalte direkt von den Blob-URLs herunterladen.

Weil Blob Storage häufig Trainingsdaten für Machine Learning beherbergt, ist auch Datenvergiftung ein Risiko: Angreifer können falsch beschriftete oder manipulative Samples einfügen, um Modellvorhersagen zu verfälschen.

Erster Zugriff
Schon ein falsch konfigurierter Endpunkt kann sensible Informationen offenbaren. Über Blob-getriggerte Azure Functions, Event Grid oder Logic Apps lassen sich nachgelagerte Workflows auslösen oder kapern, wenn deren Authentifizierung schwach ist — mit der Folge, dass Automatisierungen missbraucht, Berechtigungen eskaliert oder laterale Bewegungen ermöglicht werden.

Persistenz
Angreifer versuchen, langfristigen Zugang zu sichern, indem sie Identitäts- und Zugriffskonfigurationen manipulieren. Taktiken reichen von Zuweisung privilegierter Rollen und Erzeugen weitreichender SAS-Tokens über das Anpassen von Container-Richtlinien bis hin zur Aktivierung von SFTP oder dem Missbrauch von Soft Delete zum Verstecken bösartiger Payloads. Tools wie AADInternals oder AzureHound werden häufig eingesetzt, um Hintertüren zu etablieren oder Eskalationspfade zu identifizieren.

Umgehung von Abwehrmaßnahmen
Zur Erkennungsevasion manipulieren Angreifer Netzwerk- und Protokollierungseinstellungen: Lockerung oder Löschung von Firewall-Regeln, Hinzufügen zu großzügiger IP- oder VNet-Regeln, Erstellen nicht autorisierter privater Endpunkte, Regionenverteilung von Anfragen oder das Deaktivieren der Diagnoseprotokollierung.

Zugriff auf Anmeldedaten
Anmeldedaten gelangen auf verschiedenen Wegen in die Hände von Angreifern: Extraktion von Tokens und Schlüsseln (z. B. via Entra-ID-APIs wie listKeys), Missbrauch der Persistenz der Cloud Shell (versteckte Blob-Container speichern Sitzungsdaten) oder Offenlegung durch Fehlkonfigurationen, unverschlüsselte Übertragungen oder in Code-Repositorys. Mit den erbeuteten Schlüsseln lassen sich identitätsbasierte Kontrollen umgehen und Datenzugriffe ermöglichen.

Entdeckung
Nach dem Zugriff kartieren Angreifer die Umgebung: Abonnements, Ressourcengruppen und Speicherkonten werden durchsucht, Container und Blobs gelistet, Metadaten und Konfigurationen wie Firewall-, Protokollierungs- und Unveränderlichkeitsrichtlinien geprüft. So lokalisieren sie sensible Daten und finden Schwachstellen, die eine Ausweitung des Angriffs erlauben.

Seitliche Bewegung
Durch das Hochladen manipulierten Contents in Quellcontainer lassen sich Event-getriggerte Funktionen oder Pipelines (Azure Functions, Logic Apps, Data Factory, Synapse) auslösen, die unter verwalteten Identitäten laufen. Schreibzugriff auf in Storage abgelegten Funktionscode ermöglicht das Ersetzen von Code und die Ausführung unter der Identität der Funktion — ein direkter Weg zu weiteren Ressourcen.

Erfassung
Falsch konfigurierte Container erlauben das massenhafte Auflisten und Herunterladen von Daten. Angreifer kopieren sensible Dateien in eigene Staging-Container oder nutzen StartCopy/SyncCopy/CopyBlob per AzCopy oder REST-API, um innerhalb von Azure zu bleiben und Erkennung zu erschweren; vor dem Exfiltrieren können sie Daten intern komprimieren oder verschlüsseln.

Befehl und Kontrolle
Komprimittierte Storage-Konten können als versteckte C2-Kanäle dienen: Malware fragt regelmäßig nach Blobs oder Metadaten, nutzt HEAD/GET-Anfragen oder liest Metadatenfelder, um Befehle zu erhalten oder Daten zurückzusenden, ohne Inhalte herunterzuladen. Auch Objekt-Replikation kann missbraucht werden, um Nutzdaten automatisch in vertrauenswürdige Zielcontainer zu verteilen und so Angriffe über Umgebungen hinweg zu verbreiten.

Exfiltration
Zur Datenabzug nutzen Angreifer native Tools wie Azure Storage Explorer oder AzCopy und profitieren von hoher Azure-Bandbreite sowie vertrauenswürdigen Domänen, um Entdeckung zu vermeiden. Beispielsweise kann das Aktivieren statischen Website-Hostings und das Kopieren sensibler Blobs in den $web-Container Daten öffentlich machen. Alternativ exfiltrieren Angreifer in eigene Abonnements oder betten Exfiltrationslogik in Funktionen, Logic Apps oder Runbooks ein, um Übertragungen zu verschleiern. Drittanbieter-Integrationen können ebenfalls als Angriffsvektoren dienen — etwa durch kompromittierte Übertragungssoftware wie MOVEit Transfer.

Auswirkungen
Mit hochprivilegierten Rollen, Speicherkontoschlüsseln oder weitreichenden SAS-Tokens können Angreifer massenhaft löschen, überschreiben, Daten neu hochladen oder erneut verschlüsseln, Metadaten ändern, Zugriffsebenen anpassen und rechtliche Aufbewahrungsfristen aufheben. Schon das reine Auslesen oder die Exfiltration sensibler Daten kann langfristige Schäden verursachen — etwa durch Spionage oder Reputationseinbußen.


Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky

Folgen Sie uns auf Mastodon