Le password spraying a explosé de 155 fois — parce que la MFA n'a jamais été déclenchée

Au premier semestre 2026, Huntress a enregistré une hausse multipliée par 155 des attaques de password spraying chez ses clients. Ce n’était pas un retour à la force brute bruyante. C’était la réutilisation calme d’anciens mots de passe sur un chemin de connexion qui ne demandait jamais de second facteur.

Une grande part de ce trafic visait l’Azure CLI de Microsoft. En deux semaines à la mi-juin, Huntress a compté plus de 81 millions de tentatives et 78 comptes compromis dans 64 organisations. Beaucoup croyaient déjà avoir la MFA. Pour la méthode utilisée par l’attaquant, elle n’a jamais été déclenchée.

Cet article explique ce qu’est le spraying, comment la campagne LSHIY a abusé d’un grant OAuth obsolète, pourquoi l’accès conditionnel semblait complet tout en restant incomplet, et quoi changer pour qu’un mot de passe seul n’ouvre plus la porte.

Le spraying n’est pas la force brute

Une attaque par force brute assomme un seul compte avec de nombreuses tentatives. Ce schéma déclenche verrouillages, limites de débit et alertes de déplacement impossible. Le password spraying inverse l’ordre : l’attaquant choisit un mot de passe probable, le teste sur une longue liste d’identifiants, attend, puis passe au mot de passe suivant.

• Force brute : beaucoup de tentatives contre un compte. Rapide, bruyant, facile à bloquer.
• Password spraying : une tentative contre beaucoup de comptes. Assez lent pour rester sous les seuils de verrouillage.
• Credential stuffing : paires e-mail/mot de passe déjà fuitées, rejouées sur d’autres sites.

Cette campagne a mêlé volume de spray et paires volées

La campagne LSHIY se situait entre ces deux dernières catégories. Huntress indique que le ciblage suivait la prévalence des mots de passe dans des listes combo compromises, pas le secteur ni la taille de l’entreprise. Les attaquants ont réutilisé des couples identifiant/mot de passe déjà fuités et jamais renouvelés. C’est pourquoi l’unicité compte encore, même avec une MFA « sur le papier » : un mot de passe réutilisé qui fonctionne encore est une session en attente.

Un spray classique commence encore par la reconnaissance — identifiants valides via LinkedIn, sites d’entreprise, fuites ou phishing — puis une courte liste de mots de passe courants ou saisonniers. Ici, l’opérateur n’avait pas besoin de devinettes astucieuses. Les secrets étaient déjà connus. L’avantage était le volume, une infrastructure difficile à bloquer, et un flux qui contournait la page MFA.

Le flux d’authentification que le temps a oublié

Azure CLI, l’outil en ligne de commande pour Azure et Microsoft Entra, accepte encore un grant OAuth hérité appelé Resource Owner Password Credentials (ROPC). La documentation Microsoft prévient que le ROPC est incompatible avec l’authentification multifacteur. OAuth 2.1 l’a entièrement déprécié.

Lors d’une connexion navigateur normale, l’utilisateur arrive sur une page d’autorisation. C’est là que l’accès conditionnel peut exiger la MFA, vérifier l’appareil ou refuser un lieu risqué. Le ROPC ne visite jamais cette page. Le client envoie identifiant et mot de passe directement au endpoint /token du locataire. Si le mot de passe est encore valide, un jeton délégué peut être émis sans invite interactive.

Andrew « Spike » Brandt, de Huntress, le dit clairement : même si l’on parle d’une méthode d’autorisation, « c’est techniquement une méthode d’usurpation ». Pour un attaquant qui détient un mot de passe réutilisé, c’est tout le gain — une session, pas une tentative.

La MFA était configurée. La politique ne l’était pas.

C’est le point qui devrait inquiéter quiconque prend une case MFA pour une ligne d’arrivée. Lors du pic du 22 juin, Huntress a examiné 23 entreprises touchées. Huit n’avaient aucune politique MFA. Les 15 autres avaient une MFA imposée via l’accès conditionnel — et ont quand même perdu des comptes — parce que la politique ne couvrait pas le chemin de l’attaquant.

• MFA limitée à certaines applications, comme les portails d’administration Microsoft, donc Azure CLI restait dehors.
• MFA limitée à certains groupes, souvent « admins seulement », alors que les comptes compromis n’étaient pas dans le périmètre.
• MFA exigée seulement depuis des lieux non de confiance. Une géolocalisation IPv6 incohérente a fait passer des adresses attaquantes pour fiables.
• MFA restée en mode rapport uniquement : configurée, observée, jamais appliquée.

Un décompte ultérieur a clarifié l’écart

Dans un suivi, Huntress a écrit que 55 des 78 comptes compromis avaient déjà des politiques d’accès conditionnel exigeant la MFA. Une organisation avait même nommé une politique « Block Azure CLI ». Elle ne bloquait pas Azure CLI. La MFA n’a pas échoué comme technologie. Elle a échoué comme périmètre.

Huntress n’a vu aucune activité post-compromission après les connexions LSHIY réussies. Rich Mozeleski suppose que l’opérateur validait des identifiants pour les revendre plutôt que de s’installer dans les locataires. C’est une faible consolation. Un mot de passe confirmé qui contourne la MFA reste un produit sur une liste, et l’acheteur suivant peut ne pas s’arrêter à la validation.

Bloquer les IP est devenu un jeu de taupe

La première vague venait de la plage IPv6 2a0a:d683::/32, annoncée par LSHIY LLC (AS32167). L’attaquant utilisait l’offre bring-your-own-IP (BYOIP) — un peering légitime qui permet de router du trafic via des plages déjà détenues. Après les signalements, LSHIY a suspendu cet utilisateur début juillet.

Le spray n’a pas cessé. L’activité est passée à des plages IPv6 hébergées chez FranTech, puis à 3xK Tech en IPv4, en tournant parmi des milliers d’adresses et en gardant un volume faible par IP. Huntress a ensuite revu environ 1,5 million de tentatives par jour. L’IPv6 offre un immense vivier d’adresses. Changer de fournisseur en offre un nouveau dès qu’un bloc est fermé.

Les défenseurs qui attendent de bloquer l’ASN du jour seront toujours en retard. Le contrôle durable consiste à rendre un mot de passe insuffisant, pas à tenir une liste noire de l’infrastructure d’hier.

Ce que les organisations doivent changer

Affiner l’accès conditionnel sans bloquer les vrais utilisateurs est difficile. Cette difficulté explique en partie pourquoi l’attaque continue de fonctionner. Les conseils de Huntress restent le chemin le plus court :

• Exiger la MFA — ou bloquer la connexion — pour tous les utilisateurs, toutes les applications cloud et tous les types de clients, sans exclusions silencieuses.
• Utiliser un paramètre client fort comme userStrongAuthClientAuthNRequired pour que le ROPC échoue même si le mot de passe est correct.
• Désactiver le ROPC et les autres grants hérités qui ne peuvent pas satisfaire la MFA. Microsoft demande déjà aux développeurs d’en sortir.
• Réserver Azure CLI aux personnes qui en ont vraiment besoin. La plupart des collaborateurs n’en ont pas besoin.
• Prioriser la réponse selon la validité des identifiants, pas le volume de spray. Les locataires les plus bruyants sont souvent les moins compromis.
• Traiter l’hygiène des mots de passe comme une MFA inachevée : secrets uniques, renouvellement après toute fuite, et passkeys ou d’autres options sans mot de passe pour les comptes à forte valeur.
• Écrire les règles. Notre guide des mots de passe sûrs en 2026 aide à transformer « nous avons la MFA » en standard applicable sur la réutilisation, la rotation et les méthodes de secours.

Ce que chacun peut faire

Vous n’avez pas besoin d’un locataire Entra pour être dans le rayon d’action. Les mêmes listes combo qui ont nourri les sprays Azure CLI sont testées chaque jour sur la messagerie personnelle, les sites marchands et les réseaux sociaux. Spraying et stuffing se nourrissent tous deux de la réutilisation.

• Utilisez un mot de passe unique pour chaque compte. Créez-en un avec notre générateur, puis stockez-le dans un gestionnaire.
• Lancez un test de fuite sur tout ce que vous avez réutilisé. Les mots de passe LSHIY étaient anciens ; ils fonctionnaient encore parce que personne ne les avait changés.
• Activez la MFA partout, puis préférez passkeys ou clé de sécurité pour la messagerie, le gestionnaire, la banque et le travail. La MFA classique aide encore contre le stuffing — mais comme l’explique notre article AitM, SMS et TOTP ne sont pas la fin de l’histoire.
• Si vous utilisez Azure CLI ou un autre client hérité, demandez au service IT si le ROPC est encore autorisé pour votre compte. Un mot de passe que vous ne tapez jamais dans un navigateur peut quand même être rejoué par un outil.