Des chercheurs en sécurité alertent sur une nouvelle technique d’hameçonnage qui permet à des attaquants de prendre le contrôle de comptes Microsoft sans dérober les mots de passe ni contourner directement l’authentification multifacteur.
Cette attaque, connue sous le nom de ConsentFix, exploite la confiance implicite accordée à l’interface de ligne de commande Azure de Microsoft (CLI) et repose sur une interaction utilisateur subtile plutôt que sur des pages de connexion malveillantes.
Il s’agit d’une « … attaque ClickFix native du navigateur qui hameçonne un jeton OAuth sur une application cible en amenant la victime à copier-coller dans une page d’hameçonnage une URL contenant des éléments de clé OAuth », ont déclaré les chercheurs de Push Security.
Cibles de ConsentFix
ConsentFix cible les organisations qui s’appuient sur Microsoft Entra ID, Microsoft 365 et Azure pour gérer les identités et les accès.
Comme l’attaque exploite une application Microsoft propriétaire qui ne peut être ni bloquée ni supprimée, les comptes compromis peuvent passer inaperçus jusqu’à ce que les attaquants commencent à abuser des ressources cloud ou à recenser les données d’annuaire.
Push Security indique que la campagne est active et cible sélectivement des utilisateurs professionnels au moyen d’empoisonnement des moteurs de recherche et de sites web compromis.
En filtrant les victimes selon leur adresse e-mail professionnelle, les attaquants réduisent le bruit et augmentent leurs chances de réussir la prise de contrôle des comptes.
Fonctionnement de l’attaque ConsentFix
L’attaque commence lorsque les victimes sont redirigées depuis les résultats de recherche Google vers des sites web malveillants ou compromis.
Ces sites affichent une fausse vérification Cloudflare Turnstile conçue pour paraître légitime, tout en recueillant les adresses e-mail et en filtrant les visiteurs.
Si l’utilisateur saisit une adresse e-mail personnelle, le site lui demande une adresse professionnelle, afin de ne laisser passer que les comptes d’entreprise.
Une fois une adresse e-mail admissible saisie, les victimes sont invitées à cliquer sur un bouton « Se connecter ». Celui-ci ouvre une page de connexion Microsoft légitime dans un nouvel onglet du navigateur.
Si l’utilisateur est déjà authentifié, il lui suffit de sélectionner son compte dans une liste déroulante pour terminer la connexion sans saisir ses identifiants.
À ce stade, le navigateur redirige vers une URL localhost contenant un code d’autorisation OAuth associé au compte Microsoft de l’utilisateur.
La page d’hameçonnage demande à la victime de recopier cette URL dans le site d’origine — une action qui semble inoffensive, mais qui termine le flux OAuth.
En collant l’URL, la victime accorde à son insu à l’attaquant l’accès à son compte via Azure CLI.
Comme Azure CLI est une application Microsoft propriétaire de confiance, l’attaquant obtient l’accès sans mot de passe, MFA ni invite d’authentification résistante à l’hameçonnage, comme les clés d’accès.
Comment les attaquants détournent Azure CLI
Azure CLI bénéficie d’une confiance implicite au sein de Microsoft Entra ID et est exempté des restrictions standard de consentement OAuth appliquées aux applications tierces.
Il ne nécessite pas d’approbation administrative pour l’octroi d’autorisations et ne peut être bloqué ou désactivé par les administrateurs du locataire.
Ces choix de conception font d’Azure CLI un outil puissant pour les administrateurs légitimes — et une cible idéale pour les attaquants.
Une fois l’accès établi, les adversaires peuvent recenser Azure Active Directory, accéder aux ressources cloud et éventuellement se déplacer vers d’autres systèmes sans déclencher immédiatement d’alertes.
La campagne échappe davantage à la détection grâce au blocage synchronisé des adresses IP, au chargement sélectif de JavaScript et au ciblage conditionnel fondé sur les adresses IP des visiteurs.
Ces mesures empêchent les chercheurs en sécurité et les scanners automatisés d’observer l’intégralité de la chaîne d’attaque au moyen d’une simple analyse d’URL.
Comment se défendre contre ConsentFix
Les attaques de type ConsentFix montrent comment les flux de gestion des identités peuvent être détournés même lorsque des contrôles d’authentification robustes sont en place.
Pour se défendre contre ces techniques, il faut disposer d’une visibilité accrue sur le consentement OAuth, l’utilisation des jetons et les voies d’accès administratives.
- Surveillez les événements d’authentification Azure CLI et considérez les connexions CLI interactives inattendues comme une activité suspecte.
- Activez et examinez régulièrement AADGraphActivityLogs afin de détecter les recensements anormaux de l’annuaire et les connexions non interactives.
- Limitez l’accès à Azure CLI au moyen du contrôle d’accès en fonction des rôles (RBAC) et limitez l’authentification aux administrateurs et développeurs approuvés.
- Verrouillez le consentement des applications OAuth en exigeant une approbation administrative et en réexaminant régulièrement les autorisations accordées aux applications.
- Appliquez l’accès conditionnel et la détection des menaces liées aux identités aux jetons OAuth, notamment au moyen de contrôles fondés sur l’appareil, la localisation et le niveau de risque.
- Réduisez l’exposition en raccourcissant la durée de vie des jetons, en appliquant le principe du moindre privilège aux autorisations d’API et en procédant régulièrement à des réexamens des accès.
Ensemble, ces mesures aident les organisations à améliorer leur visibilité sur l’activité liée aux identités et à réduire le risque d’abus fondés sur OAuth.
Évolution des tactiques dans les attaques visant les identités
ConsentFix illustre une évolution plus large des attaques visant les identités : les adversaires détournent des applications de confiance et des flux de travail conçus pour être pratiques au lieu de dérober directement les identifiants.
À mesure que les plateformes d’identités cloud centralisent davantage l’accès aux systèmes d’entreprise, les autorisations OAuth et les outils propriétaires deviennent des cibles attrayantes en raison de leur large accès et d’un niveau de contrôle souvent moindre.
Cela souligne l’importance des principes zéro confiance, qui partent du principe qu’aucune confiance implicite n’existe et vérifient en continu les accès entre les identités, les applications et les flux de travail.