SaaS-to-SaaS OAuth Worms : Le virus du "Consentement"
Résumé exécutif
En 2026, l’ère de “L’identité est le nouveau périmètre” a évolué vers “L’interconnexion est la nouvelle vulnérabilité.” La dernière menace en cybersécurité n’est pas une attaque par force brute ou une exploitation zero-day. C’est le SaaS-to-SaaS OAuth Worm — un “Virus du Consentement” auto-propagateur qui exploite les connexions API légitimes entre applications cloud.
Cet article dissèque l’anatomie de ces attaques, les relie à des campagnes réelles documentées en 2025, et propose des stratégies de défense concrètes pour les administrateurs Microsoft 365 et Google Workspace.
La nouvelle surface d’attaque : “Applications d’aide” & intégrations IA
D’ici 2026, l’utilisateur moyen d’entreprise connecte plus de 50 applications tierces à son identité d’entreprise. Il ne s’agit pas seulement de Shadow IT — ce sont des “boosters de productivité” comme les planificateurs IA, correcteurs grammaticaux, et assistants de réunion.
Les équipes de sécurité ont passé une décennie à renforcer la porte d’entrée (MFA, SSO, biométrie). Le Worm OAuth passe par la porte arrière. Il ne s’introduit pas ; il demande à entrer. Une fois autorisé, il n’a pas besoin de votre mot de passe — il possède votre Jeton d’Accès OAuth, une clé numérique qui fonctionne même après un changement de crédentiel.
Le scénario “AI-Meeting-Summarizer”
L’exemple le plus marquant de ce modèle d’attaque est le “AI-Meeting-Summarizer” worm. Voici le cycle d’infection :
Patient Zéro — Un utilisateur reçoit un email utile d’un collègue (déjà infecté) l’invitant à “Collaborer sur ce résumé de réunion” via un nouvel outil IA.
L’Appât — L’email ne contient pas un lien de phishing traditionnel. Il provient d’un domaine interne légitime (ex.
user@company.com) car le compte de l’expéditeur automatise l’invitation via API.Le Crochet — L’utilisateur clique sur le lien et voit un écran de consentement OAuth standard de Microsoft 365 ou Google Workspace. Il semble 100% authentique — parce que c’est le cas.
La Charge Utile (Le “Consentement”) — L’application demande des permissions telles que :
Contacts.Read— pour identifier de nouvelles victimesMail.Send— pour propager le verFiles.ReadWrite.All— pour exfiltrer des donnéesOffline_Access— pour maintenir l’accès indéfiniment
La Propagation — Au moment où l’utilisateur clique sur “Accepter”, le ver utilise le jeton API accordé pour scanner les contacts fréquents de l’utilisateur et envoie 50 invitations personnalisées depuis la propre adresse email de la victime.
Temps pour infecter tout un département : < 15 minutes.
Précédents réels (2025–2026)
Ce ne sont pas des scénarios théoriques. Le modèle d’attaque s’est déployé à grande échelle en 2025 et s’accélère en 2026.
La brèche de la chaîne d’approvisionnement Salesloft-Drift (mars 2025)
Un des incidents OAuth les plus importants de 2025 illustre parfaitement le rayon d’action SaaS-to-SaaS. Les attaquants ont accédé au dépôt GitHub de Salesloft, puis exploité les jetons OAuth d’intégration Drift pour atteindre des instances Salesforce dans plus de 700 organisations. Les chercheurs d’Obsidian Security ont noté que les dégâts étaient 10x plus importants que lors d’attaques ciblant directement Salesforce — car une seule intégration compromise a cascadeé à travers des centaines d’environnements en aval.
La leçon : un seul lien OAuth dans votre chaîne d’approvisionnement SaaS peut être une porte d’entrée dans tout votre écosystème d’affaires.
La vague de consentement des extensions Chrome (fin 2024–2025)
Une campagne de phishing par consentement ciblant les vendeurs d’extensions Google Chrome a impacté environ 2,6 millions d’utilisateurs finaux sur au moins 35 extensions couramment utilisées, dont la société de cybersécurité Cyberhaven. Un compte employé compromis a permis aux attaquants d’accéder au Chrome Web Store, leur permettant de publier des versions malveillantes d’extensions qui récoltaient des identifiants OAuth à grande échelle.
La campagne “ShadyPanda” sur navigateur (décembre 2025)
La campagne “ShadyPanda” a accumulé environ 4,3 millions d’installations via des extensions Chrome et Edge, exfiltrant des données par vol de cookies et de jetons de session — totalement invisible pour les outils de détection en endpoint.
Impersonation d’app OAuth Microsoft 365 (2025, en cours)
Proofpoint a identifié une campagne soutenue utilisant de fausses applications OAuth Microsoft 365 imitant des marques de confiance comme Adobe, DocuSign, RingCentral, et SharePoint. Ces campagnes ont ciblé près de 3 000 comptes utilisateurs dans plus de 900 environnements Microsoft 365, avec un taux de succès de compromission supérieur à 50%. Les applications malveillantes agissaient comme des leurres d’entrée, redirigeant les victimes vers des kits de phishing adverses (ex. Tycoon) pour récolter cookies de session et jetons MFA simultanément.
Abus OAuth aligné sur l’État (septembre 2025)
Proofpoint a observé un acteur de menace supposé aligné avec la Russie, identifié comme UNK_AcademicFlare, abusant de l’autorisation par code de périphérique OAuth pour prendre le contrôle de comptes ciblés. L’acteur a utilisé des comptes email gouvernementaux et militaires compromis pour établir un rapport avant d’envoyer des liens spoofés OneDrive, entraînant les victimes dans des flux de phishing par code de périphérique. Les cibles principales incluaient les secteurs gouvernemental, académique, des think tanks, et du transport en Europe et aux États-Unis.
L’évolution : “ConsentFix” — La prochaine mutation (décembre 2025)
Alors que les défenseurs commençaient à verrouiller les flux de consentement OAuth tiers, les chercheurs de Push Security ont documenté une mutation significative en décembre 2025 : ConsentFix.
ConsentFix est une attaque native au navigateur qui contourne même les configurations de consentement OAuth plus strictes que Microsoft a commencé à déployer en 2025. Voici pourquoi c’est plus dangereux que ses prédécesseurs :
Le mécanisme : Plutôt que de piéger un utilisateur pour cliquer sur “Autoriser” sur un prompt de consentement, ConsentFix ingénieure socialement la victime pour copier-coller une URL légitime d’autorisation OAuth dans la page de phishing de l’attaquant. La victime remet ainsi à l’attaquant une session valide — entièrement dans le navigateur, sans installer de logiciel ni déclencher de MFA.
La faille de première partie : ConsentFix cible spécifiquement Azure CLI — une application Microsoft native implicitement fiable dans chaque locataire Entra ID. Comme Azure CLI est une application native Microsoft, elle ne peut pas être bloquée ou supprimée par les administrateurs. Elle peut demander des permissions élevées sans déclencher de workflows d’approbation admin, et les politiques de restriction d’apps tierces ne s’appliquent pas.
Le contournement résistant au phishing : Si la victime possède déjà une session navigateur active pour son compte Microsoft, aucune connexion n’est requise. Cela permet à ConsentFix de contourner les méthodes d’authentification résistantes au phishing, y compris les passkeys.
Cela marque un changement fondamental : les attaquants n’exploitent plus seulement la faille de consentement des apps tierces — ils exploitent la confiance implicite que les plateformes cloud étendent à leurs propres outils.
Anatomie d’un Worm OAuth : Pourquoi il contourne la sécurité legacy
Il contourne la MFA
La MFA protège le moment d’authentification — la connexion. Les worms OAuth exploitent l’autorisation — l’octroi de permissions. Étant donné que l’utilisateur est déjà connecté avec une session valide, cliquer sur “Accepter” sur un prompt de consentement ne déclenche pas de MFA dans la plupart des configurations par défaut. Parce que les attaquants utilisent des identités non humaines via l’accès API OAuth 2.0, les protections MFA sont inefficaces contre l’abus de jetons ultérieur.
Vivre dans le Cloud (LotC)
L’attaque n’installe pas de malware sur l’endpoint. Il n’y a pas de .exe à signaler pour CrowdStrike ou Windows Defender. La logique malveillante vit entièrement dans l’infrastructure cloud de l’attaquant (AWS/Azure/GCP), communiquant directement avec les API de votre locataire — Microsoft Graph API ou Google Workspace API.
Invitations de confiance
Les filtres anti-spam se basent sur des signaux de réputation. Quand le ver envoie des emails depuis internal-employee@votresociete.com vers autre-employe@votresociete.com, le message est signé avec des enregistrements DKIM et SPF valides. Il passe à travers les listes “Expéditeurs sûrs” parce qu’il provient d’un compte interne de confiance.
Persistance via les Refresh Tokens
Même si la victime change son mot de passe, l’attaque persiste. Les applications OAuth utilisent des Refresh Tokens pour générer de nouveaux Access Tokens sans interaction utilisateur. Sauf si la permission de l’app est explicitement révoquée, l’attaquant conserve l’accès jusqu’à 90 jours ou plus — survivant aux resets de mot de passe, réinscriptions MFA, et verrouillages de comptes.
La clé, c’est le Token
Les tokens Bearer ne valident pas l’expéditeur. Un jeton OAuth volé fonctionne depuis n’importe quel lieu, appareil ou réseau sans nouvelle authentification. Une fois qu’un attaquant obtient un jeton OAuth valide — via phishing de consentement, vol de jeton, ou compromission tierce — il contourne totalement les contrôles d’authentification. Quiconque détient le jeton détient les clés.
La menace “Agentic” : Contexte piloté par l’IA
En 2024, des chercheurs ont démontré Morris II — le premier ver génératif IA. D’ici 2026, ce concept a mûri en attaques opérationnelles.
Les worms OAuth modernes utilisent des LLMs pour lire les emails et calendriers récents de la victime, puis génèrent des invitations contextuelles qui sont pratiquement indiscernables des communications légitimes de collègues :
| Phishing ancien | Worm OAuth assisté IA 2026 |
|---|---|
| “Veuillez consulter la facture ci-jointe.” | “Salut Sarah, j’ai utilisé cet outil IA pour résumer notre appel budget de mardi. Il a bien capturé la discussion sur la projection Q3 — regarde.” |
Ce social engineering à haut contexte rend la sceptique presque impossible pour l’employé moyen. Le message est personnalisé, fait référence à de vraies conversations, et arrive depuis une adresse email de collègue de confiance.
Notamment, ClickFix — une technique étroitement liée à ConsentFix — était le premier vecteur d’accès initial détecté par Microsoft en 2025, impliqué dans 47% des attaques.
Réponses des plateformes : Quoi de neuf en 2025
Changement de politique par défaut de Microsoft en juillet 2025
Dans une démarche défensive majeure, Microsoft a annoncé qu’à partir de juillet 2025, les utilisateurs ne pourraient plus consentir par défaut à l’accès de leurs fichiers et sites par des applications tierces. Ils doivent plutôt demander une approbation administrateur via le workflow d’Admin Consent. La gestion du risque par étape dans Entra ID escalade désormais automatiquement les demandes de consentement pour les apps multi-locataires sans éditeur vérifié, pour exiger l’approbation admin — empêchant les utilisateurs finaux de donner leur consentement directement à des apps suspectes via des URLs de phishing.
C’est une avancée majeure, mais cela ne règle pas entièrement les vecteurs de contournement ConsentFix et applications first-party.
Contrôles Google Workspace
Les administrateurs Google Workspace peuvent configurer les contrôles API pour restreindre l’accès aux applications tierces. La posture recommandée est de n’autoriser que les apps du domaine et certaines apps tierces en allow-list, en bloquant toutes les autres par défaut. Cela réduit considérablement la surface d’attaque pour les campagnes de phishing par consentement.
Stratégies de défense : Inoculer votre organisation
Protéger contre le Virus du Consentement nécessite un passage de “Sécurité d’Identité” à “Gouvernance des Applications”.
1. Le “Kill Switch” : Restreindre le consentement utilisateur
Microsoft 365 : - Aller dans Entra ID Applications d’entreprise Consentement et Permissions - Sélectionner “Autoriser le consentement utilisateur uniquement pour les apps de publishers vérifiés” (recommandé) ou désactiver le consentement utilisateur - Activer le Workflow d’Admin Consent pour que les utilisateurs puissent demander des apps sans s’auto-approver - Vérifier que votre locataire utilise la politique de consentement gérée introduite en juillet 2025
Google Workspace : - Aller dans Sécurité Contrôles API Contrôle d’accès aux applications - Faire confiance uniquement aux apps internes, du domaine ; maintenir une allow-list explicite pour les apps tierces approuvées - Bloquer toutes les autres apps accédant aux API Google Workspace par défaut
2. Audit et purge (Le protocole “Hygiène des Apps”)
Votre environnement contient probablement des apps dormantes, sur-priviliégiées, accordées il y a des mois ou des années. Utilisez votre CASB ou Microsoft Defender pour Cloud Apps pour filtrer :
- Apps avec
Mail.SendouContacts.Readpermissions - Apps avec le statut “Faible confiance communautaire” ou “Éditeur non vérifié”
- Apps avec consentement par plus de 10 utilisateurs en moins de 24h — indicateur fort d’une propagation active
- Toute app combinant
offline_accessavecFiles.ReadWrite.AllouMail.ReadWrite— une combinaison à haut risque d’exfiltration longue durée
3. Détection d’anomalies pour l’usage API
Les solutions EDR classiques sont aveugles face aux attaques OAuth natives cloud. Il faut ITDR (Détection et réponse aux menaces d’identité) avec des règles d’alerte spécifiques :
- “Nouvelle app OAuth avec permissions à haut risque” — alerter lors de la première occurrence
- “Volume de mails sortants anormal depuis un compte interne” — surtout avec des sujets identiques envoyés à des listes de distribution internes
- “Nouvelle app multi-locataires avec
offline_access+Files.ReadWrite.All” — investiguer dans les 60 minutes - “DM externe pour la première fois + création de règle de boîte mail + nouvelle attribution OAuth” dans un délai de 24–48h — ce trifecta est un indicateur de ver à haute confiance
- “Changement de domaine éditeur sur une app existante” — signal potentiel de compromission supply chain
4. Nouveaux contrôles pour les apps first-party
ConsentFix a montré que des apps Microsoft natives comme Azure CLI peuvent être utilisées comme arme pour contourner totalement les restrictions sur les apps tierces. Vérifiez les politiques d’accès conditionnel pour couvrir les flux d’autorisation par code de périphérique, et envisagez d’ajouter des conditions d’origine de connexion pour repérer des authentifications depuis des lieux ou appareils inattendus.
5. La simulation de “Consent Phishing”
Lancez des simulations d’autorisation OAuth en complément des tests de phishing classiques :
- Envoyez un email “Mettez à jour votre application Calendrier” à vos utilisateurs
- Dirigez-les vers un écran de consentement simulé
- Suivez combien cliquent sur “Accepter” sans vérifier l’éditeur
L’objectif est de former les utilisateurs à repérer le “Vérificateur d’éditeur” (le badge bleu) avant d’approuver un écran de consentement — et à signaler toute invite OAuth inattendue à la sécurité IT plutôt que de la rejeter ou accepter.
Récupération : Que faire si vous êtes infecté
Si vous détectez un ver OAuth se propageant dans votre locataire, suivez ces étapes dans l’ordre :
Étape 1 : Révoquer l’application globalement
Microsoft 365 : Dans Entra ID, localisez l’Application d’entreprise, allez dans “Propriétés,” et mettez “Activé pour la connexion des utilisateurs ?” à Non. Supprimez l’attribution de l’application et le principal de service.
Google Workspace : Dans Contrôles API, bloquez le Client ID spécifique de l’app malveillante.
Étape 2 : Révoquer les Refresh Tokens
Changer de mot de passe ne suffit pas — il faut explicitement révoquer les jetons OAuth.
PowerShell (M365):
Revoke-MgUserSignInSession -UserId UserObjectID
Exécutez ceci pour tous les utilisateurs affectés, pas seulement ceux initialement signalés.
Google Workspace : Réinitialisez les cookies de connexion et révoquez les apps connectées dans les paramètres de sécurité de chaque utilisateur.
Étape 3 : Nettoyer les emails internes
Utilisez Microsoft Content Search ou eDiscovery pour localiser et supprimer définitivement les emails d’invitation du ver dans toutes les boîtes mail — y compris dans les éléments envoyés des comptes compromis. Les invitations non supprimées continueront à générer de nouvelles victimes.
Étape 4 : Auditer la portée de l’exfiltration
Si l’app détenait Files.ReadWrite.All ou Mail.Read permissions et disposait d’un jeton Offline_Access actif, considérez la fuite de données comme présumée. Identifiez quels sites SharePoint, dossiers OneDrive ou boîtes mail ont été accessibles durant la période de résidence du jeton et lancez une évaluation de la violation.
Le modèle de menace évolue : ce que 2026 exige
Le modèle de menace pour le phishing en 2026 doit reconnaître que les attaquants prennent le contrôle de comptes via des flux d’authentification, consentement OAuth, autorisation par code de périphérique, et vol de jetons natifs au cloud — pas seulement par récolte de mots de passe. Il ne suffit plus de protéger l’email comme périmètre anti-phishing principal.
La distinction a une importance opérationnelle. Votre SEG peut bloquer un lien malveillant. Il ne peut pas bloquer une invite de consentement qui arrive par email interne légitime d’un collègue compromis. Il ne peut pas voir une action de copier-coller dans le navigateur.
Le Virus du Consentement prouve qu’en environnement cloud-native, une app malveillante est bien plus dangereuse qu’un fichier malveillant. En appliquant des politiques strictes de consentement, en adoptant des outils ITDR avec l’EDR, et en traitant chaque demande d’intégration OAuth avec la même rigueur qu’un fichier exécutable, les organisations peuvent briser la chaîne d’infection avant qu’elle ne dévaste leur environnement cloud.
Principaux enseignements
- Les attaques de consentement OAuth contournent totalement la MFA car elles exploitent l’autorisation, pas l’authentification
- La brèche Salesloft-Drift (mars 2025) a montré qu’une seule intégration compromise peut se propager à plus de 700 organisations — un rayon d’action 10x supérieur aux attaques directes
- “ConsentFix” (décembre 2025) est une mutation native au navigateur qui contourne même les restrictions d’approbation admin en ciblant des apps first-party comme Azure CLI
- Microsoft a rendu le consentement restrictif par défaut en juillet 2025 — vérifiez la conformité de votre locataire et testez-la
- Révoquez les jetons, pas seulement les mots de passe — un jeton OAuth de rafraîchissement compromis survit à une réinitialisation complète des crédentials
- ITDR n’est pas optionnel : la détection classique en endpoint est aveugle face à l’exploitation OAuth native cloud
- Les variantes ClickFix / ConsentFix représentaient près de la moitié des vecteurs d’accès initiaux observés par Microsoft en 2025
Le paysage de la menace OAuth évolue plus vite que la plupart des cycles d’audit. Revoyez vos politiques de consentement applicatif, réalisez un audit d’hygiène des apps, et vérifiez que votre ITDR couvre l’abus de jetons API non interactifs — avant que votre prochaine invitation de calendrier ne devienne le Patient Zéro.
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.
Related Topics
Keep building with InstaTunnel
Read the docs for implementation details or compare plans before you ship.