Google confirme un incident ciblant une instance Salesforce utilisée pour la prospection. Les données exfiltrées restent limitées, mais l’alerte est sérieuse. Pourquoi cette fuite chez google marque-t-elle un tournant, et quelles défenses mettre en place sans tarder face au piratage et aux attaques de sécurité informatique ?
Le 5 août 2025, Google a reconnu qu’une intrusion en juin 2025 avait touché “l’une de [ses] instances Salesforce”, un outil de gestion de la relation client (Customer Relationship Management, CRM), exposant des données liées à des prospects de Google Ads. Le 8 août, Google a indiqué avoir terminé l’envoi de ses notifications par e-mail aux parties concernées. Le 11 août, un article de 01net a évoqué une ampleur potentielle plus large du piratage.
Google confirme avoir été piraté
Google a détaillé l’essentiel dans une note de son équipe Threat Intelligence. L’attaque, attribuée au collectif ShinyHunters (également suivi par Google sous le nom UNC6040), a ciblé un périmètre Salesforce précis. Selon Google, l’instance servait à stocker des données professionnelles “de contact” et des “notes associées” sur des petites et moyennes entreprises. Google parle d’éléments largement accessibles, donc a priori moins sensibles que des identifiants de paiement ou des mots de passe. Mais suffit-il que ces données soient publiques pour être inoffensives ? Certainement pas. La sécurité, c’est aussi la combinaison et le contexte.
Google insiste également sur deux points opérationnels de sécurité informatique. D’abord, l’accès illicite a été interrompu “après une brève fenêtre” d’exfiltration. Ensuite, les équipes ont conduit une analyse d’impact et lancé les notifications, confirmées le 8 août. La méthode d’intrusion relève du piratage par ingénierie sociale, en particulier du vishing (hameçonnage vocal) qui pousse des employés à installer ou autoriser des outils illégitimes liés à Salesforce. Dans un environnement cloud, un simple appel peut faire tomber une digue. Google le sait, les attaquants aussi.
Google et la guerre de l’ingénierie sociale : le piratage par vishing en ligne de mire
Pourquoi cette campagne touche-t-elle Google ? Parce que les acteurs comme ShinyHunters cultivent une attaque à bas coût : usurper une identité, téléphoner, pousser à l’erreur, puis vider une instance CRM. Le piratage ne repose pas sur une faille “zéro-day” spectaculaire, mais sur une mécanique humaine. Plusieurs médias spécialisés expliquent que la tactique, c’est le vishing et des resets d’identifiants abusifs. Selon 01net, pas moins de 2,55 millions d’enregistrements de données ont été touchés.
Les données concernées sont décrites par Google comme “des informations commerciales de base” : noms d’entreprises, coordonnées, notes de prospection. Pas de paiement, pas de données de compte Ads ou d’Analytics selon un recoupement de BleepingComputer. Faut-il pour autant minimiser ? Non. Ce type de fuite sert de matière première à des campagnes de phishing hyper ciblées. Les prospects Google Ads sont, par définition, des organisations déjà en interaction avec google. Un courriel semblant provenir d’un chargé de compte, un appel prétendant “vérifier un IBAN” pour une facturation, et l’ancre est jetée. C’est ici que la sécurité informatique rejoint l’art de la fraude.
Alors, que faire côté utilisateurs ? Google a terminé d’envoyer ses alertes par e-mail, mais le meilleur pare-feu reste la discipline. D’abord, vérifier chaque sollicitation liée à google par un canal indépendant : ne jamais rappeler un numéro fourni dans un message inattendu ; passer par l’interface Google Ads officielle pour toute action sensible. Ensuite, exiger la double authentification (MFA) partout, y compris pour les accès Salesforce si votre entreprise l’emploie. Enfin, former les équipes aux scénarios de vishing : un appel pressant, une “mise à jour” d’outil, une URL oblique… Si c’est urgent, c’est suspect.
Google et protection : gestes immédiats pour les annonceurs et partenaires
Pour les entreprises ayant interagi avec Google autour de Google Ads, la priorité est double. Sur le périmètre Google, revisiter les rôles, les accès, les comptes administrateurs, et purger les utilisateurs inactifs. Sur le périmètre interne, surtout si Salesforce est utilisé, renforcer les politiques d’authentification, bannir l’installation de “Data Loader” non officiels, et instaurer un protocole de vérification par double canal pour toute demande de modification sensible (moyen de paiement, titulaire du compte, transfert d’actifs publicitaires).
