Phishing Google Calendar : pourquoi le MFA par code a cédé

En résumé. De mi-août à l'automne 2026, une campagne de phishing a utilisé de fausses invitations Google Calendar pour voler des sessions Google actives d'utilisateurs en entreprise, selon l'équipe Threat Research de Material Security. Un proxy inverse placé devant la vraie page de connexion Google relayait mot de passe, codes SMS, codes d'application et validations « Oui » sur le téléphone : aucun de ces seconds facteurs n'a empêché la capture. Les facteurs liés au domaine (passkeys, clés de sécurité FIDO2) sont conçus pour ne pas se relayer de cette façon ; c'est le contrôle à prioriser pour les comptes Google Workspace.

Ce qui s'est passé

BleepingComputer a publié le 4 novembre 2026 un article qui présente les travaux de Material Security sur cette campagne (source). Le texte est rédigé du point de vue de Material, éditeur d'une solution de détection : les chiffres viennent de lui et ne portent que sur ses clients qui ont accepté de partager leurs données. L'article précise lui-même que les totaux réels sont plus élevés.

Les faits rapportés :

• Depuis mi-août 2026, l'opération récolte des sessions Google actives d'utilisateurs en entreprise.
• Le leurre : des invitations Google Calendar, parfois envoyées en copie cachée, souvent depuis une organisation avec laquelle la cible avait déjà échangé. Les prétextes sont ordinaires : message vocal, appel d'offres (RFP, RFI), convocation au tribunal, impayé.
• Les liens pointent le plus souvent vers Google lui-même : le redirecteur /url de Google, ou selon les vagues share.google et des liens de fichiers Drive. Une variante utilisait des liens de notification de transaction Intuit.
• La capture passe par le framework Nyasher, documenté publiquement depuis février après la découverte d'une clé codée en dur dans son JavaScript.
• Fin septembre, Material a lancé ce qu'il appelle l'Operation CloudFire : signaler les passerelles et les serveurs de réception à Cloudflare, qui a affiché son propre avertissement de phishing sur les destinations validées.
• Sur un mois d'opération, Material annonce 68676 messages bloqués, 2112 URL malveillantes analysées, 897 domaines retirés, et 8570 adresses d'expéditeurs compromises réparties sur 6354 domaines racines. Les envois suivaient les heures de bureau américaines.
• Situation actuelle : les thèmes sont passés des invitations Calendar aux partages de fichiers et documents Drive, l'activité du groupe semble s'être dispersée, et Material estime que la campagne paraît terminée.

Comment ça fonctionne, dans le principe

Trois éléments se combinent.

La confiance héritée. Chaque adresse expéditrice compromise appartenait à un compte déjà contrôlé par l'attaquant, qui envoyait des invitations aux contacts enregistrés de la victime précédente. Le destinataire voit un nom ou un domaine connu, au passé propre, à une heure plausible. La source résume : les systèmes de réputation répondent à une question de propriété (qui a enregistré le domaine, quel historique), et toutes les réponses étaient rassurantes.

Une chaîne qui ne laisse rien à analyser. Premier saut : le redirecteur de Google. Deuxième : un challenge Cloudflare Turnstile, parfois le vrai widget servi par Cloudflare. Troisième : la page de capture, qui n'existe pas en statique. Elle est construite dans le navigateur par du JavaScript après le challenge, si bien qu'un robot d'analyse n'a rien à télécharger et qu'un journal de proxy n'a rien à enregistrer. L'infrastructure est jetable : domaines enregistrés quelques jours avant usage, un certificat émis 46 minutes avant l'enregistrement du domaine qu'il couvre.

Le relais en temps réel. C'est le cœur du sujet pour un RSSI. Le serveur de l'attaquant se place entre la victime et la vraie page Google (on parle d'attaque adversary-in-the-middle, AiTM). La victime saisit son mot de passe, reçoit une vraie demande de second facteur, l'approuve. Le serveur transmet chaque élément à Google au fil de l'eau, et récupère la session ouverte.

Pourquoi un code se relaie

Un code SMS ou un code TOTP (le code à six chiffres d'une application d'authentification) ne sait pas sur quel site il est saisi. Il prouve que la personne détient le téléphone, pas qu'elle parle au bon serveur. Si un intermédiaire le reçoit dans les secondes qui suivent, il le présente à Google comme s'il venait de l'utilisateur. La validation « Oui » sur le téléphone, même avec correspondance de nombre, a la même limite : l'utilisateur voit bien une connexion en cours, puisqu'il est en train de se connecter. La source cite explicitement les codes SMS, les codes d'application, le Tap-Yes avec correspondance de nombre de Google et la récupération par téléphone parmi les mécanismes relayés.

Ce que changent passkeys et clés FIDO2

Une passkey ou une clé de sécurité FIDO2 (le standard d'authentification de la FIDO Alliance, implémenté via WebAuthn dans les navigateurs) signe un défi en y liant l'origine du site, vérifiée par le navigateur. Une signature obtenue sur un domaine qui n'est pas google.com n'est pas acceptée par Google, et le navigateur ne propose même pas la passkey Google sur un autre domaine. Le relais en temps réel perd donc son matériau. C'est pour cela qu'on parle de MFA résistant au phishing.

Deux limites à garder en tête, qui sont des points d'analyse et non des éléments de la source :

• La passkey protège l'ouverture de session. Elle ne protège pas une session déjà volée, ni un cookie exfiltré par un logiciel malveillant sur le poste.
• Elle ne sert à rien si des méthodes plus faibles restent acceptées sur le même compte. La source mentionne que la récupération de compte par téléphone a été relayée : un compte « passkey + SMS de secours » reste attaquable par le SMS.

Qui est concerné

Les organisations sur Google Workspace dont les utilisateurs s'authentifient par mot de passe et code ou par validation mobile. Le ciblage décrit vise des utilisateurs en entreprise, avec des envois calés sur les heures de bureau américaines ; la source ne donne pas de répartition géographique des victimes, et rien ne permet d'exclure des cibles européennes.

Les startups et scale-ups sont exposées pour une raison structurelle mentionnée par la source : une session Google donne accès à la messagerie, à Drive et à la capacité d'accorder des accès OAuth au nom de la victime. Dans une petite structure où Google est aussi le fournisseur d'identité unique (SSO) vers les autres outils, l'impact peut dépasser Google : c'est une hypothèse à vérifier selon votre configuration.

Le mécanisme de propagation ajoute un risque pour vos partenaires : un compte compromis chez vous envoie des invitations à vos contacts.

Comment s'en protéger

1. Imposer un second facteur résistant au phishing aux comptes à privilèges, puis à tous. Commencez par les super-administrateurs Workspace, les fondateurs, la finance et les personnes qui ont des accès production. Retirez ensuite les méthodes relayables (SMS, codes, appels) de ces comptes, y compris en secours. Prévoyez deux authentificateurs par personne pour éviter les blocages. Notre plan passkeys sur 90 jours détaille le déploiement.

2. Encadrer les invitations Calendar. La source souligne qu'une passerelle mail conçue pour inspecter les messages en transit est mal adaptée aux invitations. Vérifiez dans la console d'administration comment les invitations provenant d'expéditeurs externes s'ajoutent aux agendas, et sensibilisez les équipes à ce vecteur précis : une invitation n'est pas plus sûre qu'un mail.

3. Contrôler les autorisations OAuth. Une session volée peut accorder des accès à des applications tierces. Restreignez l'accès des applications tierces aux données Workspace aux seules applications approuvées, et passez en revue régulièrement les jetons déjà accordés.

4. Savoir révoquer en moins d'une heure. La source pose la question directement : qui lit les journaux d'audit Workspace, et l'équipe peut-elle révoquer les sessions, contenir les autorisations OAuth et réinitialiser le compte dans l'heure ? Écrivez cette procédure, nommez qui la déclenche, et chronométrez-la une fois. Notre méthode de gestion d'incident en 7 étapes sert de base.

5. Surveiller les signaux de session. Connexions depuis des adresses IP ou des pays inhabituels juste après une connexion légitime, nouvelles règles de transfert de mail, nouvelles autorisations OAuth, partages Drive massifs vers l'extérieur.

Comment vérifier chez vous

• Exportez la liste des utilisateurs et leurs méthodes de validation en deux étapes : combien de comptes administrateurs utilisent encore SMS ou code ?
• Cherchez dans les journaux d'audit Workspace les connexions réussies suivies, dans l'heure, d'une connexion depuis une autre géographie pour le même compte.
• Listez les applications tierces ayant reçu un accès OAuth sur les 90 derniers jours et identifiez celles que personne ne reconnaît.
• Faites l'exercice : révoquez toutes les sessions d'un compte de test et mesurez le temps réel jusqu'à la déconnexion effective.

FAQ

Le MFA protège-t-il contre le phishing ? Pas tous les MFA. Les codes SMS, les codes d'application et les validations par notification peuvent être relayés en temps réel par un proxy inverse, comme dans cette campagne. Les passkeys et les clés FIDO2 sont liées au domaine du site et résistent à ce relais.

Qu'est-ce qu'une attaque adversary-in-the-middle (AiTM) ? L'attaquant place un serveur entre la victime et le vrai site. La victime croit se connecter normalement, saisit ses identifiants et valide son second facteur ; le serveur transmet tout au vrai site et récupère la session authentifiée.

Une passkey suffit-elle à empêcher le vol de session ? Elle empêche la capture de session par ce type de relais à la connexion. Elle ne couvre pas un cookie volé sur un poste infecté, ni un compte qui garde le SMS comme méthode de secours. Il faut la combiner avec la suppression des méthodes faibles et une capacité de révocation rapide.

Que faire si un collaborateur a cliqué sur une fausse invitation Calendar ? Révoquer ses sessions actives, réinitialiser son mot de passe, examiner les autorisations OAuth et règles de transfert créées récemment, puis vérifier dans les journaux d'audit ce qui a été consulté. Prévenir aussi ses contacts : le mécanisme décrit réutilise les comptes compromis pour envoyer de nouvelles invitations.

Sources

• BleepingComputer, « Google Calendar phishing campaign hijacks sessions, bypasses MFA », 4 novembre 2026, contenu présentant les travaux de Material Security : https://www.bleepingcomputer.com/news/security/google-calendar-phishing-campaign-hijacks-sessions-bypasses-mfa

---

WeeSec accompagne les CTO et RSSI de startups et scale-ups sur la sécurisation de leurs chaînes d'identité et de développement. Voir notre approche DevSecOps.