Fuite de données Gmail : 2,5 milliards de comptes potentiellement exposés – analyse et recommandations

Intrusion chez Google et fuite de données ?

En juin 2025, le géant Google a été victime d’une cyberattaque ciblant l’une de ses bases de données d’entreprise hébergée sur la plateforme Salesforce. Le groupe de hackers ShinyHunters, associé aux collectifs Scattered Spider et Lapsus$, est parvenu à piéger des employés par ingénierie sociale (technique du vishing) : se faisant passer pour du support informatique, les attaquants ont convaincu un employé d’installer une fausse application Salesforce (Data Loader compromis).

Cette ruse a permis d’accéder à une base contenant des informations de contact professionnelles (principalement des noms d’entreprise, adresses e-mail et numéros de téléphone) de clients potentiels de Google Ads.

Google a confirmé l’incident début août en précisant que les données dérobées étaient limitées à des informations basiques et déjà publiques, et qu’aucun mot de passe ni contenu de compte Gmail/Google n’avait été compromis.

Environ 2,55 millions d’enregistrements de contacts ont ainsi fuité, et les personnes concernées ont été averties par Google par e-mail.

Cette attaque illustre une faille avant tout humaine et organisationnelle : les attaquants n’ont exploité aucune vulnérabilité technique des serveurs Google, mais ont abusé de la confiance d’utilisateurs internes pour pénétrer l’environnement. Google a coupé l’accès des pirates rapidement après une « courte fenêtre de temps » d’exposition et a refusé de payer la rançon de 2,3 millions de dollars exigée par ShinyHunters.

Cependant, dès la mi-août, l’incident a pris une ampleur bien plus large. Plusieurs sources spécialisées ont signalé la diffusion en ligne d’une base de données massive regroupant jusqu’à 2,5 milliards de comptes associés à Gmail et Google Cloud. Contrairement à ce que le chiffre pourrait suggérer, cette fuite n’est pas le résultat d’un piratage unique et centralisé de Gmail. Il s’agirait d’une compilation de données issues de multiples brèches historiques, agrégées sur plusieurs années.

Autrement dit, des identifiants (adresses Gmail) et possiblement des mots de passe volés lors d’anciennes violations de divers services se retrouvent rassemblés dans un seul fichier géant. Ce type de compilation alimente des attaques dites de credential stuffing, où les cybercriminels utilisent ces couples login/mot de passe connus pour tenter de prendre le contrôle d’autres comptes en ligne.

Le risque est majeur si des utilisateurs ont réutilisé sur leur compte Google un mot de passe compromis ailleurs : un mot de passe Gmail figurant dans la base devient une clé pour accéder à d’autres services, et réciproquement, un mot de passe volé sur un site tiers peut servir à s’introduire sur Gmail si l’utilisateur l’a recyclé.

Il convient de noter qu’à ce stade, Google maintient qu’aucune faille de ses systèmes Gmail n’a été exploitée directement et qu’aucune donnée client privée (messages Gmail, fichiers Drive, etc.) n’a fuité depuis ses serveurs.

La présence de milliards d’adresses Gmail dans la nature provient surtout de la longue traîne de fuites antérieures touchant d’innombrables sites web et services tiers, combinées ici en un ensemble sans précédent. En somme, presque l’intégralité des utilisateurs Gmail à travers le monde (plus de deux milliards) sont désormais exposés à des attaques indirectes utilisant ces données volées.

Vague d’attaques ciblant les comptes Gmail

Dans les jours suivant la publication de cette base de données, on a observé une multiplication des attaques visant les utilisateurs Gmail et Google. Sur les forums spécialisés et les réseaux sociaux, de premiers témoignages ont émergé dès la mi-août : par exemple, des utilisateurs sur Reddit ont rapporté des appels téléphoniques suspects d’interlocuteurs se présentant comme des techniciens Google.

Ce type d’attaque, appelé vishing (phishing vocal), exploite les informations de contact volées : les escrocs appellent des victimes en se faisant passer pour le support de Google, parfois en utilisant des numéros à l’indicatif +1 650 (indicatif de la Silicon Valley, donc potentiellement rassurant).

Prétextant une activité inhabituelle ou une faille de sécurité sur le compte, ils incitent l’utilisateur à leur communiquer des éléments sensibles – par exemple un code de vérification à usage unique, ou à effectuer une réinitialisation de mot de passe dictée par l’attaquant. Armés de ces informations, les pirates peuvent alors tenter de prendre le contrôle du compte Gmail de la cible, en changeant le mot de passe et en évincant ainsi le véritable propriétaire.

Google a confirmé avoir constaté des intrusions réussies sur certains comptes, principalement en raison de mots de passe déjà compromis et en l’absence d’authentification à deux facteurs. Selon des chiffres communiqués en interne, seuls 36 % des utilisateurs modifient régulièrement leur mot de passe, ce qui laisse une large base d’usagers potentiellement vulnérables aux tentatives d’accès non autorisé sur la durée.

Parallèlement aux appels, des campagnes de phishing par e-mail ciblées sont en cours. Plusieurs victimes ont signalé la réception de faux courriels de sécurité imitant les alertes officielles de Google. Par exemple, des messages semblant provenir de « Google » indiquent « Suspicious sign-in prevented » (connexion suspecte bloquée) et poussent l’utilisateur à cliquer sur un lien pour sécuriser son compte.

Bien entendu, le lien renvoie vers un site de phishing habilement déguisé où l’utilisateur, trompé par le caractère urgent et légitime du message, pourrait saisir ses identifiants sans se douter de la supercherie. Google a dû émettre un avertissement mondial sur ces imitations malveillantes d’emails de sécurité : la firme rappelle qu’elle ne demandera jamais à un utilisateur de fournir son mot de passe ou des données sensibles via un simple e-mail, et qu’il faut se méfier des liens ou pages web inhabituelles demandant de telles informations. De manière générale, toute communication non sollicitée vous pressant de « sécuriser » votre compte doit être considérée avec une extrême prudence.

En exploitant le gigantesque fichier de comptes compromis, les acteurs malveillants peuvent également mener des attaques plus techniques. Par exemple, des tentatives d’accès automatisées aux comptes (credential stuffing) sont probablement en cours : les assaillants testent en masse les couples adresse + mot de passe connus sur les pages de connexion Gmail. Si les utilisateurs n’ont pas changé un mot de passe qui figurait dans une ancienne fuite, les attaquants pourraient réussir à se connecter directement.

Cependant, Google affirme avoir renforcé ses dispositifs de détection et de blocage de ces tentatives : de nombreux utilisateurs reçoivent justement des alertes « Connexion suspecte empêchée » lorsque quelqu’un tente d’accéder à leur compte avec le bon mot de passe depuis un appareil non autorisé. Ces alertes sont le signe que les protections automatiques jouent leur rôle (notamment grâce à l’apprentissage automatique pour repérer des connexions anormales), mais elles indiquent aussi que les assaillants testent activement les données volées.

Par ailleurs, des attaques exploitant des accès cloud obsolètes ont été évoquées par certains chercheurs. Il s’agit par exemple de tirer parti d’anciennes configurations liées au compte Google, telles que des liens vers des espaces de stockage Google Cloud (buckets) qui auraient été mal désactivés. Des cybercriminels pourraient alors tenter d’injecter du code malveillant ou de siphonner des données via ces points d’entrée laissés sans surveillance.

Ce vecteur requiert des conditions spécifiques (p. ex. un « bucket » Google Cloud dont l’URL aurait été publique et qui n’est plus géré par l’utilisateur légitime, phénomène connu sous le nom de dangling bucket) et ne toucherait plus les utilisateurs particuliers que les organisations utilisant Google Cloud. Néanmoins, c’est un rappel que la surface d’attaque ne se limite pas aux emails : tout service associé à un compte Google non maintenu à jour ou correctement fermé peut devenir une opportunité pour les hackers.

Enfin, au-delà des méthodes de phishing classiques, une nouvelle menace plus insidieuse, liée à l’IA générative, a été mise en lumière. Des chercheurs en cybersécurité alertent sur la possibilité d’injecter des instructions malveillantes cachées dans le texte d’un email pour piéger les modèles d’IA intégrés à Gmail.

Google déploie en effet progressivement son modèle de langage Gemini dans Gmail (notamment pour les clients Google Workspace) afin de proposer des résumés automatiques des messages. Or une équipe a démontré en juillet 2025 qu’un attaquant peut concevoir un email dont le contenu comprend, en fin de message, du texte invisible pour l’utilisateur (par exemple en blanc sur fond blanc) contenant une fausse alerte de sécurité.

Lorsque le destinataire ouvre ce mail et que l’IA de Gmail génère le résumé, elle intègre alors cette fausse alerte comme si elle provenait de Google, par exemple un message indiquant « Votre mot de passe a été compromis, appelez d’urgence ce numéro… ».

. Heureusement, à ce jour il ne s’agit que d’une preuve de concept réalisée par des chercheurs, et Google affirme n’avoir observé aucun cas d’exploitation malveillante de Gemini « dans la nature ». L’entreprise a pris ces résultats au sérieux : elle a engagé des mesures pour durcir son modèle (via du red teaming et des filtres empêchant l’IA de relayer du texte caché). Néanmoins, cet exemple souligne que l’essor des outils d’IA dans les communications ouvre de nouvelles surfaces d’attaque qu’il faudra surveiller de près à l’avenir. Les dispositifs automatiques censés assister l’utilisateur peuvent être détournés et devenir involontairement les complices des fraudeurs.

Analyse technique des failles exploitées

Du point de vue technique, la situation actuelle résulte d’un enchaînement de vecteurs d’attaque complémentaires, plutôt que d’une vulnérabilité unique dans Gmail. La compromission initiale chez Google s’est faite via une attaque de social engineering sophistiquée (voix + malware), sans exploitation d’une faille applicative. Ce scénario met en évidence l’importance des mécanismes de sécurité « humains » : formation des employés, procédures de vérification des demandes inhabituelles, authentification renforcée pour les accès sensibles…

L’absence de segmentation stricte ou d’alertes internes lors de l’accès aux données Salesforce a également joué un rôle : bien que Google ait publié juste avant l’attaque un guide de bonnes pratiques pour contrer ce type de menace, cela n’a pas empêché l’intrusion, démontrant que même les entreprises les mieux protégées restent vulnérables dès lors qu’un utilisateur interne est compromis.

La masse d’identifiants diffusée en ligne repose, elle, sur des faiblesses systémiques de l’écosystème web au fil du temps. Des milliards de comptes et de mots de passe ont fuité ces dernières années (violations de grandes entreprises, vols de bases d’utilisateurs, etc.), alimentant un marché noir où ces données sont agrégées et revendues. Aucune entreprise, pas même Google, n’est totalement à l’abri des conséquences de ces fuites externes lorsque ses propres utilisateurs réutilisent leurs mots de passe un peu partout. La technique du credential stuffing ne vise pas la sécurité des serveurs de Google (qui, en l’occurrence, n’a pas été mise en défaut) mais les mauvaises habitudes des utilisateurs.

De fait, même sans faille côté Google, un attaquant peut réussir à accéder à un compte si l’utilisateur a recyclé un mot de passe compromis – d’où l’urgence, pour des milliards de personnes, de changer leurs identifiants après la révélation de cette compilation.

Les attaques de phishing/vishing actuellement observées exploitent quant à elles des principes connus de longue date (usurpation d’identité, ingénierie sociale) mais à une échelle inédite et avec un ciblage plus crédible grâce aux données dérobées. Le fait de posséder le nom, le numéro de téléphone ou certaines informations spécifiques d’un utilisateur Gmail rend le discours de l’escroc plus convaincant (par exemple : « Bonjour M. Dupont, je vous appelle de Google au sujet de votre compte professionnel… »).

Ces attaques ne cherchent pas à casser le chiffrement ou à trouver une faille logicielle : elles visent le maillon faible humain en profitant du contexte anxiogène d’une possible fuite massive. On observe d’ailleurs que les protections multifactorielles imposées par Google (confirmation via smartphone, etc.) ont limité la casse : un mot de passe seul, même valide, ne suffit pas à accéder à un compte Gmail protégé par 2FA.

En revanche, pour les comptes sans double authentification, les dégâts peuvent être graves (accès à tous les e-mails, Google Drive, Photos, etc.) dès qu’un mot de passe figure dans la liste leakée. Là encore, ce n’est pas la robustesse cryptographique de Google qui est en défaut, mais bien le niveau de protection activé par l’utilisateur sur son compte.

Enfin, l’aspect émergent lié aux modèles d’IA intégrés (Gemini) représente un nouveau défi technique de sécurité. On touche ici à des vulnérabilités de type IA/LLM plus qu’à des failles classiques. Le prompt injection est un genre de faille logique où l’attaquant profite du fonctionnement d’un modèle de langage pour lui faire exécuter des instructions non prévues, un peu comme on exploiterait une faille XSS dans une application web pour injecter du code malveillant.

Google travaille déjà à des garde-fous (filtrage du texte caché, détection dans les sorties de l’IA de mots-clés suspects comme des URL ou numéros de téléphone alarmants), mais cela relève d’une course entre attaquants et défenseurs dans un domaine très récent. Pour les professionnels, cela souligne la nécessité d’évaluer les outils d’IA déployés en entreprise sous l’angle de la sécurité : chaque nouvelle fonctionnalité intelligente peut introduire des comportements non anticipés exploitables par des adversaires ingénieux.

Recommandations pour les professionnels de la sécurité (RSSI, analystes, pentesters)

Face à cet incident de grande ampleur, les experts en cybersécurité doivent adopter une approche proactive pour protéger leur organisation et leurs utilisateurs. Voici les principales recommandations à destination des RSSI, équipes SOC/Cert et pentesters :

  • Renforcer l’authentification et l’hygiène des mots de passe : Il est impératif d’augmenter le niveau de sécurité des comptes, notamment les comptes Google Workspace et autres services critiques. Imposez l’authentification multi-facteur (MFA) sur tous les accès possibles – idéalement via des applications ou des clés physiques plutôt que par SMS. Envisagez de déployer les clés de sécurité FIDO2/passkeys qui offrent une protection sans mot de passe très résistante au phishing. Vérifiez également que les mots de passe respectent les bonnes pratiques (complexité et unicité) : bannissez la réutilisation des mots de passe entre services. Des campagnes internes de sensibilisation accompagnées de gestionnaires de mots de passe peuvent aider les collaborateurs à adopter ces mesures sur leurs comptes personnels comme professionnels. Enfin, tenez à jour les correctifs de vos navigateurs, applications Google et systèmes, certaines attaques pouvant exploiter des failles déjà connues si elles ne sont pas patchées.

  • Surveiller les identifiants compromis et les tentatives suspectes : Considérez cet événement comme une opportunité de renforcer votre rôle de veille et de détection. Surveillez activement les bases de données leakées pour identifier si des adresses e-mail de votre organisation ou de vos clients y figurent (des services comme Have I Been Pwned peuvent aider à vérifier si des comptes d’entreprise ont été exposés – en veillant au respect des règles internes et de la confidentialité). Si c’est le cas, forcez immédiatement une réinitialisation de mot de passe des comptes concernés et une invalidation des sessions actives. Mettez en place des alertes sur les systèmes d’authentification pour repérer les connexions échouées en masse ou provenant de localisations inhabituelles, signes d’attaques par credential stuffing. Google propose un outil de Security Checkup à destination des utilisateurs, mais côté entreprise vous pouvez intégrer ces indicateurs dans votre SIEM : par exemple, un pic de tentatives de connexion sur des comptes valides bloquées par Google (alerte « sign-in prevented ») doit immédiatement déclencher une enquête. En outre, surveillez les échanges sur les forums clandestins : l’alliance ShinyHunters/UNC6040 a menacé de publier les données volées sur son propre site de leak, il faut donc suivre l’évolution de cette menace (ce qui pourrait exposer plus largement encore les données et inciter à d’autres attaques ciblées).
  • Sensibiliser et tester les utilisateurs face au phishing/vishing : Même les meilleures technologies échouent si l’humain cède à la tromperie. Renforcez vos programmes de sensibilisation en insistant sur les nouvelles méthodes employées par les attaquants. Informez clairement que Google (ou tout autre fournisseur) ne contactera jamais un utilisateur par téléphone pour lui demander son mot de passe ou un code de vérification : ce message doit être su et répété par tous. De même, formez les utilisateurs à reconnaître les signes d’un email frauduleux même s’il ressemble à une alerte de sécurité (adresse d’expéditeur légèrement altérée, liens qui pointent vers autre chose qu’un domaine google.com, ton urgent demandant une action immédiate, etc.). Menez des exercices de type phishing drill et même vishing : par exemple, planifiez des faux appels de support simulés envers un échantillon d’employés pour tester leurs réactions et, surtout, les éduquer de manière pratique (ce genre d’attaques étant de plus en plus répandu). Les pentesters « red team » peuvent vous accompagner en intégrant ces scénarios dans leurs audits de sécurité humains. L’objectif est de créer des réflexes : un collaborateur qui reçoit un appel inattendu du « support » doit instinctivement vérifier l’identité de l’interlocuteur via un canal officiel, et un email même alarmant doit faire l’objet de vérifications avant de cliquer. En renforçant la culture de la méfiance constructive, on réduit grandement la surface d’attaque sociale.

  • Sécuriser les accès tiers et les données clients : L’attaque initiale via Salesforce rappelle que les fournisseurs tiers et applications cloud utilisées par votre organisation peuvent devenir la porte d’entrée. Un RSSI doit s’assurer que les accès aux outils SaaS (CRM, stockage cloud, etc.) sont gérés en zero trust. Auditez les droits et tokens d’accès sur vos instances cloud : supprimez les comptes/projets inactifs, révisez les mots de passe des intégrations et imposez le MFA partout où c’est possible. Limitez les droits des utilisateurs et des applications aux seules données nécessaires (least privilege), de sorte qu’un éventuel compte compromis donne accès au minimum d’informations. Dans le cas de Google Workspace, profitez des outils d’admin : surveillez les applications tierces connectées à vos comptes Google (OAuth) et révoquez celles qui sont superflues ou non approuvées – les attaquants de ShinyHunters ont utilisé des comptes compromis d’autres entreprises pour enregistrer de fausses applications malveillantes, ce qui doit inciter à la vigilance sur les apps ayant accès à vos données. Si votre entreprise développe des fonctionnalités autour de Gmail/Google Cloud, suivez les bonnes pratiques de sécurisation des ressources cloud : par exemple, Google recommande de vérifier qu’aucun storage bucket supprimé n’est encore référencé quelque part (dangling bucket), afin d’éviter qu’un attaquant ne revendique cet emplacement pour distribuer du code malveillant. En somme, appliquez scrupuleusement le modèle de responsabilité partagée : même si le fournisseur cloud offre des contrôles de sécurité robustes, c’est à vous de bien les configurer et de former vos utilisateurs à s’en servir correctement.

  • Anticiper les menaces liées à l’IA et aux nouvelles techniques : Les responsables sécurité doivent intégrer dans leur stratégie les vecteurs d’attaque émergents tels que les prompt injections. Si vous déployez des assistants intelligents ou outils de résumé automatiques, évaluez les risques : pouvez-vous filtrer/neutraliser le contenu caché dans les données traitées ? Des solutions commencent à apparaître, par exemple supprimer ou rendre inoffensif tout texte stylé en invisible dans les emails avant qu’il ne soit analysé. Vous pouvez également implémenter un filtre de sortie sur les réponses de l’IA : par exemple, détecter si un résumé d’email contient un langage d’alerte de sécurité, un URL ou un numéro de téléphone, et dans ce cas le marquer pour relecture manuelle plutôt que de le présenter tel quel à l’utilisateur. Ne considérez pas les contenus générés par l’IA comme intrinsèquement fiables, surtout s’ils concernent la sécurité. Mettez en place une veille sur les vulnérabilités des modèles de langage (consultez par exemple les programmes bug bounty comme celui de Mozilla 0din qui a révélé la faille Gemini). Enfin, partagez ces connaissances au sein de la communauté : les attaques IA étant encore nouvelles, la coopération entre chercheurs, RSSI et éditeurs sera cruciale pour établir rapidement des bonnes pratiques de défense.

En synthèse, cette crise autour de Gmail pourrait être un électrochoc pour la communauté sécurité par son ampleur, mais les outils pour y faire face sont connus : renforcement de l’authentification, rigueur dans la gestion des identités, sensibilisation anti-phishing, et adaptation continue aux nouvelles menaces. Les RSSI doivent s’assurer que les leçons de cet incident – pourtant multi-factoriel – sont bien tirées au sein de leur organisation, car elles confirment plusieurs principes fondamentaux de la cybersécurité.

Comme toujours, c’est en combinant technologie, processus et facteur humain que l’on pourra réduire l’exposition aux attaques, qu’elles exploitent des bases de données volées, la confiance des utilisateurs ou l’intelligence artificielle. En agissant dès maintenant sur ces recommandations, les experts pourront non seulement protéger leurs utilisateurs Gmail, mais aussi renforcer globalement la résilience de leur environnement face aux prochaines vagues d’attaques annoncées.

Sources :

  • Google (Blog officiel – Google Threat Intelligence Group) – https://cloud.google.com/blog/topics/threat-intelligence/voice-phishing-data-extortion
  • Forbes – https://www.forbes.com/sites/zakdoffman/2025/08/25/google-confirms-most-gmail-users-must-change-passwords/
  • The Sun (Royaume-Uni) – https://www.thesun.co.uk/tech/36404957/google-hack-gmail-users-risk/
  • TechCrunch – https://techcrunch.com/2025/08/06/google-says-hackers-stole-its-customers-data-in-a-breach-of-its-salesforce-database/
  • Axios – https://www.axios.com/2025/08/06/google-shinyhunters-salesforce-data-breach
  • The Times of India – https://timesofindia.indiatimes.com/technology/tech-news/google-admits-shinyhunters-steal-data-in-salesforce-hack-the-data-retrieved-by-the-threat-actor-was-/articleshow/123167758.cms
  • The Economic Times (Inde) – https://economictimes.indiatimes.com/news/international/global-trends/us-news-2-5-billion-gmail-accounts-warned-scammers-using-us-650-area-code-to-trick-millions-what-should-you-do/articleshow/123473376.cms
  • BleepingComputer – https://www.bleepingcomputer.com/news/security/google-confirms-data-breach-exposed-potential-google-ads-customers-info/
  • DataBreaches.net – https://databreaches.net/2025/08/08/shinyhunters-sent-google-an-extortion-demand-shiny-comments-on-current-activities/
  • SecurityAffairs – https://securityaffairs.com/181017/data-breach/google-confirms-salesforce-crm-breach-faces-extortion-threat.html
  • Clubic – https://www.clubic.com/actualite-576711-votre-compte-gmail-est-compromis-il-est-temps-de-changer-de-mot-de-passe-ou-de-messagerie.html
  • Journal du Geek – https://www.journaldugeek.com/2025/08/25/google-en-alerte-maximale-25-milliards-dutilisateurs-gmail-doivent-changer-leur-mot-de-passe-en-urgence/