Azure Blob Storage est devenu un actif critique dans beaucoup d’architectures : sauvegardes, data lakes, datasets IA, médias, ingestion IoT, HPC…
Et c’est précisément parce qu’il concentre beaucoup de données non structurées et qu’il peut être exposé à Internet, il constitue une cible de choix pour les attaquants.
Le lien vers l’article sur le blog Microsoft : Inside the attack chain: Threat activity targeting Azure Blob Storage | Microsoft Security Blog
Une chaîne d’attaque sur un Blob Storage peut être décomposée de la sorte :
1) Reconnaissance : “trouver” le storage avant de le compromettre
La reconnaissance sur Blob Storage a une signature particulière : l’attaquant cherche des noms valides (storage accounts, containers) et des surfaces exposées. Via des approches comme le probing DNS et l’analyse d’en‑têtes HTTP pour identifier des sous‑domaines *.blob.core.windows.net qui répondent.
Le Brut Force est facilité par des dictionnaires de préfixes/suffixes, des scripts de permutations, et même des outils d’énumération publiés sur GitHub (ex : outils de “blob hunting” / reconnaissance Azure) ainsi que des modèles de langage pour générer des noms “plausibles” (donc augmenter le taux de réussite du brute‑force).
Note : la reconnaissance ne vise pas seulement les endpoints ; elle vise aussi les secrets (SAS, keys, identités Entra) qui peuvent traîner dans des dépôts de code, fichiers de config ou historiques.
2) Resource Development : détourner Blob Storage comme infrastructure d’attaque
Une fois des configurations repérées, le Blob Storage peut devenir un support opérationnel pour l’attaquant.
Par exemple, dans le cas de pages de phishing : l’attaquant peut héberger des pages d’authentification usurpées dans le Blob Storage, ce qui rend l’inspection “superficielle” (ex : certificat TLS valide) moins discriminante pour la victime.
Autre variante : le dépôt de binaires, documents macro‑enabled ou contenus malveillants dans des containers accessibles anonymement ou protégés par des SAS faibles ou compromises, afin de pousser des téléchargements “propres” via des URLs Azure.
Enfin, une menace très actuelle avec l’IA : le Blob Storage héberge souvent des datasets ML ainsi les attaquants peuvent chercher à empoisonner les données (injection d’échantillons mal étiquetés ou malveillants) pour biaiser un modèle.
3) Initial Access : quand l’exposition “data plane” ouvre la porte “control plane”
Sur le Blob Storage, un “simple” point de connexion mal configuré peut suffire : un container public, un SAS trop permissif, une clé de compte compromise, ou une automatisation mal sécurisée. Il existe aussi des scénario orientés “cloud-native” tels que des workflows en aval (Azure Functions, Logic Apps, Event Grid).
4) Persistence : survivre aux rotations de clés et aux remédiations évidentes
Une fois un accès obtenu, l’attaquant cherche un ancrage durable via des leviers typiques : attribuer des rôles (built‑in ou custom) à des identités contrôlées, générer des SAS à droits larges et expiration longue, changer des politiques d’accès au niveau container, activer SFTP, ou détourner des mécanismes comme le soft delete pour “cacher” des payloads (upload → delete → restore).
On retrouve ici une logique déjà bien documentée sur les intrusions identité‑centrées : la persistance moderne vise souvent le control plane (config / rôles / accès), pas seulement un malware sur VM.
5) Defense evasion : réduire la visibilité en touchant réseau et logs
L’évasion passe souvent par l’infrastructure : élargir des plages IP autorisées, manipuler les règles de firewall/VNet, créer des private endpoints non autorisés, répartir les requêtes, ou désactiver / réduire la journalisation.
Rappel sur le principe du forensic readiness : si les logs ne sont pas activés “avant”, l’investigation se fait à l’aveugle.
6) Credential Access : voler les clés, les tokens… et exploiter Cloud Shell
Le cœur du problème du Blob Storage, c’est que les modes d’accès sont multiples : RBAC/OAuth via Entra, SAS, account keys, voire anonymous access.
Il est donc possible, avec des privilèges suffisants, d’appeller des API de management pour extraire les clés (ex : opération type listKeys) et obtenir un accès data‑plane très puissant.
Autre point intéressant : Azure Cloud Shell stocke des artefacts de session dans un container blob “caché” ; un attaquant ayant accès peut tenter d’y récupérer historique/credentials/configs.
7) Discovery & Lateral Movement : pivoter via événements, pipelines et identités managées
Après entrée, l’attaquant cartographie. Il fait l’inventaire des storage accounts, le listing containers/blobs, la lecture de métadonnées, l’observation des règles firewall, des immutability policies, des backups, etc.
Le mouvement latéral est souvent “as a service” : des blobs peuvent déclencher des Functions/Logic Apps sous managed identity ; si l’attaquant contrôle l’input et qu’un Event Grid subscription est en place, il peut tenter d’exécuter du code ou d’influencer des services en aval.
Même idée sur des pipelines type Data Factory / Synapse : si l’attaquant peut modifier la data source, il peut influencer des traitements exécutés avec des identités privilégiées.
8) Collection, C2, Exfiltration : AzCopy, Storage Explorer, $web… et “covert transport”
Sur le Blob Storage, la collecte/exfiltration peut se faire avec des outils légitimes (AzCopy, Storage Explorer, REST API), donc avec un trafic “banal” et des domaines Microsoft
Exemple d’un scénario particulièrement piégeux : activer l’hébergement de site statique et copier des données dans le container $web pour les rendre accessibles publiquement.
Point très important : même si vous désactivez l’anonymous access au niveau compte, $web reste publiquement accessible dans ce mode d’hébergement, ce qui en fait un vecteur d’exfiltration “déguisé”.
Côté “command & control”, le Blob Storage peut aussi servir de canal : par exemple un malware qui “poll” des blobs/metadata, récupère des commandes, renvoie des données via metadata/PUT, ou exploite des politiques de réplication pour propager du contenu (logique supply‑chain).
9) Impact : suppression de masse, corruption, chiffrement cloud… sans malware classique
Le risque final n’est pas seulement la fuite : c’est aussi la destruction et la corruption : avec des impacts comme DeleteBlob/DeleteContainer, overwrite, modification de métadonnées, suppression de legal holds, et plus largement l’atteinte à l’intégrité/continuité.
L’article sur Storm‑0501 illustre très bien l’évolution : des campagnes ransomware deviennent “cloud‑based”, misant sur l’exfiltration rapide, la destruction de données/backups, et l’extorsion, sans dépendre d’un chiffrement malware traditionnel sur endpoints. Dans ce cas documenté, l’attaquant a ciblé des storage accounts, a volé des clés via des opérations Azure, a exfiltré avec AzCopy, puis a massivement supprimé ressources et protections (locks, immutability), et a même utilisé des mécanismes cloud de chiffrement (Key Vault + encryption scopes) pour augmenter l’impact.
Le lien vers l’article sur le blog Microsoft : Storm-0501’s evolving techniques lead to cloud-based ransomware | Microsoft Security Blog
Contre‑mesures : relier chaque étape à des contrôles concrets (et mesurables)
A) “Security baseline” + Zero Trust sur Storage
Microsoft recommande explicitement d’appliquer des principes Zero Trust à Azure Storage et de s’appuyer sur les bonnes pratiques identité/réseau/monitoring : la sécurité dépend fortement de l’intégrité des comptes privilégiés administrant ces systèmes.
B) Identité & accès : RBAC/ABAC, moindre privilège, éviter les secrets “longue durée”
Azure Storage s’intègre à Entra pour du least privilege via RBAC et des contrôles plus fins (ABAC), ce qui limite l’impact d’un secret compromis. Dans les scénarios d’intrusion cloud, Microsoft montre comment une compromission AD/Entra peut être le point de bascule vers la prise de contrôle du plan de contrôle Azure.
Il faut aussi prendre en compte l’essor des techniques de phishing modernes (dont AiTM) ainsi que l’intérêt des solutions phishing‑resistant et passwordless (ex : passkeys) pour réduire l’acquisition d’identités cloud.
Cf article de Microsoft : Se défendre contre les attaques évoluées sur les identités : Defending against evolving identity attack techniques | Microsoft Security Blog
C) Réseau : Private Link / endpoints privés + périmètres réseau
Il est important de s’appuyer sur des protections réseau : private endpoint/Private Link, VNet, et exigences TLS pour la donnée en transit avec pour objectif de réduire drastiquement la surface “Internet‑exposed” et donc la reconnaissance/exfiltration.
D) Protection de la donnée : chiffrement, immutabilité, versioning, soft delete
Azure Storage chiffre côté service (SSE) et peut aller jusqu’à la double encryption : c’est une brique de protection structurelle.
Il faut aussi intégrer les mécanismes de protection contre suppression/modification via immutability, et la capacité de récupération via soft delete et versioning.
E) Détection & réponse : Defender for Storage + CSPM + export SIEM
Il est recommander d’activer Defender for Storage (Fonctionnalité de Defender for Cloud) pour détecter accès inhabituels, exfiltration, corruption, upload malveillant, y compris sur des accès sans identité via SAS trop permissifs.Cette fonctionnalité dispose aussi d’un module de malware scanning (near real‑time / on‑demand) et d’intégration Event Grid / Log Analytics / Sentinel pour automatiser réponse et traçabilité.
Bine évidemment, le suivi des recommandations de posture via Defender for Cloud (CSPM) et le monitoring de la baseline Storage est vivement conseillé.
F) Logging & forensic readiness : activer les logs avant l’incident
Les logs Storage ne sont pas forcément activés “par défaut”, et sans eux vous perdez des preuves d’accès/lecture/suppression !!!
Checklist “pragmatique” (synthèse opérationnelle)
- Réduire l’exposition Internet des storage accounts (réseau + politique) et surveiller toute dérive.
- Standardiser l’accès via Entra (RBAC/ABAC) et limiter l’usage de keys/SAS très permissifs.
- Protéger la donnée : immutabilité/versioning/soft delete pour résilience, et gouvernance des changements.
- Activer Defender for Storage + malware scanning + export SIEM pour détection/automatisation.
- Activer les logs Storage + préparer l’investigation (StorageBlobLogs, corrélations, seuils).
- Traiter la racine “identité” : renforcer la résistance au phishing moderne, surveiller les comptes privilégiés, éviter les exceptions.
En synthèse : les attaques cloud modernes ne s’attaquent plus seulement sur des VMs, elles ciblent le Control Plane, les identités, et la couche data (Blob Storage) parce que l’impact est immédiat : fuite massive, corruption, destruction, extorsion.