L'attaque est élégante dans sa brutalité : un utilisateur clique sur « Autoriser », et c'est terminé. L'attaquant n'a jamais eu besoin de son mot de passe. Il n'a pas déclenché le MFA. Il n'a pas contourné la conditionnelle Azure AD. Il a simplement demandé à la victime de lui ouvrir la porte, et la victime l'a fait, convaincue d'installer un outil de productivité. C'est ce qu'on appelle un illicit consent grant, et c'est l'une des techniques d'intrusion les plus sous-estimées dans les environnements Microsoft 365.
Comment fonctionne l'abus OAuth dans Microsoft 365
OAuth 2.0 est le protocole qui permet à une application tierce d'agir au nom d'un utilisateur, sans que cet utilisateur lui transmette ses identifiants. Dans un usage légitime, c'est ce qui permet à un outil de gestion de projet d'accéder à votre calendrier Outlook ou à votre OneDrive. Le protocole lui-même n'est pas le problème. Le problème, c'est la politique de consentement : par défaut, Microsoft 365 autorise n'importe quel utilisateur à approuver une application tierce demandant des permissions sur ses données.
Un attaquant enregistre une application dans Azure AD (ou via un tenant qu'il contrôle), lui donne un nom rassurant, lui configure les permissions souhaitées, puis envoie un lien de consentement OAuth soigneusement construit à sa cible. Ce lien est généralement délivré par phishing. Quand l'utilisateur clique et approuve, l'application obtient un token d'accès OAuth valide, parfois accompagné d'un refresh token longue durée. Ce token donne accès aux emails, fichiers, contacts et calendriers, selon les permissions demandées, sans aucune authentification supplémentaire.
Les permissions qui font le plus de dégâts
Tout dépend des scopes demandés. Les plus critiques dans ce contexte sont Mail.Read, Mail.ReadWrite, Files.ReadWrite.All et offline_access. Ce dernier est particulièrement dangereux : il permet à l'application de régénérer ses tokens indéfiniment, créant un accès persistant qui survit aux changements de mot de passe et aux révocations de session MFA.
Pourquoi le MFA ne protège pas contre cette attaque
C'est le point que la plupart des équipes IT ratent. Le MFA protège l'authentification de l'utilisateur, pas les tokens que ses applications accumulent. Une fois qu'un token OAuth valide a été émis, l'attaquant l'utilise directement via l'API Microsoft Graph. Il n'interagit plus du tout avec la page de connexion, donc le MFA ne s'applique pas. Même si l'utilisateur change son mot de passe après coup, les tokens restent valides jusqu'à leur expiration ou révocation explicite.
Pour les équipes SOC, cela signifie que les alertes basées sur des tentatives de connexion suspectes ne verront rien. L'attaquant opère depuis une session applicative légitime, avec un token valide, en appelant des endpoints Graph parfaitement normaux.
Politiques de consentement à restreindre en priorité
La première ligne de défense est de ne pas laisser les utilisateurs finaux approuver des applications par eux-mêmes. Dans le portail Azure AD, sous Enterprise Applications > Consent and permissions, il faut passer la politique de consentement utilisateur à « Ne pas autoriser le consentement utilisateur » et centraliser toutes les approbations via un workflow d'administration. Les équipes peuvent configurer un admin consent workflow qui route les demandes vers un administrateur avant toute autorisation.
Ensuite, il faut auditer les applications déjà consenties. Beaucoup d'organisations découvrent lors de cet audit des dizaines d'applications tierces accordées par des utilisateurs au fil des années, dont certaines n'existent plus ou ont changé de propriétaire. L'outil PowerShell Get-AzureADServicePrincipal combiné avec Get-AzureADOAuth2PermissionGrant permet d'extraire cette liste. Pour les équipes qui préfèrent une interface graphique, le portail Entra ID propose une vue des applications d'entreprise filtrée par type de consentement.
Classifier les applications par niveau de risque
Toutes les applications tierces ne se valent pas. Une politique efficace distingue les applications publiées par des éditeurs vérifiés Microsoft (Publisher Verified) des applications non vérifiées. Les secondes méritent un niveau de scrutin bien supérieur, voire un blocage systématique par défaut. Le paramètre permissionGrantPoliciesAssigned dans les politiques de consentement permet de construire cette granularité.
Détecter les abus via Microsoft Purview et l'audit log
Microsoft Purview (anciennement Compliance Center) centralise les journaux d'audit pour les événements Microsoft 365. Pour détecter un illicit consent grant, les événements à surveiller sont Consent to application et Add OAuth2PermissionGrant dans l'audit log unifié. Un consentement accordé par un utilisateur standard à une application non répertoriée dans votre catalogue interne doit générer une alerte immédiate.
Les requêtes KQL dans Microsoft Sentinel permettent d'automatiser cette détection. On cherche typiquement des patterns comme : un utilisateur qui consent à une application pour la première fois, sur une plage horaire inhabituelle, depuis une IP géolocalisée hors du périmètre habituel de l'entreprise. Ce type de scénario de détection d'accès anormal est précisément ce que les équipes SOC doivent être capables de construire et de tester en environnement contrôlé avant d'être confrontées à un incident réel.
Surveiller l'activité post-consentement
La détection ne s'arrête pas au moment du consentement. Une fois l'application approuvée, l'activité via Microsoft Graph génère des traces dans les journaux de connexion Azure AD, sous la rubrique « Service Principal Sign-ins ». Des accès massifs à des boîtes mail via Graph, surtout en dehors des heures ouvrées, constituent un signal fort. L'audit de l'activité SharePoint et Exchange Online via Purview permet de corréler ces accès avec des téléchargements de fichiers inhabituels.
Ce que les équipes Red Team testent (et que le Blue Team doit anticiper)
Les équipes offensives utilisent des frameworks comme GraphRunner ou des scripts Python construits autour de MSAL pour simuler exactement ce type d'attaque en environnement de test. Le flux complet — enregistrement d'une fausse application, envoi du lien de consentement, exploitation du token pour exfiltrer des emails — peut être reproduit en moins d'une heure dans un tenant de test. Si votre équipe n'a jamais simulé ce scénario, elle ne sait pas si ses détections fonctionnent réellement. Un parcours de labs dédié aux attaques sur identité cloud permet de pratiquer ce type d'exercice dans un environnement isolé, sans risque pour le SI de production.
La bonne nouvelle : cette attaque laisse des traces. Le consentement est logué, l'activité Graph est logué, les refresh tokens ont une durée de vie configurable. La mauvaise nouvelle : sans politique de consentement restrictive et sans règles de détection actives, ces traces ne servent à rien jusqu'à ce qu'il soit trop tard.
Questions fréquentes
Un utilisateur peut-il révoquer lui-même le consentement accordé à une application OAuth ?
Oui. Depuis le portail myapps.microsoft.com, un utilisateur peut voir et révoquer les applications auxquelles il a accordé des permissions. Mais cette révocation est rarement connue des utilisateurs et ne garantit pas la suppression immédiate des tokens actifs côté attaquant si le refresh token a déjà été utilisé pour générer des access tokens en cache.
Le passage à une politique de consentement admin-only casse-t-il les outils déjà en place ?
Non, à condition de gérer la transition correctement. Les applications déjà consenties continuent de fonctionner. Seules les nouvelles demandes de consentement seront routées vers un administrateur. L'impact opérationnel est donc limité, mais il faut prévoir un processus de traitement des demandes pour ne pas créer un goulot d'étranglement.
Le MFA empêche-t-il vraiment les illicit consent grants ?
Non. C'est précisément la particularité de cette attaque : elle exploite le protocole OAuth pour obtenir un accès sans passer par l'authentification interactive. Le MFA protège la connexion de l'utilisateur, pas les tokens émis par des applications tierces après consentement.
Quels journaux activer en priorité pour détecter ces attaques dans Microsoft 365 ?
En priorité : l'audit log unifié dans Microsoft Purview avec les événements « Consent to application » et « Add OAuth2PermissionGrant », et les journaux de connexion des service principals dans Azure AD. Sans ces deux sources activées et exportées vers un SIEM, la détection est pratiquement impossible après le fait.