Le password spraying bondit de 155× en 2026 en exploitant les angles morts de la MFA

19 août 2026. Huntress publie un bilan qui change la lecture du risque d’identité : une multiplication par 155 des attaques de password spraying au premier semestre 2026. Mi-juin 2026, une seule campagne génère 81 millions de tentatives de connexion en deux semaines et 78 compromissions de comptes. La force brute est un vieux réflexe — mais le ressort de cette hausse, lui, est nouveau : les attaquants ne cassent plus les mots de passe, ils contournent la MFA.

Ce n’est pas un problème de force des mots de passe. C’est un problème de configuration : des organisations qui croient avoir activé la MFA, mais dont les flux d’authentification critiques en sont restés dépourvus.

Une campagne qui cible l’Azure CLI

La principale contributrice de la hausse est une campagne attribuée à l’hébergeur LSHIY LLC. Elle visait l’Azure CLI, l’outil en ligne de commande que les administrateurs utilisent pour gérer les ressources Azure et Entra ID. Le trafic provenait d’une plage IPv6 contrôlée par ce fournisseur.

La mécanique est classique mais montée à une échelle industrielle. Les attaquants collectent des noms d’utilisateur valides via LinkedIn, les sites d’entreprise, les fuites de données et le phishing. Ils assemblent une courte liste de mots de passe — mots de passe piratés, variantes du nom de l’entreprise, termes saisonniers. Puis ils pulvérisent un mot de passe contre tous les comptes de la liste, en restant sous les seuils de verrouillage, avant de passer au suivant.

Le résultat brut : plus de 81 millions de tentatives en deux semaines, concentrées sur la mi-juin. Ce qui rend chaque essai plus rentable, c’est que la campagne réutilisait des couples identifiant-mot de passe volés lors de brèches antérieures et jamais réinitialisés. Chaque succès vaut donc plus qu’une simple supposition.

ROPC, le flux d’authentification que la MFA ne voit pas

Le cœur technique de l’affaire est le ROPC (Resource Owner Password Credentials), un grant OAuth hérité et déprécié dans OAuth 2.1. ROPC a été conçu pour aider les applications à migrer d’une authentification directe vers OAuth. Son défaut : il n’accepte ni MFA ni SSO.

Concrètement, ROPC envoie le nom d’utilisateur et le mot de passe directement à l’endpoint /token, sans invite MFA interactive. Pour un attaquant, un mot de passe réutilisé qui fonctionne encore devient une session active, sans qu’aucun second facteur ne s’interpose.

C’est là que la faille se referme sur les défenseurs. Nombre des entreprises compromises avaient bel et bien déployé la MFA via une stratégie d’accès conditionnel — mais cette MFA ne couvrait pas le flux ROPC utilisé par l’attaquant. La politique protégeait l’interface web, pas l’endpoint token.

Andrew « Spike » Brandt, Principal Threat Intelligence Incident Commander chez Huntress, résume le piège d’une phrase : « Même si nous l’appelons une méthode d’autorisation, c’est techniquement une méthode d’usurpation d’identité. »

Autre indice troublant : Huntress n’a observé aucune activité post-compromission après les connexions réussies de la campagne LSHIY. Rich Mozeleski, Staff Product Manager, soupçonne que l’attaquant validait des identifiants pour les revendre sur le dark web. Le vol d’identifiants est devenu un produit en soi.

Le BYOIP transforme le blocage en jeu de taupes

La campagne a aussi montré la limite du blocage par adresse IP. LSHIY utilisait son offre BYOIP (bring your own IP), un service légitime qui permet à un client de router son trafic via le fournisseur avec ses propres plages IP. Les attaquants exploitent cette flexibilité pour changer de plage et de fournisseur à volonté.

La séquence observée est éloquente. La campagne est partie de la plage IPv6 2a0a:d683::/32. Après que LSHIY a fermé l’activité initiale, les tentatives ont migré vers des plages IPv6 de FranTech, puis vers 3xK Tech en IPv4. L’IPv6 offre aux attaquants un réservoir d’adresses quasi illimité, ce qui rend illusoire le blocage d’un petit ensemble d’IP.

La leçon est sans appel : l’attaquant change de fournisseur plus vite que le défenseur ne bloque. Le blocage d’infrastructure reste utile, mais il ne peut pas être la défense principale.

Les angles morts de la MFA

Le plus instructif tient dans l’échantillon analysé par Huntress : 23 entreprises touchées par la campagne LSHIY. Huit n’avaient aucune MFA. Sur les 15 restantes, la MFA ne s’appliquait pas aux tentatives de l’attaquant — soit parce que la politique était limitée à certaines applications ou à certains groupes d’utilisateurs, soit parce qu’elle reposait sur des emplacements de confiance, soit parce qu’elle était encore en mode rapport seul.

Une stratégie d’accès conditionnel peut sembler exiger la MFA tout en laissant de côté des utilisateurs, des applications ou des méthodes de connexion précises. C’est ce trou que la campagne exploite, sans viser un secteur en particulier : elle s’attaque aux organisations dont les contrôles d’identité laissent une brèche.

La difficulté est réelle : affiner l’accès conditionnel sans bloquer les utilisateurs légitimes est un travail d’équilibriste, et c’est en partie pour cela que la méthode continue de fonctionner.

Détecter le spray et l’usage de ROPC

La campagne LSHIY laisse des traces nettes dans les journaux. Deux signaux suffisent à la repérer :

• des connexions réussies sans MFA dans les journaux de connexion Entra ID, depuis des plages IP inconnues — un spray réussi se distingue du bruit par la validité des identifiants, pas par le volume ;
• des requêtes ROPC, identifiables par la propriété grant_type=password ou par le client app dans les journaux de connexion, souvent associées à l’Azure CLI ou à des clients hérités.

Pour mesurer le danger de ROPC, il suffit de lire le flux : un POST vers /token avec grant_type=password, le nom d’utilisateur et le mot de passe en clair. Aucune redirection, aucune invite MFA, aucune négociation de jeton — l’endpoint répond directement par un jeton d’accès. C’est précisément la mécanique qu’OAuth 2.1 a retirée, mais elle demeure disponible tant qu’elle n’a pas été explicitement désactivée sur le tenant.

La recommandation de Huntress renverse l’intuition : ne priorisez pas les tenants les plus arrosés, car ce sont souvent les moins compromis. Priorisez par validité des identifiants — c’est le seul signal qui distingue un essai raté d’un accès réellement obtenu.

Verdict

Le password spraying n’est pas un problème de mot de passe — c’est un problème de périmètre d’authentification. La hausse de 155× n’est pas venue d’une nouvelle technique d’exploit, mais d’une brèche de configuration : des organisations dont la MFA ne couvrait pas le flux ROPC, et des attaquants assez agiles pour changer d’IP à volonté.

Les correctifs tiennent en quatre décisions, toutes actionnables sans budget :

1. Désactiver ROPC — ou les applications qui en dépendent — sur tout le tenant ;
2. Exiger la MFA pour tous les utilisateurs, toutes les applications cloud et tous les types de clients, sans exclusion, en bloquant les méthodes qui ne peuvent pas satisfaire une exigence MFA ;
3. Restreindre l’Azure CLI aux seuls administrateurs qui en ont besoin ;
4. Ne pas prioriser la réponse par volume de pulvérisation : les tenants les plus arrosés sont souvent les moins compromis — priorisez par validité des identifiants.

Mozeleski conclut : « Un accès conditionnel correctement configuré et géré est un superpouvoir. » Le corollaire est tout aussi clair — une MFA mal configurée est une MFA absente. Si votre politique d’accès conditionnel comporte une exclusion, un mode rapport seul ou une application oubliée, c’est précisément là que la prochaine campagne passera.

Références

• Huntress, « Twist the Nozzle on Password Spraying: A Tradecraft Tuesday Recap », 18 août 2026.
• Huntress, « LSHIY Password Spray Attack », 2026.
• BleepingComputer, « Password spraying attacks surge 155x as hackers exploit MFA gaps », 19 août 2026.