Entre le 12 et le 26 juin 2026, Huntress, un fournisseur de cybersécurité managée, a observé une campagne de password spraying particulièrement agressive ciblant les environnements Microsoft 365 de ses clients. En 14 jours, la campagne a généré plus de 81 millions de tentatives d'authentification, aboutissant à la compromission de 78 comptes Microsoft dans 64 organisations distinctes. La campagne a été tracée sous le nom LSHIY, d'après un identifiant interne de l'infrastructure d'attaque.
Ce qui distingue LSHIY des campagnes de force brute classiques, c'est son mécanisme technique. L'attaquant n'a pas utilisé des formulaires de connexion web classiques mais le client en ligne de commande Azure (Azure CLI), couplé au protocole OAuth ROPC (Resource Owner Password Credentials), un mécanisme d'authentification legacy qui, dans certaines configurations, contourne complètement l'authentification multifacteur.
Le protocole ROPC est un flux d'authentification OAuth 2.0 conçu pour les applications qui transmettent directement les identifiants de l'utilisateur au serveur d'autorisation, sans passer par une interface de connexion web interactive. Il a été créé pour des cas d'usage spécifiques, principalement les applications d'entreprise héritées qui ne peuvent pas gérer les redirections OAuth modernes. Microsoft maintient le support de ROPC dans Azure Active Directory (Microsoft Entra ID) pour la compatibilité avec ces scénarios.
L'attaquant de la campagne LSHIY a utilisé l'Azure CLI avec ROPC pour tester des paires identifiant/mot de passe issues de fuites de données précédentes, les fameuses "combo lists" qui circulent sur les marchés criminels. À chaque tentative, l'outil envoie directement les identifiants à l'API Microsoft Entra via le protocole ROPC. Si la paire est valide et si l'authentification multifacteur n'est pas correctement configurée pour bloquer ce flux, Microsoft répond avec un token d'accès valide, sans interaction utilisateur, sans notification push, sans code SMS.
La compromission de 78 comptes malgré l'existence de politiques MFA dans de nombreuses organisations touchées s'explique par des erreurs de configuration des politiques d'Accès Conditionnel Microsoft. Huntress a identifié plusieurs schémas récurrents dans les organisations affectées.
Le premier schéma est le MFA appliqué uniquement à des applications spécifiques plutôt qu'à l'ensemble des applications cloud. Une politique qui force le MFA pour Outlook Web Access mais pas pour l'Azure CLI laisse le flux ROPC sans protection. Le deuxième schéma est le MFA requis uniquement pour certains groupes d'utilisateurs, souvent les administrateurs, laissant les comptes standards vulnérables. Le troisième est le MFA requis uniquement depuis des emplacements non fiables, avec une logique qui s'appuie sur la géolocalisation des IP de résidentiels. Les réseaux proxy résidentiels, dont NetNut (démantelé par Google et le FBI début juillet), permettent précisément à un attaquant de paraître accéder depuis une adresse IP domestique locale.
Le quatrième schéma, et sans doute le plus préoccupant, est la politique d'Accès Conditionnel configurée en mode "report-only". Ce mode permet à Microsoft Entra de simuler l'application de la politique et d'enregistrer ce qui aurait été bloqué, sans bloquer réellement quoi que ce soit. Des politiques en report-only donnent l'illusion d'une protection MFA active alors qu'elles n'appliquent aucun contrôle d'authentification. Enfin, certaines organisations n'avaient simplement aucune politique MFA en place pour les comptes touchés.
Huntress a constaté au cours de la même période une augmentation de plus de 155 fois des attaques de password spraying sur l'ensemble de sa base de clients. La moyenne observée est désormais de 1 964 tentatives d'authentification échouées par tenant Microsoft 365 chaque mois. Ces chiffres reflètent une tendance documentée depuis 2025 : la disponibilité croissante de listes d'identifiants issus de fuites passées, la réduction du coût des proxies résidentiels pour masquer l'origine des attaques, et l'efficacité du password spraying comme technique d'accès initial peu visible dans les journaux de connexion.
Le password spraying, contrairement à la force brute, teste un nombre réduit de mots de passe courants contre un grand nombre de comptes plutôt que de cibler un seul compte intensivement. Cette approche évite les blocages par tentatives multiples sur un même compte, et les volumes par compte sont souvent insuffisants pour déclencher des alertes de sécurité configurées avec des seuils élevés.
Pour les 64 organisations touchées par LSHIY, le signal d'alerte principal disponible dans les journaux Microsoft Entra était le nombre de tentatives d'authentification échouées via le protocole ROPC depuis des IP inhabituelles. Ce signal spécifique, le flux ROPC en particulier, est plus utile que le simple volume de tentatives échouées, car ROPC est rarement utilisé dans les environnements M365 modernes. Une politique d'Accès Conditionnel qui bloque le flux ROPC pour l'ensemble des utilisateurs non inclus dans un groupe d'applications héritées approuvées réduit drastiquement la surface d'attaque de cette technique.
Microsoft Entra ID Protection dispose d'une capacité de détection des logins ROPC inhabituels, mais elle nécessite une licence Microsoft Entra ID P2 ou une licence Microsoft 365 Business Premium incluant les fonctionnalités de protection d'identité avancée. Pour les organisations équipées de ces licences, l'activation des politiques d'accès conditionnel basées sur le risque peut automatiquement bloquer ou forcer une réauthentification lorsqu'Entra détecte un comportement d'authentification anormal.
Les équipes de sécurité qui souhaitent évaluer leur exposition à une campagne comme LSHIY ont plusieurs actions concrètes à réaliser. La première est de vérifier dans les journaux de connexion Microsoft Entra la présence d'authentifications réussies via le protocole ROPC au cours des 30 derniers jours et d'identifier les applications et utilisateurs concernés. La seconde est d'auditer les politiques d'Accès Conditionnel existantes pour s'assurer qu'aucune n'est en mode report-only et que la couverture MFA s'applique bien à "All Cloud Apps" et non à une liste d'applications spécifiques.
La troisième action est de vérifier si des identifiants de l'organisation circulent dans des fuites de données connues. La campagne LSHIY utilisait des combo lists issues de fuites précédentes : si les mots de passe de vos utilisateurs figurent dans ces listes, aucune configuration ROPC ne protège contre leur utilisation. La surveillance de l'exposition des identifiants permet d'identifier ces comptes avant qu'ils ne soient utilisés dans une campagne de spraying.
La hausse de 155 fois des attaques de password spraying observée par Huntress n'est pas un pic ponctuel : c'est le nouveau niveau de base. Les organisations qui n'ont pas encore adapté leur configuration MFA et leur surveillance d'authentification à ce contexte opèrent avec une hypothèse de menace qui ne correspond plus à la réalité. La vérification que vos politiques d'Accès Conditionnel bloquent effectivement le ROPC pour les utilisateurs non exemptés est une mesure de protection concrète et applicable immédiatement, indépendamment de toute autre initiative de sécurité en cours. Comprendre l'exposition de votre organisation sur le dark web complète cette défense en identifiant les identifiants déjà compromis qui alimentent ces campagnes.
La campagne LSHIY n'aurait pas pu générer 81 millions de tentatives d'authentification sans une ressource fondamentale : des listes de paires identifiant/mot de passe issues de fuites de données précédentes. Ces listes, les "combo lists", sont des compilations de données extraites de breaches passés, revendues et redistribuées sur des marchés criminels. Leur disponibilité à faible coût est ce qui rend les campagnes de password spraying économiquement viables pour les attaquants : le coût marginal de chaque tentative supplémentaire est proche de zéro lorsque les identifiants sont déjà disponibles et l'infrastructure de proxy résidentiel est louée à la demande.
Pour les 64 organisations touchées par LSHIY, la vraie question n'est pas seulement pourquoi leurs configurations MFA étaient insuffisantes, mais aussi pourquoi les mots de passe de leurs utilisateurs se trouvaient dans des combo lists criminelles en premier lieu. Les deux vecteurs principaux sont la réutilisation de mots de passe, un utilisateur qui utilise le même mot de passe sur un site tiers qui a été breached, et l'exposition directe via un breach de l'organisation elle-même ou d'un fournisseur de services partagé.
La réinitialisation proactive des mots de passe des comptes dont les identifiants apparaissent dans des bases de données de fuites connues est l'une des défenses les plus directes contre les campagnes de password spraying. Elle coupe l'alimentation des combo lists avant que la campagne ne commence. La surveillance continue de l'exposition des identifiants de votre organisation dans les bases de données de fuites et les forums criminels permet d'identifier ces comptes en temps réel plutôt que d'attendre qu'une tentative réussisse. Associée à une politique de mots de passe qui interdit les mots de passe figurant dans les listes de fuites connues, elle réduit structurellement la matière première disponible pour les campagnes de spraying ciblant votre organisation.
La hausse de 155 fois des attaques observée par Huntress reflète aussi un autre changement : le coût d'une campagne de password spraying à grande échelle a diminué de manière significative. Les proxies résidentiels, les combo lists, et les outils automatisés comme l'Azure CLI sont tous facilement accessibles. La barrière d'entrée pour lancer une campagne comme LSHIY n'est plus technique : elle est principalement organisationnelle, à savoir identifier les organisations qui ont des configurations MFA insuffisantes et des identifiants exposés. Les organisations qui adressent ces deux facteurs simultanément, en durcissant leurs politiques d'Accès Conditionnel et en surveillant leur exposition aux fuites, deviennent des cibles moins rentables et sont généralement évitées au profit d'organisations plus accessibles.
Le protocole ROPC (Resource Owner Password Credentials) est un cas d'école de la tension entre compatibilité backward et sécurité dans les systèmes d'identité modernes. Créé à l'époque où OAuth 2.0 cherchait à standardiser l'authentification pour les applications natives, ROPC permettait à une application de collecter directement les identifiants de l'utilisateur et de les transmettre au serveur d'autorisation pour obtenir un token d'accès. Ce flux a été progressivement déconseillé par Microsoft dans sa documentation car il contourne par conception les interfaces d'authentification modernes, y compris le MFA.
Microsoft maintient le support de ROPC dans Microsoft Entra ID pour permettre la migration des applications héritées qui ne peuvent pas être rapidement mises à jour pour utiliser les flux d'authentification modernes. Dans un monde idéal, ces applications héritées constituent une minorité bien définie et contrôlée dans chaque organisation. Dans la réalité, de nombreuses organisations ont des politiques ROPC activées par défaut pour tous les utilisateurs, car personne n'a explicitement réfléchi à les restreindre, faute d'avoir compris que ROPC est disponible comme flux d'authentification implicite pour n'importe quelle application qui sait comment le formuler.
L'Azure CLI est l'outil utilisé par la campagne LSHIY précisément parce qu'il supporte le flux ROPC nativement et que les tentatives d'authentification via CLI génèrent moins d'alertes dans les configurations de surveillance standard que les tentatives via l'interface web. Les journaux d'authentification Microsoft Entra identifient le client utilisé (Azure CLI dans ce cas), mais beaucoup de règles d'alerte sont configurées pour surveiller les connexions web et pas les connexions CLI.
Pour comprendre pourquoi 81 millions de tentatives en 14 jours sont économiquement faisables pour un attaquant, il faut comprendre l'écosystème des combo lists. Une combo list est un fichier texte contenant des paires email/mot de passe extraites de brèches de données. Des bases comme "Collection #1" publiée en 2019 contenaient 2,7 milliards de paires. Depuis, de nombreuses autres compilations ont été publiées et se cumulent. Les marchés criminels vendent des combo lists filtrées par domaine (par exemple, uniquement les emails en @entreprise.com avec leurs mots de passe), par secteur, ou par taux de validité vérifié.
Pour la campagne LSHIY, l'attaquant a probablement utilisé des combo lists filtrées pour cibler des adresses email d'entreprises Microsoft 365, puis testé ces paires contre l'endpoint ROPC de Microsoft Entra. Le taux de succès brut d'une campagne de password spraying sur combo lists est généralement faible, souvent inférieur à 1%, mais sur 81 millions de tentatives, même un taux de 0,1% représente 81 000 accès potentiels. En pratique, les 78 comptes compromis représentent un taux de conversion très bas, mais chaque accès réussi est une intrusion concrète avec des conséquences réelles pour l'organisation concernée.
La disponibilité et le coût des combo lists de qualité ont diminué considérablement. Des listes filtrées par domaine coûtent quelques dizaines de dollars sur les marchés criminels. L'infrastructure de proxy résidentiel (comme NetNut avant son démantèlement) coûte quelques centaines de dollars pour louer suffisamment de nœuds pour une campagne de cette envergure. Le coût total d'une campagne comme LSHIY est inférieur à quelques milliers d'euros, pour un retour potentiel de centaines de milliers d'euros en données exfiltrées ou en accès revendus.
Pour les équipes de sécurité qui souhaitent évaluer et renforcer leur configuration MFA face à des attaques comme LSHIY, voici les vérifications les plus critiques à effectuer dans Microsoft Entra ID. La première vérification porte sur la couverture des applications : dans le portail Microsoft Entra, sous "Protection / Accès Conditionnel / Politiques", examiner chaque politique active et vérifier que la condition "Applications ou actions cloud" est définie sur "Toutes les applications cloud" et non sur une liste spécifique d'applications. Une politique MFA qui ne couvre pas "Toutes les applications cloud" laisse des vecteurs d'accès non protégés.
La deuxième vérification porte sur le mode d'application : s'assurer qu'aucune politique critique n'est en état "Rapport uniquement". Les politiques en rapport uniquement ne bloquent rien. Elles simulent l'impact d'une politique sans l'appliquer. Pour confirmer l'état réel, le portail affiche clairement "Actif" ou "Rapport uniquement" pour chaque politique. La transition d'une politique de "Rapport uniquement" à "Actif" devrait être précédée d'un test en conditions réelles pour valider qu'elle ne bloque pas des accès légitimes.
La troisième vérification porte sur les exclusions de groupes : les politiques MFA incluent souvent des exclusions pour des comptes de service, des comptes d'urgence "break-glass", ou des groupes d'utilisateurs hérités. Ces exclusions doivent être auditées régulièrement pour s'assurer qu'elles ne sont pas plus larges que nécessaire et que les comptes exclus utilisent des compensations de sécurité alternatives comme des mots de passe très longs et uniques ou une surveillance renforcée.
La quatrième vérification porte sur le blocage du flux ROPC : créer une politique d'Accès Conditionnel qui bloque le flux d'authentification "Exchange ActiveSync" et les "autres clients" (qui inclut ROPC) pour tous les utilisateurs sauf ceux explicitement exemptés pour des besoins d'applications héritées. Microsoft fournit dans sa documentation des exemples de politiques de blocage des authentifications héritées qui couvrent précisément ce vecteur. Cette politique unique aurait bloqué la campagne LSHIY pour les organisations qui l'avaient en place.
La hausse de 155 fois des attaques de password spraying documentée par Huntress n'est pas un événement ponctuel lié à la campagne LSHIY spécifique. Elle reflète une tendance de fond qui devrait se maintenir ou s'accélérer pour plusieurs raisons structurelles. La première est l'accumulation continue de combo lists : chaque nouvelle brèche de données ajoute des millions de paires identifiant/mot de passe aux ressources disponibles pour les attaquants. La deuxième est la démocratisation des infrastructures de proxy résidentiel : même après le démantèlement de NetNut, d'autres réseaux similaires existent et continuent de croître. La troisième est la disponibilité d'outils automatisés clé en main pour lancer des campagnes de spraying via Azure CLI ou d'autres mécanismes d'authentification cloud.
La réponse efficace à cette tendance n'est pas réactive mais structurelle. Les organisations qui implémentent une couverture MFA complète sur "Toutes les applications cloud", qui bloquent le flux ROPC pour les utilisateurs sans besoin d'applications héritées, et qui surveillent en continu l'exposition de leurs identifiants dans les bases de données de fuites créent une posture défensive qui résiste à l'ensemble de cette catégorie d'attaques, quel que soit le nom de la prochaine campagne ou le réseau de proxies qu'elle utilise. Ces mesures structurelles transforment le password spraying d'une menace viable en une technique à faible rendement contre leur environnement spécifique, ce qui suffit généralement à rediriger les attaquants opportunistes vers des cibles moins bien protégées.
Les attaques décrites dans cet article partagent une caractéristique commune : elles exploitent soit des identifiants compromis, soit des comportements de confiance dans des systèmes légitimes, soit la lenteur des cycles de mise à jour. Qu'il s'agisse de ransomware Avalon ciblant les sauvegardes, d'une intrusion médicale via vishing chez Abbott, d'un ransomware généré par IA sans installation, ou d'une campagne de password spraying à 81 millions de tentatives, le point d'entrée est presque toujours lié à l'identité et aux données d'accès.
Defendis surveille en continu le dark web, les forums criminels et les bases de données de fuites pour identifier les identifiants et données liés à votre organisation. Si des informations de vos systèmes circulent dans ces canaux, Defendis vous en informe avec le contexte nécessaire pour agir avant que l'impact ne s'étende.
Réservez une démo pour voir Defendis en action.
