Microsoft a publié en mai 2026 le détail d'une campagne d'espionnage particulièrement instructive : aucun malware déployé, aucun CVE exploité, et pourtant une exfiltration massive de données sur plusieurs environnements Azure. L'attaquant s'est contenté de détourner des fonctionnalités Microsoft parfaitement légitimes. C'est précisément ce qui rend ce cas si difficile à détecter, et si utile à étudier.
Le point d'entrée : la réinitialisation de mot de passe en libre-service
Tout commence par de l'ingénierie sociale classique : l'attaquant se fait passer pour le support informatique et pousse la victime à valider une réinitialisation de mot de passe via la fonction SSPR (Self-Service Password Reset) de Microsoft Entra ID. Cette étape, en apparence anodine, permet de contourner l'authentification multifacteur associée au compte ciblé.
Une reconnaissance et une exfiltration entièrement « légitimes »
Une fois dans le tenant, l'attaquant utilise l'API Microsoft Graph pour cartographier l'environnement, puis enchaîne les actions suivantes, toutes réalisées avec des appels API standards :
- Téléchargement massif de milliers de fichiers OneDrive
- Extraction des profils de publication d'App Service, révélant des identifiants FTP et Web Deploy
- Vol de secrets dans Key Vault, en seulement 4 minutes
- Modification des règles de pare-feu SQL Azure pour ouvrir l'accès aux bases de données
- Récupération de clés SAS pour l'accès aux blobs Azure Storage
- Exploitation des extensions de VM (Run Command, VMAccess) pour exécuter des commandes
- Installation de ScreenConnect comme porte dérobée persistante
Aucune de ces actions ne déclenche une alerte de sécurité classique : ce sont des appels authentifiés, indiscernables d'une activité d'administration normale sans corrélation entre identité, poste et cloud.
Pourquoi c'est difficile à détecter
C'est là tout l'enjeu de cette affaire : sans malware ni exploitation de vulnérabilité, les outils de détection traditionnels basés sur des signatures ou des CVE connus ne voient rien passer. Seule une corrélation fine entre les signaux d'identité (comportement SSPR anormal), les signaux cloud (accès Key Vault inhabituel, modification de règles de pare-feu) et les signaux d'endpoint (installation d'un outil RMM non planifié) permet de repérer la chaîne d'attaque dans son ensemble.
Ce que nous recommandons
- Restreindre l'accès à la fonction SSPR pour les comptes à privilèges élevés
- Appliquer un RBAC minimal sur les Key Vault de production
- Générer une alerte sur tout téléchargement massif depuis OneDrive
- Bloquer l'installation d'outils RMM non planifiée au niveau du poste
- Déployer une solution XDR capable de corréler identité, endpoint et signaux cloud
C'est exactement le type de scénario que nous simulons lors de nos missions Red Team : une chaîne d'attaque construite uniquement à partir de fonctionnalités légitimes, pour tester la capacité réelle de détection de vos équipes au-delà des seules signatures antivirus.