LSHIY : 81 M d'attaques contournent le MFA sur M365

81 millions de tentatives : comment LSHIY a contourné le MFA de Microsoft 365

Entre le 12 et le 26 juin 2026, une campagne de password spraying d'une ampleur inédite a ciblé les environnements Microsoft 365. Documentée par la société de cybersécurité managée Huntress, l'opération a généré plus de 81 millions de tentatives d'authentification en quatorze jours, frappant des locataires Azure Active Directory à travers le monde. Le bilan final : 78 comptes compromis au sein de 64 organisations distinctes.

Ce qui distingue cette campagne est le vecteur d'attaque choisi. L'acteur malveillant n'a pas ciblé les portails de connexion web classiques, mais Azure CLI, l'interface en ligne de commande de Microsoft Azure. Ce choix lui a permis d'exploiter un mécanisme d'authentification hérité que la grande majorité des entreprises n'a pas sécurisé correctement : le flux ROPC (Resource Owner Password Credentials).

L'infrastructure de la campagne est identifiable avec précision. L'essentiel du trafic malveillant provient de la plage d'adresses IPv6 2a0a:d683::/32, attribuée à LSHIY LLC, un fournisseur d'infrastructure internet référencé sous le numéro de système autonome AS32167. Certaines adresses IP de cette plage sont géolocalisées aux États-Unis, d'autres en Chine. L'identité réelle de l'opérateur reste inconnue, LSHIY LLC pouvant n'être qu'un hébergeur intermédiaire utilisé pour masquer l'origine réelle des attaques.

Le mécanisme central repose sur le flux OAuth ROPC, un mode d'authentification hérité que Microsoft maintient pour des raisons de compatibilité descendante. Ce flux soumet directement un couple identifiant/mot de passe à l'endpoint /token d'un locataire Azure AD, sans déclencher de session interactive. La conséquence directe est que ROPC ne supporte ni le MFA moderne, ni le SSO, ni les politiques d'accès conditionnel appliquées aux sessions interactives classiques. Une fois qu'un attaquant dispose d'une paire d'identifiants valide, il s'authentifie sans qu'aucune invite MFA ne se déclenche.

Les tentatives d'authentification ont été alimentées par des paires identifiant/mot de passe issues de fuites de données antérieures, une technique de credential stuffing bien rodée. Contrairement au brute force classique, le credential stuffing s'appuie sur des bases de données d'identifiants réels, augmentant le taux de succès tout en maintenant une fréquence d'attaque suffisamment basse par compte pour éviter les verrouillages automatiques.

L'analyse de Huntress a mis au jour des erreurs de configuration récurrentes dans les organisations victimes. Sur les 23 entreprises touchées le 22 juin 2026, 15 disposaient d'un MFA activé via des politiques d'accès conditionnel. Mais ces politiques présentaient des angles morts : certaines ne couvraient que les portails d'administration Microsoft, pas l'ensemble des applications cloud ; d'autres étaient restreintes à des groupes spécifiques d'utilisateurs comme les administrateurs uniquement ; dans deux cas, le MFA était configuré en mode rapport uniquement, jamais basculé en mode application réel. Huit organisations ne disposaient d'aucune politique MFA.

Au niveau macro, Huntress a observé une hausse de 155 fois du volume d'attaques par password spraying sur sa base de clients, avec une moyenne de 1 964 tentatives de connexion échouées par locataire et par mois. Cette tendance illustre l'industrialisation croissante des attaques d'authentification, facilitée par la disponibilité de bases d'identifiants compromis à faible coût sur les marchés clandestins et par l'accessibilité d'infrastructures IPv6 bon marché pour masquer le trafic.

Microsoft recommande d'activer le paramètre d'accès conditionnel userStrongAuthClientAuthNRequired, qui force une authentification forte au niveau du client et bloque structurellement les flux ROPC. La mesure la plus immédiate reste de vérifier que les politiques d'accès conditionnel s'appliquent à l'ensemble des utilisateurs, toutes applications cloud confondues, et tous types de clients d'application sans exception. Selon le rapport de Huntress publié début juillet 2026 sous le titre No (Bad) CAP: Inside an Ongoing LSHIY Password Spray Attack, cette configuration représente le seul rempart fiable contre ce vecteur d'attaque.

Pourquoi cette attaque remet en cause la confiance aveugle dans le MFA

Cette campagne illustre une réalité que les équipes sécurité doivent intégrer : le MFA n'est pas une protection absolue. C'est une protection conditionnelle, dont l'efficacité dépend entièrement de la qualité de sa configuration. Activer le MFA dans Entra ID ne suffit pas si les politiques d'accès conditionnel ne couvrent pas l'ensemble des vecteurs d'authentification, notamment les flux legacy comme ROPC ou les connexions via des clients non-navigateur tels qu'Azure CLI, PowerShell, ou les applications MSAL mal configurées.

Cette attaque s'inscrit dans une tendance plus large observée depuis fin 2025 : l'exploitation systématique des angles morts de la gestion des identités cloud. Les acteurs malveillants ne cherchent plus à casser le MFA frontalement. Ils identifient les flux d'authentification qui ne le déclenchent pas. C'est ce qu'on observe avec ROPC, avec les tokens legacy SMTP AUTH, et avec l'exploitation des accès permanents non expirés dans les environnements hybrides Active Directory et Entra ID. La surface d'attaque de l'identité numérique s'est considérablement étendue avec la migration vers le cloud, mais les pratiques de configuration n'ont pas suivi au même rythme.

Pour les entreprises françaises et européennes utilisant Microsoft 365, l'enjeu est double. La conformité NIS2 impose une gestion rigoureuse des accès et une capacité de détection des incidents que cette campagne met directement à l'épreuve. Par ailleurs, une compromission de compte M365 ouvre immédiatement la porte à des actions post-exploitation variées : exfiltration de données via SharePoint et OneDrive, déplacement latéral via les permissions déléguées dans Entra ID, envoi de phishing interne depuis un compte légitime, ou accès aux applications SaaS connectées via OAuth.

La divulgation publique complète effectuée par Huntress est un exemple de threat intelligence partagée de manière responsable. La documentation technique fournie dans leur rapport, incluant les indicateurs de compromission, les plages IPv6 sources et les recommandations de configuration précises, permet à l'ensemble de l'écosystème de se défendre collectivement. Les équipes SOC et les administrateurs Azure doivent traiter cette publication comme un signal prioritaire et auditer immédiatement leurs Conditional Access Policies.

Ce qu'il faut retenir

• Le flux ROPC OAuth legacy d'Azure CLI contourne le MFA lorsque les politiques d'accès conditionnel ne couvrent pas explicitement tous les types de clients d'application.
• 78 comptes Microsoft 365 ont été compromis dans 64 organisations malgré des politiques MFA présentes, en raison d'erreurs de configuration des Conditional Access Policies.
• Action immédiate : auditer les CAP pour couvrir All Users, All Cloud Apps, All Client App Types, et activer userStrongAuthClientAuthNRequired pour bloquer structurellement le flux ROPC.