OAuth Consent Phishing : comment les applications malveillantes contournent le vol de mot de passe

L’OAuth consent phishing est une attaque d’identité où un utilisateur ou un administrateur est amené à accorder des permissions à une application OAuth malveillante. L’attaquant n’a pas besoin du mot de passe de l’utilisateur une fois le consentement accordé. L’application peut accéder à Microsoft 365 ou à d’autres ressources protégées selon les permissions reçues, ce qui rend ce scénario différent du phishing de mots de passe, du password spraying ou de la fatigue MFA.

Le périmètre de cet article est Microsoft Entra ID, Microsoft 365 et le consentement applicatif basé sur OAuth. Toute connexion malveillante n’est pas automatiquement un cas de consent phishing. Ici, le sujet central est le consentement lui-même : ce que l’application reçoit, comment les défenseurs peuvent le voir, comment le supprimer et comment éviter que le même chemin d’attaque réapparaisse.

Qu’est-ce que l’OAuth Consent Phishing ?

L’OAuth consent phishing abuse d’un modèle de consentement légitime. Microsoft décrit le consent phishing comme une attaque qui trompe les utilisateurs pour qu’ils accordent des permissions à des applications cloud malveillantes. L’écran de consentement affiche les permissions reçues par l’application, mais un nom crédible, un logo familier ou un prétexte métier réaliste peut pousser un utilisateur ou un administrateur à approuver un accès non souhaité.

Dans Microsoft identity platform, OAuth permet à une application de demander l’accès à une ressource protégée. La RFC 6749 définit OAuth 2.0 comme un framework qui permet à une application tierce d’obtenir un accès limité à un service HTTP, soit au nom d’un propriétaire de ressource, soit pour son propre compte. Microsoft Entra ID implémente ce modèle pour des ressources comme Microsoft Graph, Exchange Online, SharePoint Online et d’autres API intégrées à la plateforme d’identité Microsoft.

Limites du périmètre

Le point important pour les défenseurs est que le consent phishing cible l’autorisation, pas seulement l’authentification. Dans un incident de phishing de mot de passe, l’équipe vérifie généralement si des identifiants ont été volés, si la MFA a été satisfaite et si une session suspecte existe. Dans un incident d’OAuth consent phishing, il faut aussi vérifier si une application a reçu un grant durable qui reste valide après la session interactive initiale.

Ce risque est proche de celui décrit dans Azure App Registrations: Over-Privileged Tenant Apps, mais le chemin d’attaque est différent. Les applications légitimes sur-privilégiées relèvent souvent d’un problème de gouvernance interne. L’OAuth consent phishing implique une application malveillante ou trompeuse qui obtient un accès via un écran de consentement.

Comment fonctionne l’OAuth Consent Phishing

La chaîne d’attaque commence par une requête d’autorisation OAuth normale. Un utilisateur suit un lien ou ouvre une application qui l’envoie vers Microsoft identity platform. L’utilisateur s’authentifie si nécessaire. Si les permissions demandées n’ont pas déjà reçu de consentement, Microsoft Entra affiche une invite de consentement. Cette invite contient les permissions demandées et les informations éditeur.

État de consentement, pas seulement état de connexion

Si l’utilisateur ou l’administrateur approuve la demande, Microsoft Entra enregistre un grant pour l’application. Pour les permissions Microsoft Graph déléguées, le résultat du consentement est représenté par un OAuth2PermissionGrant. Pour les permissions applicatives, le résultat est représenté par un appRoleAssignment. Ces deux objets sont importants, car ce sont eux que les défenseurs doivent énumérer, examiner et supprimer pendant le nettoyage.

Une application malveillante n’a pas besoin de demander toutes les permissions en une seule fois. Microsoft documente le consentement dynamique comme un cas où une application demande de nouvelles permissions au moment de l’exécution. Cela signifie que la revue des consentements ne doit pas être uniquement un contrôle d’onboarding. Un tenant peut être propre lors d’une revue initiale, puis recevoir plus tard une demande d’accès plus large si l’application est codée pour demander des scopes supplémentaires.

Nuance autour d’offline_access

Le scope offline_access change aussi le modèle de défense. Microsoft documente offline_access comme donnant à une application l’accès aux ressources au nom de l’utilisateur pendant une durée prolongée. Sur la page de consentement, cette permission apparaît comme le maintien de l’accès aux données auxquelles l’application a déjà reçu accès. Microsoft indique également que si une permission déléguée est accordée, offline_access est implicitement accordé, et que les refresh tokens ont une durée de vie longue. Cela ne veut pas dire que l’attaquant dispose d’un accès permanent. Cela veut dire que la réponse à incident doit inclure la suppression des grants et le nettoyage des tokens ou sessions, pas uniquement la réinitialisation du mot de passe.

C’est pour cela que l’OAuth consent phishing est proche, mais distinct, d’autres attaques d’identité Entra. Device Code Phishing: How OAuth Device Flow Compromises Entra ID Accounts abuse d’un autre flux OAuth. Les deux attaques s’appuient sur OAuth, mais le device code phishing consiste à autoriser une session via le flux device code, alors que le consent phishing consiste à accorder des permissions à une application.

Permissions déléguées vs permissions applicatives

La distinction technique la plus importante est celle entre permissions déléguées et permissions applicatives.

Accès délégué

Les permissions déléguées sont utilisées quand une application agit au nom d’un utilisateur connecté. Microsoft les décrit comme des permissions permettant à l’application d’agir pour le compte de l’utilisateur, sans pouvoir accéder à ce que l’utilisateur lui-même ne pourrait pas accéder. Si un utilisateur accorde une permission déléguée permettant de lire le courrier, l’accès de l’application dépend de ce que cet utilisateur peut lire. Si un administrateur privilégié accorde des permissions déléguées pendant qu’il est connecté, l’impact peut être beaucoup plus élevé parce que les privilèges de l’utilisateur sont plus élevés.

Accès app-only

Les permissions applicatives, aussi appelées app roles ou permissions app-only, sont utilisées lorsqu’aucun utilisateur connecté n’est présent. Microsoft décrit l’accès app-only comme une application qui agit avec sa propre identité. Les permissions applicatives peuvent permettre un accès large aux données du tenant via Microsoft Graph ou une autre API de ressource. Microsoft indique qu’en général seul un administrateur, ou le propriétaire du service principal d’une API, peut consentir aux permissions applicatives exposées par cette API.

Triage par type de permission

Cette distinction pilote la priorité d’investigation. Un grant délégué suspect accordé par un utilisateur peu privilégié peut exposer la boîte aux lettres, les fichiers ou les ressources accessibles par cet utilisateur. Une permission applicative suspecte peut avoir une portée tenant-wide selon la permission et l’API de ressource. Microsoft utilise par exemple Files.Read.All pour illustrer la différence : en délégué, Files.Read.All permet à l’application de lire les fichiers auxquels l’utilisateur peut accéder personnellement ; en applicatif, Files.Read.All peut permettre de lire n’importe quel fichier du tenant via Microsoft Graph une fois accordée.

Il ne faut pas fusionner ces deux cas dans un vague risque d’application OAuth. L’objet de nettoyage, le périmètre d’impact, le chemin d’approbation et la validation sont différents.

Pourquoi la MFA ne bloque pas à elle seule l’abus de consentement

La MFA reste importante. Elle réduit la probabilité qu’un attaquant puisse se connecter comme l’utilisateur, approuver des prompts à sa place ou effectuer d’autres actions interactives. Le problème est plus précis : la MFA ne rend pas automatiquement inoffensif un grant OAuth déjà accordé.

Une fois qu’une application malveillante dispose d’un grant délégué valide, elle peut demander des tokens selon ce grant et selon le contexte utilisateur/ressource. Une fois qu’une application dispose de permissions applicatives, elle peut opérer sans utilisateur connecté pour les données couvertes par ces permissions. Les stratégies Conditional Access et MFA peuvent toujours influencer l’émission de tokens dans certains scénarios, mais l’existence d’un consent grant doit être investiguée directement.

C’est la même leçon générale que dans Azure Identity Security: Why MFA Alone Is Not Enough. La MFA est un contrôle. Elle ne remplace pas la gouvernance du consentement applicatif, la revue des permissions, la supervision des journaux d’audit, l’évaluation de l’éditeur ou la révocation des grants suspects. Si votre équipe suit aussi les attaques de social engineering par notifications push, MFA Fatigue: Detection and Prevention for Microsoft Entra ID couvre un scénario distinct qui peut survenir avant ou en parallèle d’un abus de consentement.

L’erreur pratique consiste à clôturer l’incident après une réinitialisation de mot de passe ou après avoir confirmé que la MFA était activée. Dans un cas de consent phishing, c’est incomplet. La réponse doit déterminer si un service principal existe, quels grants lui sont attachés, quels utilisateurs ont consenti, si un admin consent a été accordé et si l’application a été désactivée, supprimée ou empêchée de recevoir de nouveaux grants.

La chaîne d’attaque

Une chaîne réaliste d’OAuth consent phishing comporte plusieurs étapes. Le leurre exact peut varier, mais les points de contrôle restent constants.

1. L’attaquant prépare ou contrôle une application capable de demander des permissions Microsoft identity platform.
2. Un utilisateur ou un administrateur reçoit une URL d’autorisation qui affiche une expérience de connexion et de consentement hébergée par Microsoft.
3. L’écran de consentement liste les permissions et les informations éditeur. L’utilisateur ou l’administrateur approuve la demande.
4. Microsoft Entra enregistre le grant. Les permissions déléguées apparaissent comme OAuth2PermissionGrant; les permissions applicatives apparaissent comme appRoleAssignment.
5. L’application utilise des access tokens, et potentiellement des refresh tokens lorsqu’ils sont disponibles, pour appeler des API comme Microsoft Graph selon les permissions accordées.
6. L’attaquant conserve l’accès jusqu’à ce que les défenseurs révoquent les grants, désactivent ou suppriment le service principal malveillant lorsque c’est approprié, bloquent le re-consentement, invalident les sessions/tokens pertinents ou que Microsoft désactive une application qui viole ses conditions de service.

Ce que ce n’est pas

Cette chaîne n’est pas du password spraying, où l’attaquant teste des identifiants contre de nombreux comptes. Ce n’est pas du Kerberoasting, où la cible est du matériel de ticket de service Kerberos dans Active Directory. Ce n’est pas non plus du device code phishing OAuth classique, où l’attaquant pousse l’utilisateur à finaliser une autorisation via device code. Ces distinctions comptent, car la télémétrie et la remédiation ne sont pas les mêmes.

Pour les défenseurs, l’objectif de la chaîne est d’identifier l’état durable. Une connexion suspecte s’investigue via les sign-in logs. Un grant de consentement suspect s’investigue via les objets applicatifs, les permission grants, les journaux d’audit et les contrôles de gouvernance applicative.

Détection

Aucun événement Microsoft Entra unique ne prouve à lui seul un OAuth consent phishing. Un administrateur légitime peut consentir à une application légitime. Un utilisateur légitime peut approuver une permission déléguée à faible risque. La détection exige une corrélation entre activité de consentement, métadonnées d’application, permissions, contexte utilisateur et comportement API ultérieur.

Pivots dans les journaux d’audit

Commencez par les journaux d’audit Microsoft Entra. Microsoft documente les activités suivantes dans le service Core Directory et la catégorie ApplicationManagement :

Questions de corrélation

Utilisez ces événements comme pivots, pas comme verdict final. Une détection utile pose ces questions :

• L’application vient-elle d’être ajoutée au tenant ?
• L’éditeur est-il vérifié, et correspond-il au besoin métier annoncé ?
• Quelles permissions ont été demandées, et s’agit-il de permissions à faible risque ou de permissions sensibles sur les données ?
• L’acteur est-il un utilisateur standard, un administrateur, un compte break-glass ou un compte hors de son comportement normal ?
• Le consentement a-t-il été accordé juste après une connexion suspecte, un signal de déplacement impossible, un utilisateur à risque ou un signalement de phishing ?
• L’application a-t-elle commencé à appeler Microsoft Graph, Exchange, SharePoint ou d’autres API d’une manière incompatible avec un workflow approuvé ?
• Plusieurs utilisateurs ont-ils autorisé la même application inhabituelle ?

Defender for Cloud Apps peut ajouter une couche supplémentaire lorsqu’il est disponible. Microsoft documente des stratégies OAuth app capables d’alerter sur des applications correspondant à certains critères : niveau de permission élevé, nombreux utilisateurs ayant autorisé l’application, usage peu commun, noms trompeurs, noms d’éditeur trompeurs ou consentement OAuth potentiellement malveillant. Traitez ces alertes comme des signaux de priorisation et inspectez tout de même le service principal et les grants sous-jacents.

Une détection mature surveille aussi la dérive de gouvernance. Si les paramètres de consentement utilisateur sont assouplis, si les app consent policies changent ou si les reviewers du workflow admin consent sont retirés, le tenant devient plus facile à abuser. Ces changements ne prouvent pas à eux seuls qu’une application est malveillante, mais ils réduisent la force de contrôle autour des futures demandes de consentement. Associez cette surveillance à How to Audit Microsoft Entra ID Security pour revoir le consentement applicatif avec Conditional Access, les rôles privilégiés, les utilisateurs à risque et les paramètres d’identité tenant-wide.

Pour les investigations hybrides, gardez une frontière claire : cet article se concentre sur l’activité d’audit Entra, mais Active Directory Monitoring: Security Event IDs That Matter peut aider les équipes de réponse à incident à corréler l’activité d’identité on-premises lorsque le même utilisateur ou administrateur est impliqué.

Remédiation

La remédiation suit deux axes : supprimer l’accès malveillant confirmé, puis fermer le chemin de consentement qui l’a permis.

Supprimer les grants existants

Identifiez d’abord l’objet application et le service principal dans Enterprise Applications. Examinez les onglets Admin consent et User consent pour les permissions accordées. Microsoft documente que les administrateurs peuvent révoquer les permissions organisation-wide dans l’onglet Admin consent, tandis que les grants de user consent peuvent nécessiter Microsoft Graph API ou PowerShell. Pour un nettoyage complet, énumérez à la fois les permissions déléguées et les permissions applicatives.

Pour les permissions déléguées, supprimez les objets OAuth2PermissionGrant suspects. Pour les permissions applicatives, supprimez les entrées appRoleAssignment suspectes. La documentation Microsoft sur la revue des permissions fournit des chemins Graph et PowerShell pour les deux cas. Si des utilisateurs ou groupes étaient assignés à l’application, examinez et supprimez ces assignations dans le cadre du containment.

Contenir le service principal

Désactivez ou supprimez ensuite le service principal lorsque l’application est confirmée comme malveillante ou non autorisée. Soyez prudent avec les applications qui ont à la fois des usages suspects et légitimes : supprimer un service principal peut casser des workflows métier. Si Microsoft a désactivé une application OAuth pour violation des conditions de service, Microsoft documente que les nouvelles demandes de tokens et de refresh tokens sont refusées, mais que les access tokens existants restent valides jusqu’à leur expiration. C’est pourquoi les répondants ne doivent pas dépendre d’une seule action.

Traitez ensuite les tokens et sessions. Pour un abus délégué, révoquez les refresh tokens ou invalidez les sessions utilisateur lorsque c’est approprié. Pour un abus app-only, concentrez-vous sur la suppression des app role assignments, la suppression des credentials du service principal s’il est contrôlé par le tenant, la désactivation du service principal et la validation qu’aucun grant app-only ne reste. Une réinitialisation de mot de passe peut être pertinente si l’utilisateur a aussi été phishé, mais elle ne supprime pas un grant OAuth à elle seule.

Durcir les consentements futurs

Enfin, durcissez la gouvernance du consentement :

• Revoyez les paramètres de consentement utilisateur et évitez un consentement large par les utilisateurs pour les applications et permissions qui devraient exiger une revue admin.
• Utilisez les app consent policies pour restreindre ce à quoi les utilisateurs peuvent consentir selon des critères comme le statut d’éditeur vérifié et le risque des permissions.
• Activez et configurez l’admin consent workflow afin que les utilisateurs puissent demander l’accès aux applications nécessitant une approbation au lieu de contourner la revue par des canaux informels.
• Limitez les personnes pouvant accorder un tenant-wide admin consent. Microsoft recommande les rôles les moins privilégiés et rappelle que Global Administrator est un rôle hautement privilégié.
• Évaluez la publisher verification comme un signal, pas comme une approbation de sécurité complète. Microsoft indique explicitement qu’un badge d’éditeur vérifié n’implique pas des critères de qualité applicative, des certifications, de la conformité ou des bonnes pratiques de sécurité.
• Utilisez les stratégies OAuth app de Defender for Cloud Apps lorsque disponibles pour alerter sur les applications risquées, peu communes, très privilégiées ou potentiellement malveillantes.

Ne créez pas une règle globale qui bloque toutes les applications tierces sans processus d’exception. Cela pousse généralement les utilisateurs vers des contournements non maîtrisés. L’approche la plus solide est un chemin de consentement contrôlé : permissions déléguées à faible risque autorisées, revue admin pour les scopes délégués sensibles et les permissions applicatives, et revue périodique des applications déjà approuvées.

Validation après nettoyage

La validation est l’endroit où beaucoup de réponses au consent phishing échouent. Un ticket ne doit pas être fermé parce que l’application a disparu d’une page visible du portail. Il doit être fermé parce que les chemins d’autorisation durables ont été vérifiés.

Checklist de clôture

Utilisez cette séquence de validation :

1. Confirmer que le service principal suspect est désactivé ou supprimé lorsque l’application est confirmée malveillante.
2. Confirmer qu’aucun OAuth2PermissionGrant délégué suspect ne reste pour le service principal client.
3. Confirmer qu’aucun appRoleAssignment suspect ne reste pour les permissions app-only.
4. Confirmer que les assignations utilisateur et groupe à l’application ont été supprimées si elles contribuaient à l’accès.
5. Confirmer que les journaux d’audit montrent les événements de suppression attendus, comme la suppression de grants délégués ou d’app role assignments.
6. Confirmer que les paramètres de consentement utilisateur, les app consent policies et l’admin consent workflow correspondent au modèle de contrôle prévu.
7. Confirmer que les utilisateurs concernés ont eu leurs sessions/tokens révoqués lorsque l’accès délégué était impliqué.
8. Confirmer que Defender for Cloud Apps ou app governance, si déployés, ne montrent plus l’application comme autorisée ou active.
9. Confirmer que les nouvelles tentatives d’accorder le même chemin de permissions exigent le workflow admin attendu ou sont bloquées par policy.

Pour les investigations à l’échelle du tenant, associez ce contrôle à Azure Identity Protection: Blocking Leaked Credentials. Le consent phishing n’est pas la même chose qu’un identifiant compromis, mais les signaux de risky user et risky sign-in peuvent aider à déterminer si l’utilisateur qui a accordé le consentement était aussi compromis.

Comment EtcSec détecte les expositions liées

EtcSec doit traiter l’OAuth consent phishing comme un pattern d’exposition entre inventaire applicatif, gouvernance d’identité et capacité de monitoring. Le contrôle utile n’est pas seulement de savoir si une application malveillante existe. Le contrôle utile est de savoir si le tenant rendrait un consentement malveillant facile à obtenir, difficile à détecter ou lent à révoquer.

Signaux d’exposition

Les checks pertinents incluent :

• Applications Enterprise avec permissions Microsoft Graph déléguées larges ou permissions app-only larges.
• Applications autorisées par de nombreux utilisateurs sans owner clair ou justification métier.
• Applications sans éditeur vérifié, surtout lorsqu’elles demandent des permissions sensibles.
• Paramètres de consentement utilisateur permettant aux utilisateurs d’approuver plus que des permissions déléguées à faible risque.
• Admin consent workflow absent ou faible.
• Absence de revue récurrente des admin consents et user consents.
• Permissions applicatives incohérentes avec l’objectif déclaré de l’application.
• Utilisateurs privilégiés ayant consenti à des applications tierces depuis des appareils ou contextes moins fiables.
• Gaps de monitoring autour de Consent to application, Add delegated permission grant et Add app role assignment to service principal.

Ce sujet est adjacent à Azure Conditional Access: MFA Bypass With Stolen Passwords, mais la remédiation est différente. Conditional Access reste une partie de la défense d’identité, mais le durcissement du consentement OAuth exige gouvernance applicative, revue des permissions, consent policies et nettoyage des service principals.

Contrôles associés

L’OAuth consent phishing se gère mieux comme un ensemble de contrôles que comme un simple interrupteur.

Ces contrôles réduisent aussi l’exposition liée aux applications légitimes sur-permissionnées. La gouvernance du consentement devient donc une activité normale des opérations de sécurité Entra, pas seulement une réponse après signalement de phishing.

Références primaires

Les claims techniques de cet article s’appuient sur la documentation primaire et les standards suivants :

• Microsoft Learn: Protect against consent phishing
• Microsoft Learn: Permissions and consent overview
• Microsoft Learn: Scopes and permissions in the Microsoft identity platform
• Microsoft Learn: Configure the admin consent workflow
• Microsoft Learn: Manage app consent policies
• Microsoft Learn: Review permissions granted to enterprise applications
• Microsoft Learn: View activity logs of application permissions
• Microsoft Learn: Microsoft Entra audit log activity reference
• Microsoft Learn: Publisher verification
• Microsoft Defender for Cloud Apps: Create policies to control OAuth apps
• RFC 6749: The OAuth 2.0 Authorization Framework
• RFC 6819: OAuth 2.0 Threat Model and Security Considerations