Consentement à l'hameçonnage : le nouveau vecteur qui vole les jetons OAuth et élargit l'accès

En février 2026 émerge un service qui résume l'évolution du phishing: EvilTokens. En moins de cinq semaines, cette plateforme d'hameçonnage a engagé plus de 340 organisations qui utilisent Microsoft 365 dans cinq pays, non pas voler des mots de passe mais demander un consentement apparemment inoffensif OAuth sur microsoft.com / dialentin. L'utilisateur a complété son MFA légitime, cliquez sur "OK" et est retourné à sa tâche avec le sentiment d'avoir vérifié une connexion de routine; au lieu de cela, l'agresseur prenait un jeton de rafraîchissement valide et renouvelable avec accès au courrier, au calendrier, à l'unité et aux contacts, ce qui a duré aussi longtemps que la politique du locataire le permettait.

La mécanique de l'attaque révèle une rupture conceptuelle : la couche de consentement OAuth est maintenue en dehors du périmètre que de nombreuses organisations protègent rigoureusement. Alors que le vol d'identifications provoque des signaux reconnaissables - rétractations, corrélations de session, demandes provenant d'emplacements anormaux - une subvention OAuth légitime est indissociable du fonctionnement normal du fournisseur d'identité; il est signé, il porte des champs que l'utilisateur a acceptés et ne génère pas le type d'événement que les SIEM traditionnels considèrent suspect. Le résultat est ce que la communauté appelle consentement à l'hameçonnage u Octroi d'un abus, un vecteur qui exploite la confiance des utilisateurs et la conception de protocole. Pour comprendre votre base technique, vous devriez revoir la norme : OAuth 2.0 (RFC 6749).

Deux propriétés rendent cet abus particulièrement puissant : le premier, que l'authentification et MFA se produisent dans le domaine légitime, de sorte que les contrôles anti-phishing centrés sur les identifiants échouent ; le second, que les jetons de rafraîchissement étendent la fenêtre d'exposition et survivent souvent aux changements de mot de passe. La conséquence pratique: un attaquant n'a pas besoin de reproduire une session humaine ou de dessiner MFA, parce qu'il a obtenu un dispositif d'accès avec la même validité que le reste de l'écosystème est confiant à utiliser automatiquement.

L'écosystème actuel amplifie le problème. Les travailleurs reçoivent une avalanche mensuelle de demandes de consentement : agents IA qui intègrent avec des calendriers, extensions de navigateur qui demandent l'accès aux comptes SaaS, connecteurs qui relient des applications tierces. La langue des champs - "Lisez votre courrier", "Access files when you are not present" - cache une large portée opérationnelle: chaque champ est généralement traduit en accès à tous les messages, pièces jointes, fichiers partagés et ressources que l'utilisateur peut atteindre. Cet écart entre l'étiquette et la capacité est l'écart où les attaquants comme les opérateurs EvilTokens se déplacent.

Le risque réel n'est pas seulement l'accès isolé à un compte, mais les combinaisons toxiques qui émergent lorsque les permis apparemment bénins sont interconnectés par une identité humaine. Un utilisateur donne accès à un assistant de réunion au calendrier et au courrier, puis autorise un autre agent au conducteur partagé et un troisième service au CRM; aucune de ces approbations n'a été conçue pour interagir, mais ensemble créer un pont qui permet à un attaquant de pivoter entre les informations confidentielles, les contrats et les données client. Ces "combinaisons toxiques" n'apparaissent pas dans le journal d'une seule application parce que la connexion se produit en dehors du domaine de tout propriétaire d'application.

Un nouveau front émergent est le Model Context Protocol (MCP) et des serveurs équivalents qui permettent aux agents d'IA d'acquérir plus facilement la portée grâce au même mécanisme de confiance unique que les écrans de consentement exploitent. Nous avons déjà vu des événements d'échelle par des mécanismes similaires: en 2025, une chaîne de concessions légitimes a permis à un connecteur engagé de se propager parmi des centaines de locataires de Salesforce, montrant que la cascade d'OAuth peut transformer une concession isolée en une infection massive.

Pour combler cette lacune, il faut changer la façon dont le consentement est gouverné : nous devons traiter les subventions OAuth et les connexions des agents d'IA avec la même discipline qui s'applique à l'authentification. Cela signifie des politiques qui limitent la délégation automatique, la révocation agile des jetons au niveau de l'application, la surveillance continue du graphique des identités et des concessions, et des mesures techniques qui réduisent la longévité des jetons rafraîchissants. Microsoft et d'autres fournisseurs publient des lignes directrices sur les flux tels que le code de l'appareil et la façon dont les jetons doivent être traités correctement; cela les aide à comprendre les options de configuration: Azure AD - Code de périphérique OAuth 2.0.

En plus d'ajuster les configurations, les organisations devraient intégrer la détection en temps réel et la visibilité sur l'exécution du consentement. Les outils qui cartographient un graphique d'identités et de concessions au moment de leur création facilitent l'observation de ponts inattendus, de jetons inutilisés ou de déviations politiques avant qu'ils ne deviennent un incident. L'intégration entre la gouvernance de l'identité, la détection des menaces et le contrôle des agents d'IA devient une priorité pour réduire la fenêtre d'exposition et automatiser la médiation : de la révocation d'une subvention engagée au renvoi du consentement forcé ou de la mise en oeuvre de politiques assorties de conditions de risque.

En termes opérationnels, les équipes de sécurité devraient exiger l'approbation administrative pour les applications à grande vitesse, appliquer des principes moins privilégiés dans les approbations par défaut, limiter la durée des jetons de rafraîchissement lorsque le fournisseur le permet et permettre le suivi des activités d'application inhabituelles (par exemple, les exportations massives ou l'accès hors calendrier). La formation est toujours nécessaire, mais elle ne suffira plus à donner l'instruction aux utilisateurs de ne pas cliquer : il est nécessaire que l'environnement technologique rende difficile l'octroi de permis étendus par erreur.

Enfin, il faut repenser la responsabilité : la zone de risque est un graphique qu'aucune application individuelle ne contrôle complètement. Par conséquent, l'atténuation efficace combine les contrôles de la plate-forme (configuration des locataires, politiques d'accès conditionnel), les outils qui observent le graphique de consentement en temps réel et les processus organisationnels qui réduisent la vitesse à laquelle des ponts peuvent être créés (fourniture d'agents, processus d'approbation, vérification des fournisseurs). Le temps de réaction devrait être réduit de semaines à des minutes et des files d'attente opérationnelles à côté de la subvention.

Le modèle de menace a évolué : nous ne défendons plus seulement les lettres de créances, nous défendons l'acte d'octroi des permis. Traiter le consentement comme une ressource critique et appliquer la visibilité, la limitation et la révocation avec la même priorité que le contrôle d'accès et MFA est la ligne de défense qui empêche les services comme EvilTokens de devenir l'exception et de devenir la routine.