81 millions de tentatives de password spraying via Azure CLI. Les attaquants ne cherchaient pas à contourner l’authentification multifactorielle, ils la contournaient.
Quatre-vingt-un millions de tentatives de password spraying. Soixante-dix-huit comptes compromis. Trente-neuf organisations touchées. Ce sont les chiffres publiés par Huntress le 1er juillet 2026, issus d’une campagne active ciblant les environnements Microsoft Azure – et le chiffre le plus important n’est aucun de ceux-là. Le chiffre clé, c’est zéro : le nombre de notifications MFA déclenchées par les attaquants.
Cette campagne ne cherchait pas à contourner la MFA, mais à l’éviter complètement. La technique n’est pas nouvelle – les chercheurs en sécurité ont déjà documenté des attaques d’authentification basées sur ROPC – mais l’ampleur de cette campagne et la spécificité du ciblage de l’Azure CLI en font l’exemple le plus parlant de ce qui se produit lorsque des flux d’authentification hérités coexistent avec des contrôles d’identité modernes dans un même environnement d’entreprise.
La recherche Huntress détaille comment les attaquants ont utilisé le flux OAuth 2.0 Resource Owner Password Credentials pour s’authentifier directement auprès d’Azure AD sans déclencher de politiques d’accès conditionnel ni d’exigences MFA. Pour comprendre pourquoi cela fonctionne, il faut saisir ce qu’est ROPC, en quoi il diffère des flux d’authentification modernes, et pourquoi il reste accessible dans la plupart des locataires Azure malgré la dépréciation du protocole par Microsoft.
Résumé de l’essentiel
1. Huntress a documenté 81 millions de tentatives de password spraying via Azure CLI, compromettant 78 comptes dans 39 organisations.
La campagne visait un flux OAuth 2.0 hérité appelé Resource Owner Password Credentials (ROPC), qui transmet les identifiants directement à Azure AD et contourne totalement la MFA et l’application des politiques d’accès conditionnel modernes.
2. Microsoft a déprécié ROPC, mais il reste largement utilisable.
Le flux OAuth 2.0 ROPC a été conçu pour les systèmes hérités incapables de rediriger les utilisateurs vers un navigateur pour l’authentification. Microsoft l’a déprécié au profit de flux modernes, mais comme il fonctionne encore techniquement dans la plupart des locataires Azure, les attaquants peuvent l’exploiter pour s’authentifier sans déclencher la MFA ou les contrôles d’accès conditionnel.
3. La mauvaise configuration des politiques d’accès conditionnel est la cause principale.
Même les organisations ayant déployé des politiques d’accès conditionnel présentent souvent des failles de couverture – applications spécifiques, groupes d’utilisateurs ou conditions géographiques laissant le trafic ROPC sans protection. L’Azure CLI constitue une exception fréquente, ce qui signifie que les identifiants de développeurs authentifiés via ROPC peuvent accéder aux ressources de production.
4. Le mode opératoire exploite l’écart entre l’intention de la politique et son application technique.
Les organisations pensent que la MFA protège leur environnement Azure car elle sécurise l’authentification via navigateur. L’authentification ROPC ne passe pas par ce flux. Il ne s’agit pas d’une faille de la MFA en soi – mais d’une mauvaise configuration qui laisse un chemin d’authentification hérité ouvert en parallèle du flux moderne.
5. Le correctif va au-delà de l’hygiène des mots de passe.
Bloquer la voie d’attaque ROPC nécessite de : bloquer les protocoles d’authentification hérités au niveau du locataire, auditer la couverture des politiques d’accès conditionnel pour détecter les failles, renouveler les identifiants des comptes ayant accès à l’Azure CLI, et mettre en place des contrôles Identity and Access Management capables de signaler les événements d’authentification ROPC comme anormaux.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Qu’est-ce que ROPC et pourquoi existe-t-il encore ?
Le cadre OAuth 2.0 propose plusieurs flux d’authentification adaptés à différents usages. Le standard moderne pour l’authentification interactive des utilisateurs est le flux Authorization Code avec PKCE – il redirige l’utilisateur vers un fournisseur d’identité, collecte les identifiants, puis retourne un code d’autorisation à l’application. Ce flux est compatible avec la MFA et les politiques d’accès conditionnel car l’authentification se déroule chez le fournisseur d’identité, là où résident ces contrôles.
ROPC a été conçu comme alternative pour les applications héritées incapables d’effectuer des redirections via navigateur. Au lieu d’envoyer l’utilisateur vers une page de connexion, ROPC accepte les identifiants directement depuis l’application et les transmet au fournisseur d’identité via une requête POST. L’application gère donc elle-même l’échange d’identifiants.
Microsoft a déprécié ROPC car il est structurellement incompatible avec les contrôles de sécurité modernes. Les identifiants transitent par l’application et non par l’interface d’authentification du fournisseur d’identité, ce qui empêche l’injection de notifications MFA dans le flux. Les politiques d’accès conditionnel qui se déclenchent lors des connexions ne s’appliquent pas. L’émission du jeton intervient sans que l’évaluation complète des accès conditionnels du fournisseur d’identité soit réalisée.
Le problème, c’est que la dépréciation ne signifie pas la désactivation. ROPC reste fonctionnel dans la plupart des locataires Azure. Microsoft incite ses clients à adopter les flux d’authentification modernes, mais ROPC demeure opérationnel pour assurer la rétrocompatibilité avec les systèmes hérités. Dans la campagne documentée par Huntress, les attaquants ont utilisé ROPC pour s’authentifier via Azure CLI – un outil de développement courant avec accès aux ressources Azure – car Azure CLI prend en charge ROPC et la plupart des organisations ne l’ont pas explicitement bloqué. Un audit formel des protocoles d’authentification actifs – en cartographiant précisément les flux hérités encore activés selon les applications – constitue le point de départ pour éliminer ce type de faille avant qu’elle ne provoque une violation.
Comment l’attaque fonctionne-t-elle concrètement ?
La campagne documentée par Huntress suit un schéma bien connu : énumérer des noms d’utilisateurs valides, lancer des attaques de credential stuffing ou de password spraying sur les points d’accès compatibles ROPC, récupérer les jetons issus des authentifications réussies, utiliser ces jetons pour accéder aux ressources Azure.
La dimension Azure CLI est essentielle en raison de la portée de cet accès. Les comptes développeurs disposant de l’Azure CLI ont souvent des autorisations sur les environnements de production, les groupes de ressources, les comptes de stockage et les ressources de calcul. La CLI est un outil d’administration – elle doit offrir un accès large. Quand un attaquant compromet un identifiant CLI via ROPC, il ne se limite pas à l’accès à la messagerie. Il peut accéder à l’infrastructure.
Les attaques par force brute sur les points d’authentification classiques sont bruyantes. Elles génèrent des événements d’échec de connexion détectés et signalés par les SIEM et systèmes de protection d’identité. Les attaques de password spraying via ROPC sont plus discrètes : elles ne génèrent pas les mêmes événements d’authentification de session navigateur, et de nombreuses configurations de journalisation ne capturent pas l’émission de jetons ROPC avec la même précision que les connexions interactives.
Le chiffre de 81 millions de tentatives reflète le coût informatique du password spraying à grande échelle – c’est un volume important, mais les 78 compromissions réussies (taux de réussite de 0,000096 %) illustrent aussi la dispersion des identifiants sur de nombreux essais avant de trouver une correspondance. Le véritable risque ne réside pas dans le nombre brut de tentatives. Il tient au fait que chaque authentification ROPC réussie retourne un jeton bearer donnant accès à tout ce que le compte compromis peut atteindre. Un seul compte développeur compromis avec accès à des comptes de stockage de production, des ressources de calcul et des pipelines CI/CD constitue à la fois une violation de données et un incident d’infrastructure – la combinaison de propriété intellectuelle dans les dépôts de code et de données réglementées dans le cloud implique des obligations de notification et de remédiation conséquentes.
Le phishing et la réutilisation de mots de passe sont les principales sources des identifiants exploités dans les campagnes de password spraying. Dès qu’un identifiant apparaît dans une base de données de violation – ce qui finit par arriver pour la plupart – il devient une donnée d’entrée pour les outils automatisés de spraying. L’authentification ROPC à grande échelle dépend essentiellement : (a) du nombre d’identifiants valides obtenus par les attaquants lors de violations précédentes, et (b) du nombre de points d’accès locataire accessibles via ROPC sans application des politiques d’accès conditionnel.
Le problème de couverture des politiques d’accès conditionnel
Les politiques d’accès conditionnel constituent le principal contrôle de défense en profondeur pour les environnements Azure AD. Elles permettent aux organisations de définir les conditions de réussite de l’authentification – exiger la MFA, bloquer les connexions à risque, restreindre l’accès aux appareils conformes. Bien configurées, ces politiques rendent les attaques de password spraying largement inefficaces, car même un identifiant valide ne permet pas de s’authentifier sans satisfaire aux conditions de la politique.
Le problème de couverture dans les attaques ROPC ne vient pas d’une défaillance des politiques, mais de leur couverture rarement totale. Les organisations déploient les politiques d’accès conditionnel de façon incrémentale, en commençant souvent par les applications et groupes d’utilisateurs prioritaires, et accumulent des exceptions au fil du temps. L’Azure CLI est une exception fréquente : les développeurs ont besoin d’un accès CLI, les outils CLI fonctionnent souvent dans des pipelines automatisés qui ne supportent pas les interruptions MFA, ce qui aboutit à une exemption qui fait de l’authentification CLI une cible facile.
La mauvaise configuration de la sécurité au niveau de l’identité reste l’un des vecteurs d’attaque les plus efficaces. Une seule exception mal configurée peut exposer des identifiants à des chemins d’authentification hérités contournant une MFA pourtant robuste. La campagne Huntress en est la conséquence directe : 78 comptes compromis non pas parce que la MFA est faible, mais parce qu’ils bénéficiaient d’une exception ou d’un périmètre applicatif autorisant l’authentification ROPC.
La question d’audit à se poser n’est pas « avons-nous des politiques d’accès conditionnel ? », mais « nos politiques couvrent-elles tous les chemins d’authentification, y compris les points d’accès aux protocoles hérités, pour tous les comptes utilisateurs ? » La plupart des organisations n’ont pas audité ce point au niveau des protocoles. Étendre les pratiques de gestion des risques supply chain à cette question est crucial, surtout pour celles ayant accordé un accès Azure CLI à des développeurs tiers, prestataires ou fournisseurs de services managés – chaque identifiant externe avec accès CLI représente un point d’exposition ROPC que l’audit CAP de l’organisation principale ne contrôle pas toujours directement.
Gouvernance des identités au-delà de la MFA
Le mode opératoire ROPC met en lumière une faille structurelle de la sécurité des identités que la MFA seule ne règle pas. La MFA agit sur les flux d’authentification interactifs. Les protocoles hérités ont été conçus pour fonctionner hors de ces flux. Par définition, ils sont incompatibles avec la MFA.
La réponse architecturale doit intervenir au niveau du protocole, pas seulement de l’identifiant. Bloquer l’authentification héritée signifie configurer Azure AD pour rejeter toute demande de jeton ROPC – une politique d’accès conditionnel peut être créée pour bloquer l’authentification héritée pour tous les utilisateurs ou des groupes ciblés. C’est la principale recommandation de Microsoft et du rapport Huntress.
Les cadres de contrôle d’accès basé sur les rôles et contrôle d’accès basé sur les attributs qui limitent les droits des développeurs au strict nécessaire réduisent l’impact d’une compromission ROPC. Un compte développeur qui ne peut lire que certains conteneurs de stockage ou déployer sur des groupes de ressources précis est moins catastrophique à compromettre qu’un compte Contributor sur tout un abonnement. La minimisation des données appliquée à la portée des identifiants – en provisionnant les comptes développeurs avec le minimum de droits Azure nécessaires à leur tâche du moment, revus à intervalles réguliers plutôt qu’accumulés au fil des années – fait du principe du moindre privilège une réalité opérationnelle, et non une simple intention lors du provisionnement.
Les programmes Identity and Access Management qui traitent les identifiants développeurs comme une catégorie de risque distincte – avec des rotations programmées, des revues de périmètre d’accès et une détection d’anomalies sur l’émission de jetons ROPC – constituent la réponse à l’échelle entreprise à ce mode d’attaque. La plupart des programmes IAM ont été conçus pour gérer les identifiants humains dans des workflows via navigateur. Les identifiants développeurs utilisés dans les outils CLI et pipelines d’automatisation échappent souvent à ces workflows.
Le zéro trust architecture appliqué à l’identité cloud impose une vérification continue à chaque événement d’authentification, et non seulement à l’accès applicatif. Lorsqu’un jeton est émis via ROPC, les principes du zéro trust exigent d’évaluer ce jeton selon des signaux de risque – géolocalisation inhabituelle, réutilisation d’identifiants, vitesse d’accès – avant de servir les ressources. Cette évaluation continue, c’est précisément ce que fournissent les contrôles basés sur les politiques d’accès conditionnel, d’où l’importance du contournement CAP par ROPC.
Le rapport annuel Kiteworks 2026 sur la sécurité et les risques de conformité des données a montré que les failles de gestion des identités et des accès restent l’une des causes principales des violations de données en entreprise. La campagne ROPC documentée par Huntress en est l’illustration parfaite : il ne s’agit pas d’un zero-day sophistiqué, mais d’une faille de protocole héritée que la plupart des organisations n’ont pas traitée dans leur gouvernance des identités. Les organisations qui font transiter du contenu sensible via un Réseau de données privé avec des contrôles d’accès par politiques et une journalisation d’audit immuable au niveau du contenu disposent d’une barrière de confinement supplémentaire : même un identifiant Azure compromis avec accès à la production ne peut atteindre le contenu que les politiques ABAC de Kiteworks restreignent à des identités autorisées spécifiques.
Mesures de remédiation immédiates
La recherche Huntress propose des recommandations concrètes à appliquer sans attendre. Les mesures clés sont :
Bloquer l’authentification héritée au niveau du locataire. Les politiques d’accès conditionnel Azure AD permettent de bloquer les protocoles d’authentification hérités, dont ROPC, pour tous les utilisateurs ou des groupes/applications ciblés. Microsoft propose un modèle de politique dédié. Les organisations qui retardent cette étape à cause de dépendances applicatives héritées doivent auditer ces dépendances et planifier leur migration.
Auditer la couverture des politiques d’accès conditionnel. Cartographiez chaque compte utilisateur et application par rapport aux politiques CAP qui s’y appliquent. Identifiez les failles – applications sans CAP, comptes exclus des exigences MFA, comptes de service avec accès CLI contournant l’accès conditionnel. Chaque faille représente un point d’exposition ROPC potentiel.
Renouveler les identifiants des comptes ayant accès à Azure CLI. Dans la campagne Huntress, 78 comptes ont été authentifiés via ROPC avant détection. Les organisations qui ne peuvent exclure une exposition doivent renouveler les identifiants de tous les comptes développeurs ayant un accès CLI ou programmatique à Azure.
Activer la journalisation des connexions pour les événements ROPC. Les journaux de connexion Azure AD enregistrent les événements d’authentification, y compris hérités. Configurer des alertes SIEM sur les événements d’authentification ROPC permet d’anticiper de futures tentatives de spraying – et d’établir la base de journaux d’audit nécessaire à la réponse aux incidents.
Mettre en place une détection d’anomalies sur l’émission de jetons. Les demandes de jetons ROPC provenant de plages IP, de zones géographiques ou à des horaires inhabituels sont des signaux détectables. Les outils de protection d’identité qui évaluent le risque des événements d’authentification peuvent signaler les tentatives de spraying ROPC avant que les compromissions ne se multiplient. Le tableau de bord RSSI offre aux responsables sécurité une visibilité en temps réel sur les accès au contenu sur tous les canaux gouvernés – pour que toute activité anormale après compromission d’identifiants soit détectée avant de devenir un incident à déclarer.
Pour en savoir plus sur la façon dont Kiteworks gère la gouvernance des identités, les contrôles d’accès et la mauvaise configuration de la sécurité cloud dans les environnements réglementés, réservez votre démo personnalisée dès maintenant.
Foire aux questions
Le flux Resource Owner Password Credentials (ROPC) est un mécanisme d’authentification OAuth 2.0 hérité qui transmet directement les identifiants utilisateur d’une application au fournisseur d’identité via une requête POST, contournant l’authentification par redirection navigateur utilisée par les flux modernes. Comme les identifiants transitent par l’application et non par l’interface d’authentification du fournisseur d’identité, les notifications MFA ne peuvent pas être injectées dans le flux et les évaluations d’accès conditionnel ne s’appliquent pas. Microsoft a déprécié ROPC en raison de ces limites de sécurité, mais le protocole reste fonctionnel dans la plupart des locataires Azure pour assurer la rétrocompatibilité avec les applications héritées. Huntress a documenté l’utilisation de ce flux par des attaquants pour mener 81 millions de tentatives de password spraying sur les points d’accès Azure CLI en 2026, compromettant 78 comptes sans déclencher la moindre notification MFA. La mauvaise configuration de la sécurité ne réside pas dans la MFA elle-même, mais dans la persistance d’un chemin d’authentification qui la contourne. Les organisations soumises à des obligations de conformité réglementaire – HIPAA, CMMC, RGPD, FINRA – doivent considérer la disponibilité de ROPC dans leur locataire Azure comme une faille de conformité, car les chemins d’authentification hérités non surveillés compromettent la documentation des contrôles d’accès exigée par ces cadres.
Une attaque de password spraying Azure CLI utilisant ROPC suit les étapes suivantes. Les attaquants obtiennent ou compilent une liste d’identifiants Azure AD valides – généralement issus de bases de données de violations précédentes, de campagnes de phishing ou de credential stuffing. Ils soumettent ensuite ces identifiants au point d’accès ROPC d’Azure AD via des requêtes d’authentification Azure CLI. Si les identifiants sont valides et qu’aucune politique d’accès conditionnel ne bloque le flux ROPC pour ce compte, Azure AD délivre un jeton d’accès sans déclencher la MFA. L’attaquant utilise alors ce jeton pour exécuter des commandes Azure CLI sur les ressources Azure de la victime. L’attaque peut être détectée via la surveillance SIEM des événements de connexion hérités dans les journaux Azure AD, mais uniquement si la journalisation est activée et les alertes configurées. Les principes du zéro trust architecture imposent une vérification continue lors de l’émission du jeton – y compris une évaluation du risque pour les requêtes d’authentification héritées – ce qui offre une couverture de détection que la MFA seule ne garantit pas. Un plan de réponse aux incidents documenté, couvrant explicitement les scénarios de compromission ROPC – avec les étapes de revue des journaux d’activité Azure et la séquence de rotation des identifiants – fournit aux équipes sécurité un chemin défini de la détection au confinement.
Une politique d’accès conditionnel (CAP) dans Azure AD définit les conditions de réussite de l’authentification – exiger la MFA depuis certaines localisations, bloquer les connexions à risque ou restreindre l’accès aux appareils conformes. Bien configurées et ciblées, les CAP rendent les attaques de password spraying largement inefficaces, car même des identifiants valides ne permettent pas de s’authentifier sans satisfaire aux conditions de la politique. L’attaque ROPC contourne les CAP car leur application se déclenche lors des connexions interactives ; les requêtes de jeton ROPC ne génèrent pas le même flux d’événements de connexion. De plus, de nombreuses organisations prévoient des exceptions CAP pour les outils développeur, les pipelines d’automatisation et les applications héritées nécessitant une authentification compatible ROPC. Ces exceptions créent les failles exploitées par la campagne Huntress. Les audits Identity and Access Management qui cartographient précisément la couverture des protocoles d’authentification – et pas seulement des applications – sont nécessaires pour identifier ces failles. L’application de contrôles d’accès au niveau du contenu – et non uniquement au niveau de l’identité – offre une seconde barrière d’application qui reste efficace même lorsqu’une faille d’authentification permet l’émission d’un jeton.
Exiger la MFA dans Azure AD signifie que les flux d’authentification interactifs déclenchent un défi MFA avant l’émission des jetons. Bloquer l’authentification héritée signifie qu’Azure AD rejette toute demande de jeton utilisant des protocoles d’authentification hérités (dont ROPC), quel que soit la validité des identifiants. Ce sont deux contrôles distincts aux effets différents. La MFA seule ne protège pas contre les attaques ROPC, car ROPC contourne le flux interactif où la MFA s’applique. Bloquer l’authentification héritée stoppe les requêtes de jeton ROPC avant même l’évaluation des identifiants, empêchant l’attaque au niveau du protocole. Microsoft recommande de bloquer l’authentification héritée comme configuration de sécurité de base, et Azure AD propose un modèle CAP dédié à cet usage. Les organisations doivent appliquer les deux contrôles : exiger la MFA pour toute authentification interactive et bloquer les protocoles d’authentification hérités pour tous les comptes et applications ayant migré vers les flux modernes. Le contrôle d’accès basé sur les rôles limitant les droits développeurs au strict nécessaire réduit l’impact de toute faille d’authentification héritée persistante. Les programmes de gestion des risques tiers doivent vérifier que les prestataires et fournisseurs de services managés opérant dans l’environnement Azure ont bien bloqué l’authentification héritée dans leurs propres outils d’administration – un compte MSP avec identifiants CLI accessibles via ROPC crée la même exposition qu’un compte développeur interne.
Les organisations qui pensent avoir été ciblées par une campagne de password spraying ROPC Azure CLI doivent agir immédiatement sur cinq points. Premièrement : extraire les journaux de connexion Azure AD et filtrer les événements d’authentification héritée sur les 90 derniers jours – les demandes de jeton ROPC apparaissent comme des connexions héritées. Deuxièmement : identifier les comptes ayant réussi une authentification héritée et examiner leurs journaux d’activité Azure pour détecter tout accès non autorisé. Troisièmement : renouveler les identifiants de tous les comptes ayant accès à Azure CLI, qu’une authentification ROPC soit confirmée ou non. Quatrièmement : mettre en place une politique d’accès conditionnel bloquant l’authentification héritée pour tous les comptes, ou a minima pour ceux disposant d’un accès CLI ou API programmatique. Cinquièmement : revoir et supprimer toutes les exceptions CAP pour les outils développeur et comptes de service d’automatisation. Il convient ensuite d’établir une base de journaux d’audit complète et de configurer des alertes SIEM sur les futurs événements d’authentification ROPC. Le processus de réponse aux incidents doit documenter les constats pour toute obligation de notification de conformité réglementaire applicable. Les organisations gérant des données réglementées – informations médicales protégées (PHI), CUI, informations personnelles identifiables (PII) – doivent en outre évaluer si des comptes de stockage ou dépôts de données accessibles via les identifiants Azure compromis contiennent du contenu nécessitant une notification de violation selon les cadres applicables.
Ressources complémentaires
- Article de blog
Comment concevoir un workflow de transfert sécurisé de fichiers pour les fournisseurs et sous-traitants tiers - Article de blog
L’importance de la gestion des risques fournisseurs pour les RSSI - Article de blog
Comment protéger la propriété intellectuelle lors de collaborations avec des tiers externes - Article de blog
Contrer les menaces grâce à la sécurité et à la gestion des risques de la supply chain - Article de blog
Violations de données chez les partenaires : votre sécurité dépend de votre maillon le plus faible