Une pulvérisation, pas une percée
La société de sécurité Huntress a révélé une campagne de password spraying qui s'est déroulée du 12 au 26 juin 2026, avec un pic le 22 juin. En deux semaines, plus de 81 millions de tentatives de connexion ont visé des comptes Microsoft 365. Le trafic sortait d'une plage IPv6 enregistrée au nom d'un seul opérateur, et les attaquants ne devinaient pas les mots de passe à l'aveugle. Ils rejouaient des couples identifiant et mot de passe récupérés dans des fuites antérieures et sans rapport entre elles, en pariant que les gens réutilisent leurs identifiants d'un service à l'autre. De ce déluge sont sortis 78 comptes compromis dans 64 organisations.
Ce qui frappe, c'est l'absence de tout élément exotique. Pas de faille zero-day, pas de logiciel malveillant sophistiqué, pas de manoeuvre sur la chaîne d'approvisionnement. Il y a eu du volume, des identifiants réutilisés et une voie d'authentification faible. Cette combinaison est à la portée de n'importe quel attaquant ordinaire, et c'est bien pour cela qu'elle mérite l'attention d'un dirigeant. La technique coûte peu, se répète à volonté et vise la couche d'identité que la plupart des entreprises croient déjà protégée par l'authentification multifacteur.
Comment les connexions ont contourné le MFA
Le mécanisme tenait à une ancienne voie de connexion. Les attaquants se sont authentifiés via les outils en ligne de commande d'Azure en empruntant le flux Resource Owner Password Credentials, connu sous le nom de ROPC, une vieille méthode OAuth qui accepte directement un identifiant et un mot de passe et qui, dans de nombreux locataires, ne déclenche aucune demande multifacteur. Là où un locataire avait activé le MFA sans lui donner une portée complète, les identifiants réutilisés sont entrés tout droit par la brèche. Huntress a retrouvé les mêmes erreurs de configuration encore et encore : MFA appliqué à quelques applications seulement, MFA imposé aux seuls groupes d'administrateurs, MFA exigé uniquement depuis des emplacements non approuvés, et politiques Conditional Access oubliées en mode rapport seul, où elles journalisent sans jamais bloquer.
La leçon la moins évidente est que le MFA n'est pas un interrupteur, mais une carte de couverture. Un locataire peut passer un audit qui se contente de demander si le MFA existe, et laisser malgré tout une ancienne porte déverrouillée. Les attaquants n'ont pas vaincu l'authentification multifacteur. Ils ont trouvé les connexions où elle n'était jamais demandée. Toute l'histoire tient dans cette distinction, et elle reste invisible tant que personne ne vérifie quelles voies d'authentification un locataire autorise encore.
La demi-heure qui referme la faille
Un problème de configuration appelle une réponse de configuration, et l'essentiel se règle en une courte session d'administration, sans rien acheter. Bloquez l'authentification héritée et désactivez le flux ROPC, pour que les connexions par identifiant et mot de passe qui sautent le MFA soient purement et simplement refusées. Imposez l'authentification multifacteur sur chaque application et chaque connexion, pas uniquement sur les comptes administrateurs ou les emplacements non approuvés, et faites passer Conditional Access du mode rapport seul au blocage actif. Vérifiez ensuite les journaux de connexion pour y repérer le schéma des pulvérisations échouées, et réinitialisez tout identifiant qu'une fuite passée aurait pu exposer.
Pour une entreprise européenne, il existe une seconde raison d'agir vite. Si des identifiants réutilisés ouvrent une boîte aux lettres contenant des données personnelles, l'incident peut déclencher une obligation de notification au titre du RGPD dans les 72 heures, et une faille d'identité silencieuse devient alors un événement à déclarer et un échange avec l'autorité de contrôle. Refermer la porte coûte un après-midi de configuration. La laisser ouverte se paie en obligations de divulgation et en confiance perdue. Traitez la couche d'identité pour ce qu'elle est devenue, à savoir le périmètre.
À lire ensuite: Un audit IA n'a pas vu la faille Linux qui donne root | Une faille Squid de 29 ans fuite les logins en clair
