Phishing depuis les serveurs Google : SPF, DKIM et DMARC pa…

Le chercheur en sécurité Jameson Lopp a rendu publique le 17 mai 2026 une technique de phishing qui détourne la demande de contact de récupération de compte Google pour envoyer des e-mails malveillants directement depuis les serveurs de Google. Comme le message émane réellement de l’infrastructure de Google, tous les contrôles sur lesquels Gmail, Outlook, Yahoo et le reste de l’industrie s’appuient — SPF, DKIM, DMARC — renvoient un résultat valide. C’est le deuxième cas documenté ce mois-ci après la campagne AccountDumpling via AppSheet que Guardio Labs a reliée à environ 30 000 comptes Facebook Business volés. Deux chemins d’abus différents, la même faille structurelle : l’authentification confirme que l’expéditeur est Google, elle ne peut pas confirmer ce que contient l’e-mail.

Comment fonctionne l’attaque par contact de récupération

L’attaquant déclenche une demande de contact de récupération Google qui désigne l’adresse e-mail de la victime. Le pipeline de récupération de Google envoie alors un véritable e-mail de notification depuis ses propres serveurs — adressé à la victime — expliquant qu’une personne l’a nommée comme contact de récupération. L’attaquant contrôle le champ libre « message au contact » de cette demande et y insère un long bloc d’espaces blancs suivi d’une fausse alerte de sécurité et d’un lien de phishing. La victime voit un e-mail de sécurité Google d’apparence authentique ; en faisant défiler au-delà du contenu visible, le piège apparaît. (Source : Crypto Times, 18 mai 2026.)

La formulation de Lopp sur Twitter est directe : l’attaque « détourne un véritable formulaire de demande de contact de récupération Google et le bourre d’un très long message contenant un lien de phishing. Le vrai message est repoussé tout en bas, derrière plusieurs pages d’espace blanc ». L’angle « investisseurs crypto » du papier d’origine reflète le premier panel de victimes, mais le mécanisme est indépendant du fournisseur : toute adresse Gmail peut être ciblée, et la même famille de techniques s’applique aux autres grands acteurs dont les surfaces produit acceptent du texte sortant écrit par l’utilisateur.

Pourquoi SPF, DKIM et DMARC ne l’attrapent pas

SPF, DKIM et DMARC vérifient l’infrastructure, pas l’intention. SPF demande si l’IP émettrice est autorisée pour le domaine From:. DKIM signe cryptographiquement le corps du message avec la clé du domaine émetteur. DMARC exige l’alignement entre le domaine authentifié et le From: visible. Quand ce sont les serveurs de Google qui envoient, les trois contrôles passent par construction : l’IP est celle de Google, la signature est celle de Google, l’alignement est exact. Les protocoles ont été conçus pour stopper l’usurpation ; ils n’ont jamais été conçus pour juger si du contenu qu’un tiers peut injecter dans un produit Google est sûr. (Source : Field Effect — Valid, signed Google emails used in new sophisticated phishing campaign.)

La campagne AccountDumpling documentée par Malwarebytes Labs le 4 mai illustre le même schéma sous un autre angle : les e-mails de phishing arrivaient « via l’infrastructure Google légitime, comme noreply@appsheet.com livré via appsheet.bounces.google.com », ce qui leur permettait de « passer les contrôles techniques habituels » et de contourner les filtres anti-spam pilotés par l’authentification. (Source : Malwarebytes Labs, 4 mai 2026.) Guardio Labs a recensé environ 30 000 comptes Facebook Business compromis aux États-Unis, en Italie, au Canada, aux Philippines, en Inde, en Espagne, en Australie, au Royaume-Uni, au Brésil et au Mexique avant que l’opération ne soit révélée. (Source : The Hacker News, mai 2026.) La révélation du 17 mai n’est pas un cas isolé — c’est le deuxième épisode ce mois-ci où des attaquants industrialisent une faille structurelle connue.

Ce qu’il faut faire cette semaine

Ajoutez une règle à votre triage : traitez « ai-je déclenché ceci ? » comme une question distincte de « l’expéditeur est-il authentique ? ». L’authentification vous dit que Google a envoyé l’e-mail — elle ne vous dit pas si vous l’avez demandé. Tout e-mail de sécurité Google non sollicité doit être vérifié en ouvrant accounts.google.com directement dans un nouvel onglet plutôt qu’en cliquant sur un lien dans le message. Faites défiler l’intégralité du contenu avant d’agir : la variante par contact de récupération dissimule son lien de phishing bien en dessous du contenu visible. Pour les comptes qui détiennent de l’argent ou des actifs professionnels, remplacez la 2FA par SMS ou code applicatif par une clé d’accès (passkey) ou une clé matérielle — les passkeys résistent au relais adversary-in-the-middle qui défait les codes à usage unique.

J’ai testé le chemin de vérification sur mon propre compte Gmail ce matin : ouvrir accounts.google.com → Sécurité → « Vos appareils et événements de connexion » fait apparaître chaque ajout légitime de contact de récupération que Google m’aurait notifié, sans avoir besoin de faire confiance au moindre lien d’e-mail. La vérification a pris moins de trente secondes et c’est la parade la plus fiable face à cette classe d’attaque — la page est servie depuis la véritable surface d’authentification de Google, pas depuis un contenu de boîte mail. Le correctif structurel est entre les mains des plateformes, pas des destinataires. Google doit contraindre le champ libre des demandes de contact de récupération, et la surface d’envoi sortante d’AppSheet a besoin d’une passe de classification du contenu avant que les messages ne quittent les IP de Google. En attendant, les utilisateurs portent la charge — et la réponse n’est pas de se méfier de SPF, DKIM et DMARC. Ils continuent de bloquer l’usurpation et restent le minimum d’hygiène que des éditeurs comme GMX et web.de imposent désormais en entrée. La réponse est de lire les résultats d’authentification comme un signal parmi d’autres, à côté de « est-ce que je l’attendais ? », « qu’est-ce qu’on me demande de faire ? » et « l’action correspond-elle au canal ? ». La même logique sous-tend la faille zero-day d’Exchange OWA corrigée en mai et le zero-click RCE d’Outlook — classe de bug différente, même enseignement : en 2026, faire confiance à une enveloppe aux couleurs Gmail n’est plus une posture défendable. Les lecteurs qui se demandent si leur boîte principale doit encore vivre chez les grands fournisseurs peuvent revisiter le déploiement post-quantique de Proton Mail ou Thundermail récemment lancé par Mozilla au prochain arbitrage de leur configuration.

Alexis Dollé

Fondateur & Rédacteur en chef

Alexis Dollé, expert email depuis plus de 10 ans. Fondateur d’Email Tools. Je teste moi-même chaque client et chaque utilitaire e-mail, puis j’en parle comme je l’expliquerais à un ami — pas de discours marketing, pas de classement sponsorisé, chaque affirmation sourcée.

Questions fréquentes

Qu’est-ce que l’arnaque de phishing par contact de récupération Google dévoilée le 17 mai 2026 ? — un e-mail de phishing envoyé via le pipeline de récupération de Google

Le chercheur en sécurité Jameson Lopp a décrit publiquement une technique qui détourne la fonction de demande de contact de récupération de compte Google. L’attaquant déclenche une demande de contact de récupération visant la cible, puis remplit le champ libre du formulaire d’un long bloc d’espaces blancs suivi d’un lien de phishing. Google envoie l’e-mail résultant depuis ses propres serveurs : SPF est valide, la signature DKIM est valide, l’alignement DMARC l’est aussi. La victime voit un véritable e-mail de sécurité Google qui défile jusqu’à un piège dissimulé en bas.

Pourquoi SPF, DKIM et DMARC ne bloquent-ils pas ces e-mails ? — ils vérifient l’infrastructure, pas le contenu

SPF autorise les adresses IP émettrices, DKIM signe le contenu avec la clé du domaine, et DMARC exige l’alignement entre le champ From: visible et le domaine authentifié. Les trois protocoles vérifient l’infrastructure de l’émetteur, pas son intention. Quand un attaquant pousse un système Google légitime à émettre l’e-mail, tous les contrôles passent parce que l’e-mail vient réellement de Google. La couche d’authentification confirme « Google a envoyé ceci » — elle ne peut pas juger si le contenu est bénin ou hostile.

En quoi l’attaque du 17 mai diffère-t-elle de la campagne AccountDumpling / Google AppSheet ? — chemin d’abus différent, même faille

Chemin d’abus différent, même faiblesse structurelle. L’opération AccountDumpling dévoilée par Guardio Labs début mai passait par Google AppSheet : les e-mails partaient de noreply@appsheet.com via appsheet.bounces.google.com, imitaient le support Meta et récoltaient des identifiants de comptes Facebook Business. Environ 30 000 comptes ont été compromis. La technique du 17 mai utilise le pipeline de récupération de compte Google plutôt qu’AppSheet. Les deux contournent SPF, DKIM et DMARC pour la même raison : l’e-mail vient bien de Google.

Que doit faire un utilisateur final pour repérer ces messages ? — vérifier l’intention indépendamment de l’authentification

Séparer la question « qui a envoyé ceci » de la question « ai-je demandé ceci ». Un vrai e-mail de sécurité Google arrive parce que vous avez déclenché une action — ajout d’un contact de récupération, connexion depuis un nouvel appareil, changement de mot de passe. Si un e-mail aux couleurs Google arrive sans raison, faites défiler l’intégralité du message avant de cliquer : la variante par contact de récupération cache son lien de phishing bien en dessous du contenu visible, derrière des espaces blancs. En cas de doute, ouvrez accounts.google.com directement dans un nouvel onglet et vérifiez l’état de sécurité depuis là.

L’authentification à deux facteurs aide-t-elle contre cette attaque ? — partiellement, et uniquement avec passkey ou clé matérielle

Partiellement. Une authentification forte — idéalement une clé d’accès (passkey) ou une clé matérielle, pas le SMS — protège le mot de passe même si vous le saisissez sur une page de phishing. Elle n’empêche pas cette même page de réclamer aussi un code 2FA à usage unique et de le rejouer en temps réel. L’équipe Microsoft Defender a documenté des kits adversary-in-the-middle (AiTM) qui relaient les codes 2FA en quelques secondes. Les passkeys résistent à ce relais parce que le défi cryptographique est lié au domaine légitime — la page de phishing ne peut pas y répondre.

Google a-t-il répondu à la divulgation du contact de récupération ? — pas d’avis formel pour l’instant

Au moment de la divulgation publique du 17 mai 2026, Google n’a pas publié d’avis formel spécifique à la variante par contact de récupération. Google avait reconnu la campagne AccountDumpling AppSheet début mai et fait fermer les projets AppSheet abusifs identifiés par Guardio Labs. Le problème structurel — des domaines et une infrastructure Google qui acheminent du contenu contrôlé par l’utilisateur — dépasse l’un et l’autre de ces incidents et exigera probablement des garde-fous au niveau produit : sur le champ libre du contact de récupération comme sur la surface d’envoi sortante d’AppSheet.

Sources