Aller au contenu

Phishing Google Ads et LLMjacking : comment des attaquants détournent un compte Google Cloud

Par l’équipe AXELITES

Chaîne d’attaque LLMjacking sur Google Cloud : publicité Google Ads frauduleuse, vol des identifiants et du MFA, usage détourné de l’API Gemini

Une recherche « google cloud » sur Google, une publicité en tête des résultats, une page de connexion identique à l’originale : il n’en faut pas plus pour qu’un attaquant récupère les identifiants et le code de double authentification d’un administrateur cloud. Quelques heures plus tard, la victime découvre une facture d’intelligence artificielle qu’elle n’a jamais consommée.

Le 20 octobre 2026, l’équipe de réponse à incident de Wiz a documenté plusieurs campagnes de ce type visant Google Cloud, sous le nom de « LLMjacking ». Ce guide explique le déroulé de l’attaque, ce que l’attaquant cherche, pourquoi tout semble légitime pour l’utilisateur, et les mesures qui l’arrêtent.

1. Une publicité Google qui mène à une fausse page de connexion

Tout commence par une recherche banale. L’utilisateur tape « google cloud » dans Google pour ouvrir sa console. En tête des résultats s’affiche une publicité sponsorisée, acceptée par Google Ads, qui renvoie vers une fausse page de connexion Google Cloud : même interface, même apparence, rien de suspect à première vue. L’utilisateur saisit ses identifiants, valide sa double authentification et pense se connecter normalement. Il est sur une page de phishing.

Wiz décrit précisément ce mode opératoire. L’attaquant achète des annonces Google sur des recherches d’administration courantes comme « google cloud » et « gcp ». Le clic passe par une redirection hébergée sur Google Sites avant d’arriver sur la fausse page, qui capture l’identifiant, le mot de passe et le code de double authentification, puis renvoie l’utilisateur vers la vraie page de connexion de Google. Obligé de s’authentifier une seconde fois, l’utilisateur croit à un simple incident technique.

  • Une annonce sponsorisée en tête des résultats pour une recherche d’administration (« google cloud », « gcp »).
  • Une redirection, puis une fausse page de connexion Google identique à l’originale.
  • La saisie de l’identifiant, du mot de passe et du code de double authentification, capturés au passage.
  • Un retour vers la vraie page de Google, qui redemande une connexion et masque la manipulation.

2. Un code de double authentification rejoué aussitôt

La double authentification ne protège pas ici, parce que le code est utilisé dans les secondes qui suivent sa saisie. D’après Wiz, le kit de phishing est automatisé : il se sert des identifiants volés dès leur capture pour ouvrir une première session dans l’environnement Google Cloud de la victime, depuis sa propre adresse IP.

L’attaquant se reconnecte ensuite, quelques minutes plus tard, depuis une seconde adresse IP qui sert au reste de l’attaque. Dans toutes les intrusions étudiées par Wiz, les connexions suivantes proviennent d’adresses situées dans le pays du siège de la victime, même quand ce n’est pas le pays où se trouve l’utilisateur, pour ne pas déclencher les alertes géographiques.

3. Ce que Wiz a documenté

Wiz, spécialiste de la sécurité cloud dont le rachat par Google a été finalisé le 11 mars 2026, a publié le 20 octobre 2026 l’analyse de plusieurs intrusions suivant ce schéma, en se concentrant sur celles qui visent Google Cloud. L’article décrit l’ensemble de la chaîne d’attaque : fausse publicité Google Ads, vol des identifiants et du code de double authentification, puis utilisation frauduleuse de l’API Gemini aux frais de la victime.

Wiz publie aussi des indicateurs de compromission, dont l’adresse IP du kit de phishing et une liste de domaines qui imitent le nom de Google, ainsi que les recherches à lancer dans les journaux. L’article est cité dans les sources en bas de page : c’est la référence à consulter pour vérifier votre propre environnement.

4. LLMjacking : détourner la facturation cloud pour payer de l’IA

Wiz emploie le terme LLMjacking pour décrire des attaquants qui détournent les comptes de facturation cloud de leurs victimes afin de financer un usage massif de grands modèles de langage (LLM). L’objectif n’est ni de chiffrer les données ni de casser l’environnement : c’est une exploitation financière, où la victime paie la consommation d’IA de l’attaquant.

Une fois connecté, l’attaquant de la campagne décrite par Wiz se sert des droits étendus du compte volé pour s’installer durablement. Point important : les projets externes rattachés au compte de facturation exécutent leurs requêtes d’IA chez l’attaquant. La victime paie la consommation, mais ses propres journaux ne montrent ni les requêtes ni les réponses des modèles.

  • Activer l’API Gemini dans des projets existants et peu utilisés, puis y créer des comptes de service et des clés d’API Gemini.
  • Attribuer à ces comptes de service des rôles à hauts privilèges, comme roles/ml.admin.
  • Supprimer au niveau de l’organisation la règle iam.allowedPolicyMemberDomains, qui réserve les accès aux domaines de l’entreprise.
  • Ajouter des comptes Gmail extérieurs au compte de facturation, avec le rôle roles/billing.admin.
  • Rattacher au compte de facturation de la victime des projets Google Cloud contrôlés par l’attaquant.
  • Rétrograder les administrateurs de facturation légitimes en simples lecteurs, pour les empêcher de détacher ces projets depuis la console.

5. Une facture d’IA qui s’emballe en quelques heures

Pour les intrusions qu’il a analysées, Wiz indique que les victimes ont vu apparaître, dans les 24 à 48 heures suivant l’accès initial, des frais de plusieurs dizaines à plusieurs centaines de milliers de dollars d’usage non autorisé de l’API Gemini, bien au-delà de leur consommation habituelle. C’est souvent la facture, et non une alerte de sécurité, qui révèle l’attaque.

Sur Google Cloud, les modèles Gemini sont aussi proposés par Vertex AI, la plateforme d’IA que Google a renommée Gemini Enterprise Agent Platform en avril 2026. Une consommation anormale peut donc apparaître sous l’un ou l’autre de ces noms dans la facturation : c’est la hausse soudaine qui doit alerter, quel que soit le service affiché.

6. Pourquoi tout semble légitime

Ce qui frappe dans cette attaque, c’est qu’à aucun moment l’utilisateur n’a de raison objective de se méfier. La publicité a été acceptée par Google Ads, le lien frauduleux est mis en avant sur Google, la page reproduit fidèlement l’interface de connexion, et la connexion de l’attaquant est acceptée avec un mot de passe et un code valides. Pour l’utilisateur, tout semble légitime ; c’est pourtant un piège du début à la fin.

Wiz apporte deux précisions. Dans les cas qu’il décrit, Google a signalé la connexion comme suspecte et envoyé des alertes de sécurité par e-mail à l’utilisateur, et Google Ads a retiré la campagne après les signalements. Wiz en conclut que les organisations ne doivent pas compter sur la seule vigilance des utilisateurs, mais surveiller elles-mêmes les événements de connexion. Le procédé, une annonce sponsorisée qui mène à une fausse page de connexion, n’a d’ailleurs rien de propre à Google Cloud : il peut viser n’importe quel service sensible, une banque, AWS, Azure ou Microsoft 365.

7. Deux réflexes qui évitent l’attaque

Le premier réflexe ne coûte rien. Une page de phishing ne fonctionne que si l’on y arrive : en ouvrant ses consoles depuis un favori enregistré plutôt que depuis un moteur de recherche, l’utilisateur ne voit jamais la publicité frauduleuse.

Le second concerne la double authentification. Dans cette attaque, le code est saisi sur la fausse page et rejoué aussitôt par l’attaquant : un code reçu par SMS ou généré par une application ne protège pas contre ce relais. Les passkeys et les clés de sécurité FIDO2 résistent au phishing ; Google présente les clés de sécurité comme la forme de validation en deux étapes la plus sûre, qui protège contre le phishing. À défaut, une validation sur téléphone avec vérification du numéro vaut mieux qu’un simple SMS : l’agence américaine de cybersécurité CISA la recommande comme mesure intermédiaire contre les demandes de validation à répétition, tout en rappelant qu’elle reste moins robuste qu’une méthode résistante au phishing.

  • Enregistrez vos consoles d’administration (Google Cloud, AWS, Azure, Microsoft 365, banque) dans vos favoris et passez toujours par eux.
  • Activez les passkeys ou les clés FIDO2 pour les comptes à privilèges, en priorité les administrateurs et les responsables de la facturation.
  • À défaut, préférez la validation sur téléphone avec vérification du numéro au code SMS.

8. Côté Google Cloud : vérifier et limiter les dégâts

Si vous administrez un environnement Google Cloud, les recommandations de détection de Wiz forment une bonne liste de contrôle, même sans indice d’attaque. Elles portent sur les journaux de Google Workspace, les journaux d’activité d’administration de Google Cloud et ceux de la facturation.

Côté prévention, la règle d’organisation qui limite les accès aux domaines de l’entreprise doit rester active et surveillée, puisque sa suppression est l’une des premières actions de l’attaquant. Côté coûts, Google rappelle qu’un budget classique ne fait qu’envoyer des alertes et ne plafonne pas la dépense ; les budgets avec plafond de dépenses, eux, suspendent l’usage des services éligibles dans un projet une fois le montant atteint. Wiz recommande de surveiller les hausses anormales de consommation d’API et d’envisager ces plafonds.

  • Rechercher dans les journaux Google Workspace et Google Cloud les indicateurs de compromission publiés par Wiz (adresse IP du kit de phishing et domaines de phishing).
  • Lister les utilisateurs IAM rattachés à un domaine extérieur, en particulier les adresses @gmail.com.
  • Contrôler les modifications des règles d’organisation, notamment allowedPolicyMemberDomains, et les changements d’administrateurs du compte de facturation.
  • Repérer les activations d’API Gemini, les créations de comptes de service et de clés d’API inattendues, surtout dans d’anciens projets.
  • Vérifier les projets rattachés au compte de facturation et mettre en place alertes et plafonds de dépenses.

9. Ce qu’il faut retenir

On parle beaucoup de pare-feu, d’antivirus et de solutions de sécurité sophistiquées. Cette attaque rappelle que cliquer sur le premier résultat Google peut suffire à compromettre tout un environnement cloud, double authentification comprise, et que le premier signe visible est souvent la facture.

Les parades sont pourtant simples et peu coûteuses : des favoris pour accéder aux consoles, une authentification résistante au phishing pour les comptes à privilèges, des droits de facturation réduits au strict nécessaire, des alertes sur les connexions et sur les coûts. C’est ce que nous mettons en place chez nos clients en hébergement et en infogérance.

Questions fréquentes

Qu’est-ce que le LLMjacking ?
C’est le détournement d’un environnement cloud pour faire payer à la victime un usage massif de modèles d’IA. Dans la campagne décrite par Wiz, l’attaquant vole les accès d’un compte Google Cloud, active l’API Gemini, s’ajoute au compte de facturation et y rattache ses propres projets : la victime paie, sans voir les requêtes exécutées.
Comment savoir si notre organisation est touchée ?
Recherchez dans vos journaux Google Workspace et Google Cloud les indicateurs de compromission publiés par Wiz, puis vérifiez les comptes extérieurs (notamment @gmail.com) dans IAM et dans la facturation, les modifications des règles d’organisation, les clés d’API récentes et les projets rattachés à votre compte de facturation. Une hausse soudaine de la consommation d’IA est souvent le premier signe visible.
La double authentification ne suffit-elle pas ?
Non, pas sous toutes ses formes. La fausse page capture le code de double authentification et l’attaquant l’utilise aussitôt. Seules les méthodes résistantes au phishing, comme les passkeys et les clés FIDO2, empêchent ce relais. La vérification du numéro sur téléphone reste préférable au SMS, mais la CISA la considère comme une mesure intermédiaire.
Que faire si la facture a déjà explosé ?
Reprenez d’abord le contrôle : réinitialisez les accès du compte compromis, retirez les comptes extérieurs, rétablissez les administrateurs de facturation, détachez les projets inconnus du compte de facturation et désactivez les clés d’API créées par l’attaquant. Conservez les journaux, puis contactez le support facturation de Google Cloud avec la chronologie de l’incident.
Ce type d’attaque concerne-t-il seulement Google Cloud ?
Non. Wiz indique avoir enquêté sur plusieurs intrusions de ce type et se concentrer dans son article sur Google Cloud. Une publicité sponsorisée qui mène à une fausse page de connexion peut viser n’importe quel service sensible : une banque, AWS, Azure ou Microsoft 365. Les mêmes réflexes s’appliquent : favoris et authentification résistante au phishing.

Sources et documentation

Services liés

Faites vérifier vos accès cloud

Décrivez votre environnement (Google Cloud, AWS, Azure, Microsoft 365) : nous analysons les journaux, sécurisons les comptes à privilèges et mettons en place les alertes de connexion et de coûts.

Demander une vérification

D’autres ressources

Tout voir