L’attaque ConsentFix v3 automatise l’abus du consentement OAuth Azure à grande échelle : un opérateur envoie un e-mail piégé qui invite la victime à autoriser une application Microsoft 365, et l’attaquant gagne un accès persistant à la boîte mail, OneDrive et Teams sans jamais voler de mot de passe. Pour les PME-ETI, ce vecteur contourne la MFA et les EDR classiques, parce que rien n’est techniquement « cassé » : c’est l’utilisateur qui clique sur « Accepter ». Voici un tutoriel concret pour durcir Azure contre cette menace en moins d’une heure.
Pourquoi ConsentFix v3 cible le consentement OAuth Azure
La campagne ConsentFix v3 documentée par BleepingComputer le 2 mai 2026 industrialise une technique connue sous le nom d’illicit consent grant attack. Le scénario typique :
- Un e-mail prétend partager un document depuis un partenaire ou une source RH.
- Le lien redirige vers
login.microsoftonline.com— l’URL est légitime. - La victime est invitée à autoriser une application tierce malveillante (souvent nommée pour ressembler à un produit Microsoft).
- Une fois le consentement OAuth accordé, l’attaquant obtient un refresh token valable des semaines, indépendant du mot de passe.
Ce consentement OAuth Azure détourné échappe à la MFA, ne déclenche pas d’alerte de connexion suspecte et survit à un changement de mot de passe. C’est pour cela que la version 3 de ConsentFix est particulièrement dangereuse : elle automatise la création d’apps multi-tenant, l’envoi des leurres et l’exfiltration immédiate.
Étape 1 : restreindre le consentement OAuth Azure pour les utilisateurs
L’action la plus efficace en sécurité Azure est de retirer aux utilisateurs standards le droit de consentir à des applications tierces. Dans le portail Microsoft Entra ID (anciennement Azure AD) :
- Aller dans Identity → Applications → Enterprise applications → Consent and permissions → User consent settings.
- Choisir Do not allow user consent ou Allow user consent for apps from verified publishers, for selected permissions.
- Configurer un admin consent workflow pour que les demandes légitimes remontent à un administrateur.
Cette seule mesure neutralise la majorité des kits ConsentFix v3, parce qu’aucun utilisateur n’est plus en mesure d’accorder un consentement OAuth Azure sans validation administrateur.
Étape 2 : auditer les applications déjà autorisées
Avant de boucher le futur, il faut vérifier le passé. Connectez-vous à Microsoft Graph PowerShell et exécutez :
Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All"
Get-MgServicePrincipal -All |
Where-Object { $_.Tags -contains "WindowsAzureActiveDirectoryIntegratedApp" } |
Select-Object DisplayName, AppId, PublisherName, SignInAudience |
Export-Csv azure-oauth-apps.csv -NoTypeInformationPassez le CSV en revue et concentrez-vous sur les éditeurs inconnus, les noms qui imitent Microsoft (« Office365 Sync », « SharePoint Connector ») ou les applications multi-tenant non vérifiées. Pour chaque application suspecte, révoquez les permissions accordées et supprimez le service principal :
Remove-MgServicePrincipal -ServicePrincipalId <ID>Étape 3 : activer la détection des consentements à risque
Microsoft Defender for Cloud Apps détecte les schémas de consentement OAuth Azure anormaux. Activez les politiques :
- Misleading OAuth app name — applications qui imitent un éditeur connu.
- Misleading publisher name — publishers proches phonétiquement de Microsoft, Google, Atlassian.
- OAuth app with high-privilege permissions — alerte sur
Mail.ReadWrite,Files.ReadWrite.All,offline_access.
Côté SIEM, exportez les événements Add OAuth2PermissionGrant et Consent to application du journal Microsoft Entra vers votre plateforme de détection (Wazuh, Sentinel ou Splunk). Une règle simple suffit : alerter si un nouveau consentement implique Mail.Read et offline_access en moins de 24 heures après la création de l’application.
Étape 4 : former les utilisateurs au piège du « cliquer pour accepter »
La cybersécurité PME-ETI ne tient pas sans sensibilisation. Trois messages clés à diffuser :
- Une boîte de consentement Microsoft légitime n’arrive jamais sans demande métier explicite.
- Aucune application ne devrait demander
Mail.ReadWriteouoffline_accesssans validation IT. - En cas de doute, ne pas cliquer sur « Accepter » et signaler immédiatement à l’IT — un consentement accordé est plus difficile à révoquer qu’à refuser.
Un exercice de phishing OAuth simulé tous les six mois — différent du phishing classique de mot de passe — permet de vérifier que le réflexe est bien acquis.
Étape 5 : limiter la portée des refresh tokens
Même avec un consentement légitime, vous pouvez réduire la durée d’un compromis. Dans Microsoft Entra Conditional Access, configurez :
- Une politique Sign-in frequency à 1 jour pour les profils sensibles.
- Persistent browser session désactivé sur les appareils non gérés.
- Une policy Block legacy authentication pour fermer la porte aux protocoles sans MFA.
Combinées au verrouillage du consentement OAuth Azure, ces règles transforment un compromis ConsentFix v3 en un incident détectable et limité dans le temps, plutôt qu’en un accès silencieux de plusieurs semaines.
Le bon réflexe en 2026
Le consentement OAuth Azure est devenu l’un des points d’entrée préférés des opérateurs de phishing-as-a-service comme ConsentFix v3, parce qu’il contourne les défenses construites autour du mot de passe. Verrouiller le consentement utilisateur, auditer l’existant, instrumenter la détection et former les équipes sont quatre actions à très haut retour pour les PME-ETI. Pour aller plus loin, voyez aussi notre guide sur l’adoption sécurisée de l’IA agentique et nos recommandations sur les agents Workspace OpenAI, qui partagent le même modèle de menace : la délégation d’identité.