Attaques Azure CLI × 155 : 81M de tentatives en 14 jours

81 millions de tentatives en deux semaines : la campagne LSHIY met Azure CLI sous pression

Huntress, éditeur américain spécialisé dans la détection et réponse managées pour les PME, a publié le 19 août 2026 un rapport détaillé sur l'explosion des attaques par password spraying observée au premier semestre 2026. Le chiffre mis en avant est spectaculaire : une hausse de 155 fois du volume de ces attaques par rapport au premier semestre 2025, un niveau sans précédent dans les données observées par la plateforme. Cette montée en puissance est attribuée en grande partie à une campagne spécifique baptisée LSHIY, du nom du fournisseur d'hébergement IPv6 depuis lequel le trafic malveillant est majoritairement originaire — LSHIY LLC.

Le password spraying est une technique d'attaque par force brute inversée : plutôt que d'essayer de nombreux mots de passe sur un seul compte — ce qui déclencherait rapidement les mécanismes de verrouillage — l'attaquant teste un petit nombre de mots de passe très courants sur un très grand nombre de comptes différents. Cette approche contourne les protections de verrouillage de compte tout en maintenant une densité d'attaque suffisante pour aboutir statistiquement à des compromissions, particulièrement dans de grands tenants avec des milliers d'utilisateurs dont certains utilisent inévitablement des mots de passe faibles ou réutilisés.

La campagne LSHIY présente une particularité technique qui la rend particulièrement efficace face aux défenses modernes : elle cible spécifiquement Azure CLI, l'outil de ligne de commande que les administrateurs utilisent pour gérer les ressources Azure et Entra ID. Azure CLI s'authentifie via le protocole OAuth 2.0, mais utilise par défaut le flux ROPC — Resource Owner Password Credentials — un mécanisme de délégation d'identifiants hérité qui permet à une application de passer directement les identifiants utilisateur au serveur d'autorisation sans redirection vers une page de connexion interactive. Ce détail technique est fondamental : le flux ROPC ne passe pas par les mécanismes d'authentification multi-facteurs (MFA) ni par le Single Sign-On (SSO), deux protections qui auraient normalement bloqué les tentatives d'authentification frauduleuses.

En d'autres termes, un compte Microsoft 365 protégé par MFA peut néanmoins être compromis via une attaque par password spraying ciblant Azure CLI si la politique d'accès conditionnel de l'organisation n'inclut pas explicitement le blocage du flux ROPC. Selon les données de Huntress, cette lacune de configuration est extrêmement répandue : parmi les 23 organisations affectées identifiées dans l'analyse, 8 n'avaient pas de MFA configuré du tout, tandis que les autres avaient du MFA uniquement sur les flux d'authentification interactive, laissant le flux ROPC exposé.

En juin 2026 seulement, Huntress a observé plus de 81 millions de tentatives de connexion liées à la campagne LSHIY sur un intervalle de deux semaines. Ce volume traduit un débit moyen d'environ 240 000 tentatives par heure sur la période, un niveau de saturation qui illustre l'infrastructure automatisée et distribuée mise en place par les attaquants. La distribution géographique du trafic, via des plages IPv6 contrôlées par LSHIY LLC, a permis aux attaquants de contourner les listes de blocage basées sur les plages IP traditionnelles, les adresses IPv6 étant encore sous-représentées dans les bases de threat intelligence des outils de sécurité périmétrique.

Les compromissions confirmées s'élèvent à 78 comptes dans les données de Huntress sur la période analysée. Ce taux de succès de moins de 0,0001 % par tentative peut sembler faible, mais le volume brut des tentatives le transforme en une source constante de compromissions exploitables. Dans le contexte d'une attaque ciblant des tenants d'entreprises, un seul compte compromis — en particulier un compte administrateur ou un compte avec accès à Azure Resource Manager — peut ouvrir l'accès à l'ensemble de l'infrastructure cloud de l'organisation.

L'analyse technique publiée par Huntress dans deux articles de blog distincts — « Twist the Nozzle » et « No Bad CAP » — décrit la mécanique précise de l'exploitation. Les attaquants récupèrent des listes d'identifiants d'entreprises depuis des dumps de données publics ou des bases de credentials compromis, puis testent ces identifiants en masse via des requêtes API directes aux endpoints d'authentification Microsoft. La difficulté de détection est accrue par la légitimité apparente du trafic : les requêtes ROPC vers les endpoints Azure sont indiscernables dans leur format d'une utilisation légitime d'Azure CLI par des administrateurs autorisés.

La réponse de Microsoft à cette problématique s'articule autour des politiques d'accès conditionnel dans Entra ID. Depuis la publication du rapport de Huntress, plusieurs recommandations de configuration spécifiques circulent dans la communauté sécurité, dont le blocage du flux ROPC via une règle d'accès conditionnel ciblant les applications clientes Exchange ActiveSync et « Other clients » — catégorie dans laquelle Azure CLI est classé. Le déploiement de cette règle est non destructif pour les usages légitimes d'Azure CLI modernes, qui supportent désormais les flux d'authentification interactifs et device code flow comme alternatives au ROPC.

L'échec structurel du MFA partiel : une leçon de configuration cloud

La campagne LSHIY illustre avec une clarté brutale les limites d'une approche partielle du MFA. De nombreuses organisations ont déployé l'authentification multi-facteurs sur leurs interfaces de connexion web et leurs applications de productivité, obtenant une réduction significative des risques sur ces surfaces d'attaque. Mais l'écosystème Microsoft 365 et Azure est composé d'une multitude de surfaces d'authentification — interfaces web, applications mobiles, clients lourds, flux automatisés, API programmatiques — dont certaines supportent des protocoles d'authentification legacy qui ne passent pas par les mécanismes MFA modernes.

Cette complexité est le talon d'Achille des environnements cloud hybrides hérités. Les organisations qui ont migré vers Microsoft 365 depuis des environnements on-premise ont souvent conservé des configurations legacy compatibles avec leurs outils existants, sans réaliser que ces configurations exposaient de nouvelles surfaces d'attaque. Le flux ROPC en est l'exemple paradigmatique : initialement conçu pour faciliter l'intégration d'applications tierces avec les APIs Microsoft, il est devenu un vecteur d'attaque documenté qui devrait être désactivé dans la quasi-totalité des environnements d'entreprise modernes.

L'explosion du volume d'attaques — 155x en un an — reflète également une évolution des outils et des capacités des acteurs malveillants. L'accessibilité croissante de l'infrastructure d'hébergement IPv6 à bas coût, la disponibilité de frameworks d'automatisation des attaques de credential stuffing, et la maturation des bases de données de credentials compromis issus des méga-breaches des années précédentes convergent pour abaisser drastiquement la barrière à l'entrée pour ce type d'attaque. Ce qui nécessitait autrefois une infrastructure sophistiquée est désormais accessible à des acteurs de niveau intermédiaire.

Les recommandations pratiques à court terme sont claires et documentées par Huntress, Microsoft et le CERT-FR. En priorité : activer une règle d'accès conditionnel dans Entra ID qui bloque le flux ROPC pour toutes les applications clientes legacy, vérifier que les politiques MFA couvrent bien les clients « Other clients » et « Exchange ActiveSync » dans les paramètres d'accès conditionnel, et activer les alertes Defender for Cloud Apps sur les tentatives d'authentification inhabituelles via Azure CLI. À moyen terme, l'audit complet des protocoles d'authentification autorisés dans l'environnement — avec désactivation systématique des protocoles legacy non nécessaires — est une action structurante qui réduit durablement la surface d'attaque.

Ce qu'il faut retenir

• Le flux OAuth ROPC utilisé par Azure CLI contourne nativement le MFA : les organisations protégées par MFA ne sont pas immunisées si leurs politiques d'accès conditionnel ne couvrent pas explicitement les clients legacy et les flux programmatiques.
• 81 millions de tentatives en 14 jours, 78 compromissions confirmées : la campagne LSHIY démontre que le password spraying à grande échelle contre des environnements partiellement protégés reste un vecteur de compromission rentable en 2026.
• Action immédiate recommandée : créer une règle d'accès conditionnel Entra ID bloquant le flux ROPC et les clients d'authentification legacy, puis auditer l'ensemble des surfaces d'authentification de votre tenant Microsoft 365.