L’écosystème Cloud de Microsoft, bien que robuste, devient un terrain de jeu de plus en plus prisé pour l’ingénierie sociale de haute précision. Récemment, des chercheurs en sécurité ont mis en évidence une méthode d’attaque particulièrement insidieuse utilisant le service Azure Monitor. Cette campagne ne repose pas sur une faille logicielle de type « Zero-day », mais sur le détournement fonctionnel d’une fonctionnalité légitime d’infrastructure pour contourner les passerelles de sécurité de messagerie (SEG).
Introduction : Le détournement de la confiance infrastructurelle
Dans le cadre de l’administration d’infrastructures hybrides, les alertes provenant de azure-noreply@microsoft.com sont considérées comme critiques et fiables. Les administrateurs et les utilisateurs finaux sont habitués à recevoir ces notifications pour des seuils de consommation, des pannes de service ou des alertes de sécurité. C’est précisément cette confiance que les acteurs de menaces exploitent aujourd’hui via le « Callback Phishing » (ou BazarCall).
1. Analyse Technique : Le mécanisme de l’alerte « Action Group »
L’attaque repose sur la configuration des Action Groups dans Azure Monitor. Techniquement, Azure permet de définir des groupes d’actions qui déclenchent des notifications (Email, SMS, Push) lorsqu’une règle d’alerte est satisfaite.
Le vecteur d’attaque se décompose comme suit :
- Création du Tenant Attaquant : L’attaquant utilise son propre tenant Azure (souvent créé avec des identifiants volés ou des essais gratuits).
- Configuration de l’Action Group : Il crée un groupe d’actions incluant les adresses e-mail de ses cibles. Azure envoie alors une notification légitime pour confirmer l’abonnement, ou déclenche une alerte basée sur une condition personnalisée.
- Injection du Payload Social : L’attaquant personnalise le nom de l’alerte ou la description pour y inclure un message alarmiste (ex: « Activité suspecte détectée sur votre compte ») et un numéro de téléphone à appeler (« Callback »).
- Authenticité du Sendeur : L’e-mail est expédié par les serveurs de Microsoft. Les protocoles SPF, DKIM et DMARC sont parfaitement valides, ce qui rend l’e-mail pratiquement invisible pour les filtres anti-spam classiques.
2. Impacts sur l’Infrastructure et la Sécurité
L’impact majeur réside dans la neutralisation des outils de défense périmétriques. Une infrastructure protégée par des solutions de type Proofpoint, Mimecast ou Microsoft Defender for Office 365 aura de grandes difficultés à classer cet e-mail comme malveillant, car l’origine est intrinsèquement sûre.
Sur le plan de l’infrastructure cyber, cela ouvre la porte à :
- L’Accès Initial : Une fois la victime au téléphone, l’attaquant la guide pour installer un outil de prise en main à distance (Remote Access Tool) ou un malware.
- Mouvement Latéral : Une fois le poste de travail compromis, l’attaquant peut exfiltrer des tokens de session ou des identifiants pour rebondir sur l’infrastructure interne.
- Déni de Service Cognitif : La multiplication de ces fausses alertes sature les équipes SOC et réduit la vigilance des utilisateurs face aux vraies alertes d’infrastructure.
Recommandations et Remédiations
Face à ce détournement de service Cloud, les recommandations doivent être à la fois techniques et organisationnelles.
Mesures Techniques (Hardening)
- Filtrage de contenu dynamique : Configurez vos outils de sécurité pour analyser le corps des e-mails provenant de domaines de confiance (
microsoft.com) à la recherche de mots-clés spécifiques (numéros de téléphone inhabituels, termes comme « Support », « Invoice »). - Monitoring des inscriptions Action Groups : Si vous gérez un parc Azure, surveillez via les logs d’audit (Azure Activity Logs) toute création d’Action Group suspecte ou toute tentative d’inscription d’utilisateurs internes par des tenants externes.
- Isolation des postes de travail : Renforcez les politiques d’exécution de scripts (PowerShell Constrained Language Mode) et bloquez les outils d’administration à distance non autorisés (AnyDesk, TeamViewer, etc.) via des politiques AppLocker ou Microsoft Defender for Endpoint.
Mesures Organisationnelles
- Formation spécifique au Callback Phishing : Informez les utilisateurs qu’une alerte Azure légitime ne demandera jamais de contacter un numéro de téléphone pour une « résolution urgente ».
- Procédure de vérification : Établissez une règle stricte : toute alerte d’infrastructure doit être vérifiée directement sur le portail Azure (
portal.azure.com) et non via les liens ou numéros présents dans un e-mail.
Conclusion
L’usage malveillant des alertes Azure Monitor démontre la créativité des attaquants qui préfèrent désormais exploiter la logique métier des services Cloud plutôt que leurs vulnérabilités logicielles. Pour l’expert infrastructure, cela signifie que la confiance accordée aux flux « système » doit être réévaluée. La vigilance humaine reste, dans ce cas précis, le dernier rempart contre une compromission orchestrée depuis les propres serveurs de Microsoft.