Phishing par consentement OAuth : détecter les octrois d'applications malveillantes avant l'exfiltration

Réponse courte : le phishing par consentement OAuth n'a pas besoin d'un mot de passe volé. Il pousse un utilisateur à autoriser une application, puis abuse du jeton accordé pour lire des e-mails, des fichiers, des contacts ou des données d'annuaire. La défense repose sur la gouvernance applicative, complétée par la détection des octrois et des usages de jetons suspects.

Les équipes sécurité décrivent souvent le phishing comme un vol d'identifiants. Le phishing par consentement OAuth est plus subtil. La victime ne saisit ses identifiants que sur une page légitime du fournisseur d'identité. Le MFA peut fonctionner. Le résultat final reste une compromission, car la victime accorde à une application contrôlée par l'attaquant la permission d'accéder à ses données.

C'est pourquoi les écrans de consentement comptent. Ce sont des décisions de sécurité déguisées en invites de workflow banales. Les utilisateurs les rencontrent en connectant des outils de productivité, des visionneuses de documents, des applications d'agenda, des extensions de navigateur, des intégrations CRM et des automatisations internes. Les attaquants exploitent cette familiarité.

Les recommandations de Microsoft sur la protection contre le consent phishing insistent sur un point clé : des applications malveillantes peuvent obtenir un accès via le consentement utilisateur, en particulier lorsque les organisations autorisent largement les octrois en libre-service. Dans un environnement fortement SaaS, ce risque n'a rien de théorique.

Comment fonctionne le phishing par consentement

L'attaquant enregistre une application auprès d'un fournisseur d'identité ou compromet une application existante. L'application demande des permissions telles que la lecture de la messagerie, l'accès aux fichiers, le maintien d'un accès hors connexion ou la lecture des informations d'annuaire. L'attaquant envoie ensuite un leurre qui dirige la victime vers le flux d'autorisation.

Le leurre peut prétendre qu'un document nécessite une visionneuse sécurisée, qu'un enregistrement de réunion réclame un plugin, qu'un dossier partagé doit être connecté ou qu'un workflow de conformité impose une réautorisation. La victime clique, s'authentifie et voit une invite de consentement. Si elle accepte, l'attaquant reçoit des jetons pour les portées accordées.

Aucune fausse page de mot de passe n'est nécessaire. Cela rend la détection de phishing traditionnelle beaucoup moins fiable.

Pourquoi l'accès hors connexion est dangereux

La portée offline_access mérite une attention particulière, car elle peut donner accès à des refresh tokens. Un consentement ponctuel peut ainsi se transformer en accès persistant. Même si l'utilisateur ferme son navigateur, l'attaquant peut continuer à utiliser les refresh tokens jusqu'à révocation, expiration ou blocage par la politique.

Les attaquants recherchent la persistance. Avec un accès à la messagerie, ils peuvent chercher des factures, des réinitialisations de mots de passe, des conversations de dirigeants, des listes de clients et le vocabulaire interne. Avec un accès aux fichiers, ils peuvent voler des documents ou y insérer des liens malveillants. Avec la lecture d'annuaire, ils peuvent cartographier l'organisation pour préparer des attaques ultérieures.

Le phishing par consentement peut donc constituer un vecteur d'accès initial pour la fraude au président (BEC), le vol de données et la compromission latérale du SaaS.

Schémas de permissions à haut risque

Tous les octrois d'applications ne se valent pas en dangerosité. Concentrez la revue sur les permissions qui offrent un accès large aux données ou de la persistance :

• Lire et écrire tous les e-mails.
• Lire les paramètres de boîte aux lettres ou créer des règles de boîte de réception.
• Lire et écrire des fichiers sur OneDrive ou SharePoint.
• Maintenir l'accès aux données hors connexion.
• Lire les données d'annuaire.
• Lire les profils de tous les utilisateurs.
• Envoyer des e-mails au nom de l'utilisateur.
• Accéder aux agendas et aux contacts.
• Usurper l'identité d'utilisateurs ou accéder à des API en leur nom.

Prenez également en compte la confiance accordée à l'éditeur, l'ancienneté de l'application, les URI de redirection, la population d'utilisateurs concernée et l'existence d'un véritable propriétaire métier.

Signaux de détection

Les événements de consentement constituent le point de départ. Déclenchez une alerte lorsque des utilisateurs accordent des portées à haut risque, lorsque de nombreux utilisateurs consentent à la même application récente, ou lorsque des utilisateurs privilégiés consentent à des applications inconnues.

Parmi les détections utiles :

• Nouvel octroi d'application OAuth avec offline_access.
• Consentement à un éditeur non vérifié.
• Consentement émanant d'un utilisateur qui accorde rarement des applications.
• Même application accordée par plusieurs utilisateurs après des e-mails similaires.
• URI de redirection de l'application sur des domaines suspects ou récemment enregistrés.
• Usage du jeton depuis des adresses IP inhabituelles après le consentement.
• Création d'une règle de boîte aux lettres après l'octroi.
• Lectures ou téléchargements massifs de fichiers par une application récemment autorisée.

Les événements applicatifs doivent être corrélés à la télémétrie e-mail et réseau. Si un octroi de consentement suit un message suspect, traitez-les comme un seul et même incident. Si l'usage du jeton provient d'une infrastructure à mauvaise réputation, escaladez.

Étapes de réponse

En cas de suspicion de consentement malveillant :

1. Révoquez l'octroi de l'application pour l'utilisateur concerné.
2. Désactivez ou bloquez l'application à l'échelle du tenant si nécessaire.
3. Révoquez les refresh tokens et les sessions actives.
4. Passez en revue les règles de boîte aux lettres, les renvois automatiques, les accès aux fichiers et les messages envoyés.
5. Recherchez les autres utilisateurs ayant accordé la même application.
6. Conservez le message de phishing, l'ID de l'application, l'éditeur, les URI de redirection, les IP sources et les horodatages de consentement.
7. Informez les propriétaires des données concernées si des fichiers ou des e-mails sensibles ont été consultés.

Ne traitez pas cela comme un simple problème de compte utilisateur. L'application malveillante est elle-même une entité qui a pu toucher de nombreux comptes.

Contrôles de prévention

Restreignez le consentement utilisateur par défaut. Autorisez les applications vérifiées à faible risque si le besoin métier l'exige, mais imposez une validation administrateur pour les portées sensibles. Maintenez un catalogue d'applications revues afin que les utilisateurs disposent d'alternatives approuvées.

Formez les utilisateurs à lire les invites de consentement. Une demande de « lecture de tous les e-mails » ou de « maintien de l'accès aux données » doit être perçue comme lourde de conséquences. Les utilisateurs doivent savoir comment signaler un écran de consentement suspect.

Revoyez régulièrement l'inventaire applicatif. Supprimez les applications inutilisées, les octrois obsolètes et les intégrations sans propriétaire. Surveillez la vérification des éditeurs et les changements d'URI de redirection.

Pour d'autres schémas d'attaque sur l'identité, consultez Spear phishing et consentement OAuth et Phishing par device code assisté par IA.

Construire un programme de gouvernance applicative

La gouvernance applicative doit commencer par un inventaire de toutes les applications d'entreprise, enregistrements d'applications, principaux de service, octrois délégués et permissions consenties par un administrateur. Cet inventaire doit inclure le propriétaire, l'éditeur, les portées, les URI de redirection, la date de création, la dernière utilisation et la population d'utilisateurs. Sans cette cartographie, les investigations sur le phishing par consentement deviennent lentes et incomplètes.

Définissez ensuite des niveaux de risque. Une application à faible risque lit le profil de base d'un utilisateur et provient d'un éditeur vérifié. Une application à risque moyen lit des agendas ou des fichiers pour un groupe restreint d'utilisateurs. Une application à haut risque demande la messagerie, les fichiers, l'accès hors connexion, la lecture d'annuaire ou des permissions d'écriture. Les applications à haut risque doivent faire l'objet d'une revue administrateur, d'une justification métier et d'une surveillance continue.

Mettez en place un processus d'approbation suffisamment rapide pour l'activité. Si l'approbation prend des semaines, les utilisateurs chercheront des contournements. Un bon processus donne des réponses claires : approuvé, refusé, ou approuvé avec des portées réduites. La sécurité doit aider les équipes à trouver des alternatives plus sûres lorsqu'une application est refusée.

Examinez les URI de redirection et le statut de l'éditeur. Une application d'apparence légitime dont les URI de redirection pointent vers des domaines suspects ne doit pas passer. Les métadonnées d'une application peuvent changer : les revues ne doivent donc pas se limiter à l'intégration initiale.

Une sensibilisation des utilisateurs qui sert vraiment

Les utilisateurs n'ont pas besoin de connaître OAuth par cœur. Ils ont besoin de règles simples. Une invite de consentement est une demande d'autoriser une application à agir avec un certain niveau d'accès. Si l'application demande la messagerie, les fichiers ou l'accès hors connexion, l'utilisateur doit marquer un temps d'arrêt. Si l'application apparaît à la suite d'un e-mail ou d'un message inattendu, l'utilisateur doit le signaler.

Les captures d'écran utilisées en formation doivent montrer des invites réalistes et expliquer les conséquences des portées larges. Évitez les conseils vagues du type « soyez prudent ». Expliquez que « maintenir l'accès » signifie que l'application conserve son accès après la fermeture du navigateur, et que « lire les e-mails » peut exposer des factures, des liens de réinitialisation et des conversations sensibles.

Les équipes sécurité doivent aussi faciliter le signalement. Ajoutez un bouton ou un workflow pour les invites d'applications suspectes, pas seulement pour les e-mails suspects. Le phishing par consentement survient souvent après le clic : les utilisateurs ont donc besoin d'un moyen de signaler ce qu'ils voient sur la page du fournisseur d'identité.

Indicateurs et audits

Suivez le nombre d'octrois à haut risque, d'éditeurs non vérifiés, d'applications sans propriétaire, d'applications inutilisées depuis 90 jours, d'utilisateurs autorisés à consentir eux-mêmes et d'octrois incluant l'accès hors connexion. Mesurez le délai de révocation des octrois malveillants et le délai d'identification de tous les utilisateurs affectés par une application suspecte.

Auditez séparément les utilisateurs privilégiés. Les dirigeants, les administrateurs, la finance, le juridique et les responsables d'ingénierie sont des cibles à plus forte valeur. Un octroi d'application malveillante provenant de l'un d'eux doit déclencher une investigation plus urgente qu'un octroi à faible risque depuis un compte de test.

Scénario d'exercice sur table

Entraînez-vous sur un incident où dix utilisateurs consentent à une visionneuse de documents malveillante. L'application demande la lecture de la messagerie et l'accès hors connexion. En moins d'une heure, un usage de jeton apparaît depuis un hébergeur cloud situé dans une autre région et des recherches dans les boîtes aux lettres commencent.

L'exercice doit répondre aux questions suivantes : qui peut révoquer l'application ? Comment retrouver chaque utilisateur ayant consenti ? Comment révoquer les refresh tokens ? Comment inspecter les accès aux boîtes aux lettres ? Comment préserver les preuves ? Comment bloquer l'application à l'échelle du tenant ? Quelles IP et quels domaines faut-il enrichir ?

Réaliser cet exercice avant une campagne réelle transforme un événement d'identité peu familier en une réponse répétée.

Plan de nettoyage en 30 jours

Un nettoyage rapide commence par les octrois inutilisés. Exportez tous les octrois d'applications d'entreprise et triez-les par dernière utilisation. Supprimez les applications sans propriétaire, sans activité récente ou sans finalité métier claire. Passez ensuite en revue les portées à haut risque telles que la messagerie, les fichiers, la lecture d'annuaire, l'accès hors connexion et les permissions d'envoi.

Restreignez ensuite la politique de consentement. Si les utilisateurs peuvent consentir eux-mêmes à des portées larges, changez ce paramètre par défaut. Créez une voie pour les applications approuvées à faible risque afin que les équipes métier ne perdent pas en productivité, mais exigez une revue administrateur pour les accès sensibles.

Enfin, ajoutez des détections pour les nouveaux octrois à haut risque et les comportements suspects après consentement. Les alertes les plus importantes relient l'octroi à l'usage du jeton, aux accès à la messagerie, aux lectures de fichiers et à l'infrastructure source. Le consentement, c'est la porte qui s'ouvre ; l'activité qui suit vous dit si un intrus l'a franchie.

Ce que les équipes sécurité ne doivent pas faire

Ne blâmez pas les utilisateurs pour avoir mal compris des invites de consentement confuses. Le système ne devrait pas attendre de chaque collaborateur qu'il évalue des portées OAuth sous la pression d'un leurre crédible. Réduisez les choix dangereux, facilitez le signalement et réservez la formation aux décisions que les utilisateurs peuvent raisonnablement prendre.

Ne traitez pas l'inventaire applicatif comme un audit annuel. Le SaaS change en permanence. De nouvelles applications apparaissent, d'anciennes changent d'éditeur, les URI de redirection dérivent et les permissions s'élargissent. La gouvernance doit être assez continue pour attraper la prochaine campagne, et pas seulement documenter la précédente.

Contenus de détection à développer

Créez des détections qui combinent au moins deux signaux. Un nouvel octroi d'application, seul, peut être bénin. Un nouvel octroi d'application avec accès hors connexion, suivi de lectures de boîte aux lettres depuis un hébergeur cloud inhabituel, est bien plus suspect. Un octroi d'un utilisateur privilégié à une application non vérifiée doit être priorisé, avant même toute exfiltration évidente.

Les fenêtres de corrélation utiles sont courtes. Recherchez des e-mails, messages de chat ou leurres de partage de documents suspects dans l'heure qui précède le consentement. Puis inspectez l'heure qui suit le consentement pour repérer l'usage du jeton, les accès aux fichiers, les requêtes sur la messagerie, les modifications de règles de boîte de réception et les connexions sortantes.

Les runbooks du SOC doivent inclure l'ID de l'application, l'éditeur, l'URI de redirection, les portées, les utilisateurs ayant consenti, l'horodatage de première observation, les IP sources et tout artefact de message associé. Cette structure facilite la comparaison d'un incident à l'autre.

Ajoutez une chasse récurrente aux abus de faible volume. Toutes les applications malveillantes ne sont pas diffusées à l'ensemble de l'entreprise. Certaines campagnes ciblent une seule assistante de direction, un seul utilisateur de la finance ou un seul ingénieur ayant accès à des fichiers intéressants. Un unique octroi à haut risque sur le bon compte peut peser plus lourd que des dizaines d'octrois à faible risque sur des utilisateurs ordinaires.

À retenir côté threat intelligence

Le phishing par consentement OAuth déplace le champ de bataille des fausses pages vers de véritables flux d'autorisation. Le domaine peut être légitime alors que l'application est malveillante.

isMalicious aide en enrichissant les domaines de redirection, les hôtes de callback, les IP sources et l'infrastructure utilisée après le consentement. Lorsque la gouvernance applicative détecte un octroi suspect, le contexte de réputation permet de déterminer si l'application est simplement inconnue ou activement liée à une infrastructure hostile.