L'essor du LLMJacking : comment les acteurs malveillants monétisent les ressources cloud et de modélisation compromises
La rédaction ·
Stoppez les attaques, réduisez les risques et renforcez votre sécurité.
En 2026, Mandiant a réagi à de multiples incidents au cours desquels des acteurs malveillants ont détourné l'accès des entreprises aux Large Language Models (LLM), une tactique connue sous le nom de « LLMJacking ». Touchant divers fournisseurs de cloud et de LLM, ces intrusions ont affecté des organisations en Amérique du Nord, en Amérique du Sud et en Asie-Pacifique dans les secteurs des services financiers, du commerce de détail, de la technologie et des transports.
Mandiant est une entreprise américaine de cybersécurité fondée en 2004 et rachetée par Google en 2022, puis pleinement intégrée au sein de Google Cloud
Contrairement à la consommation progressive de ressources associée au cryptojacking, le LLMJacking peut générer des pics importants de facturation frauduleuse sur le cloud en quelques heures seulement. Lors d'incidents individuels, nous avons observé des facturations frauduleuses liées à une consommation de ressources dépassant 100 000 USD en une seule journée, et des facturations cumulées atteignant 1 million de dollars dans certaines organisations avant que l'accès ne soit révoqué.
Figure 1 : Graphique d'utilisation montrant que LLMJacking génère un pic de requêtes API
En analysant l'écosystème criminel derrière ces compromissions de première ligne et en s'appuyant sur des rapports précédents sur le marché clandestin croissant des identifiants LLM, le Google Threat Intelligence Group (GTIG) a identifié un ensemble diversifié de groupes de menaces à motivation financière opérant dans plusieurs régions du monde.
À mesure que l'écosystème du LLMJacking se développe, nous observons également une division du travail entre les acteurs malveillants qui établissent l'accès initial aux environnements compromis et les opérateurs qui gèrent l'infrastructure de monétisation en aval, appelée « LLM Mixers ». Les LLM Mixers fonctionnent comme des passerelles de routage illicites qui servent de proxy, agrègent et revendent l'accès LLM non autorisé à des abonnés clandestins. Lors d'une enquête, le GTIG a observé deux groupes opérationnels distincts qui se coordonnaient pour compromettre et monétiser l'infrastructure LLM d'entreprise, illustrant ainsi la spécialisation sophistiquée qui se développe dans ce domaine.
Dans cet article de blog, nous décrivons le cycle de vie des attaques observé lors des récentes enquêtes sur le LLMJacking et fournissons des conseils pratiques en matière de détection, de renforcement et de correction pour aider les organisations à sécuriser leur infrastructure.
Accès initial
Alors que le vol de ressources de bas niveau consiste à manipuler les chatbots du support client pour effectuer des tâches non autorisées telles que la génération de code, les acteurs malveillants pratiquant le LLMJacking contournent ces interfaces frontales pour cibler directement les ressources des modèles backend. Plus précisément, ils s'attachent soit à identifier les points d'accès LLM exposés publiquement, soit à obtenir des clés d'API LLM valides. Un exemple de ce dernier cas est visible sur la figure 1, où un acteur malveillant utilise un script automatisé pour vérifier l'exposition en appelant le /api/createpoint d'accès afin d'exécuter indépendamment ses propres modèles sur des points d'accès laissés accessibles publiquement par des utilisateurs non avertis. Laisser ces services sans protection augmente non seulement la surface d'attaque traditionnelle d'une organisation, mais peut également engendrer une hausse significative des coûts d'hébergement.
Figure 2 : Un acteur malveillant teste des points d’accès Ollama exposés publiquement et tente d’enregistrer ses propres modèles.
Dans de multiples enquêtes LLMJacking, cependant, le vecteur d'accès initial dominant a été constitué par des jetons d'identité cloud exposés ou volés, notamment les identifiants IAM, les clés de compte de service, les jetons d'accès personnels GitHub (PAT) et les jetons de session actifs, que les acteurs malveillants exploitent pour établir un premier point d'appui dans l'infrastructure des organisations cibles.
Par exemple, mi-2026, UNC6993 a compromis une instance cloud via une clé de compte de service mal configurée et a utilisé cet accès pour obtenir un accès supplémentaire à une API LLM. UNC6993 hébergeait également une page de détournement de session se faisant passer pour un portail d'application permettant de rejoindre un groupe d'utilisateurs LLM. Cette page incitait les utilisateurs à se rendre sur le site web légitime du service LLM et à y coller leur charge utile JSON brute contenant un jeton d'accès actif, lequel était ensuite envoyé à l'API backend pour contourner les contrôles de mot de passe et d'authentification multifacteurs (MFA).
Dans un autre cas, un acteur malveillant a initialement pénétré le système en combinant un jeton d'accès personnel (PAT) volé pour accéder à des dépôts de code privés avec l'exploitation d'une vulnérabilité suspectée d'une application web exécutée dans un environnement cloud conteneurisé. De même, un autre acteur malveillant a exploité des identifiants IAM compromis d'utilisateurs d'entreprise, utilisant des jetons de fédération cloud pour générer par programmation de nouvelles clés d'accès afin de contourner les exigences d'authentification multifacteur (MFA). Dans un incident distinct, un acteur malveillant a été initialement observé accédant à l'environnement avec une clé de compte de service cloud compromise disposant de larges autorisations de projet.
Outre les identifiants d'authentification cloud classiques, les acteurs malveillants ciblent également les clés API LLM. Par exemple, un acteur malveillant a exploité de manière opportuniste des clés API LLM d'entreprise exposées sur des dépôts GitHub publics. Faisant preuve d'une technique d'évasion avancée, le groupe a mené des analyses automatisées de validation d'identifiants à l'aide de requêtes minimales à jeton unique max_tokens=1. Cela lui a permis de confirmer discrètement la validité des clés volées, sans être détecté par les alertes d'anomalies de volume des systèmes EDR (Endpoint Detection and Response) et SIEM (Security Information Management Event) de la victime.
Mouvement latéral et persistance
Après avoir pris pied initialement, les acteurs malveillants s'efforcent systématiquement d'élever leurs privilèges, de consolider leur accès et de mener une reconnaissance interne afin d'identifier des cibles et d'obtenir davantage d'identifiants d'accès au cloud.
Pour étendre leur accès, les acteurs malveillants ont recensé les services cloud, les dépôts de code et les bases de données à la recherche d'identifiants sensibles. Lors d'une intrusion, un acteur malveillant a mené une reconnaissance interne sur plusieurs régions cloud afin de cartographier les services disponibles et les politiques d'identité.
Lors d'une autre intrusion, un acteur malveillant a compromis un environnement cloud conteneurisé. Une fois à l'intérieur, il a effectué une reconnaissance approfondie des dépôts, clonant des bases de code sensibles pour rechercher des secrets codés en dur, des variables de configuration et des identifiants de développeur. Il a également analysé les journaux d'accès pour identifier les identifiants des environnements cloud secondaires.
Les acteurs malveillants ont également exécuté des requêtes de base de données ciblées pour collecter des identifiants supplémentaires ; dans un cas, l'acteur malveillant a interrogé les tables de métadonnées d'un entrepôt de données cloud pour rechercher des identifiants de base de données, des mots de passe d'administrateur et des colonnes sensibles, tout en effectuant des opérations de stockage d'objets cloud associées au vol de données ciblé.
Lors de diverses intrusions, nous avons observé des acteurs malveillants abusant des permissions d'identité cloud et des configurations de machines virtuelles pour élever leurs privilèges et maintenir un accès persistant. Un acteur malveillant a exploité les privilèges de création de jetons via des comptes de service associés à des charges de travail compromises afin de générer des identifiants temporaires pour des comptes de service à privilèges élevés.
Ceci a permis l'exfiltration d'identifiants d'infrastructure, de mots de passe de bases de données internes et de clés API tierces provenant de gestionnaires de secrets cloud. D'autres acteurs malveillants ont établi leur persistance en créant des comptes IAM et de service non autorisés et en injectant des clés SSH dans des instances de calcul.
Plus précisément, un acteur a élevé ses privilèges en associant des politiques d'administration à des rôles de service, en créant des comptes IAM non autorisés disposant de droits d'administration complets et en établissant des sessions de gestion interactives avec des machines virtuelles en cours d'exécution afin d'injecter des clés publiques SSH non autorisées dans les fichiers de configuration de l'hôte.
De même, un autre acteur malveillant a créé des comptes de service de type porte dérobée, déguisés en utilitaires internes d'optimisation de la facturation, et a injecté des clés SSH à l'échelle de l'environnement dans les métadonnées des instances de calcul.
Outre l'exploitation des permissions traditionnelles des infrastructures cloud, nous avons observé des cas où des acteurs malveillants ciblent des vulnérabilités spécifiques au sein du logiciel de routage LLM pour élever leurs privilèges. Dans un cas précis, après avoir obtenu des clés virtuelles pré-validées auprès de l'acteur malveillant ayant établi l'accès initial, un cluster ultérieur a exécuté une exploitation ciblée de la logique applicative sur la passerelle LiteLLM de la victime.
L'acteur a exploité une vulnérabilité de réassociation d'identifiants utilisateur dans le point de terminaison /key/regenerate (CVE-2026-40217) pour transformer des clés virtuelles standard en identifiants d'administrateur principal PROXY_ADMIN , établissant ainsi un contrôle étendu et persistant sur l'environnement compromis.
Abus de LLM
L'objectif ultime du LLMJacking est la monétisation et le détournement des ressources des modèles de base, ce que les acteurs réalisent grâce au proxy de jetons, au streaming automatisé de modèles et à la fourniture de matériel GPU.
Les acteurs malveillants ont fréquemment activé diverses plateformes génératives gérées et créé des clés API supplémentaires pour étendre leurs opérations. Après avoir obtenu des clés d'accès à l'API LLM, UNC6993 a tenté de générer d'autres clés API et d'activer les services associés au sein des projets cloud des victimes, accumulant rapidement plus de 100 000 $ de frais facturés.
Un autre acteur malveillant a souscrit des comptes victimes à des contrats de paiement à l'usage, en sélectionnant des modèles de base premium et en lançant des flux d'inférence à haut volume. Pour contourner les limites de débit, cet acteur malveillant a déployé une stratégie de « création et de rotation », créant et supprimant continuellement des comptes de service éphémères tout en auditant l'interface de facturation du fournisseur de cloud afin de surveiller l'impact financier.
Les acteurs malveillants ont également exploité leur accès pour héberger leurs propres points de terminaison proxy et charges de travail d'agents. Par exemple, l'un d'eux a activé des agents, déployé des proxys inverses accessibles publiquement et utilisé des bundles proxy Node.js personnalisés pour exposer des points de terminaison compatibles avec plusieurs LLM Frontier, rebaptisés sous une identité spécifique D1337-KAIROS. L'acteur a déployé une porte dérobée conteneurisée, utilisant le framework d'agents Manus , dans l'environnement cloud compromis.
Cette porte dérobée interrogeait un LLM en amont pour analyser les instructions et exécuter localement les commandes résultantes, grâce au métamoteur de recherche SearXNG et aux environnements d'exécution agent-infra/sandbox . Pour augmenter la puissance de calcul, l'acteur malveillant a provisionné des instances de calcul avec des GPU puissants, a tenté de déployer du matériel haut de gamme dans plusieurs régions et a demandé des augmentations de quota via l'API du fournisseur cloud. Il a également hébergé des passerelles LiteLLM sur des serveurs externes pour gérer et acheminer le trafic API.
Plutôt que d'utiliser la puissance de calcul détournée uniquement pour leurs propres opérations, GTIG a constaté que des acteurs malveillants monétisaient les quotas d'API compromis en vendant l'accès à ces ressources via des mélangeurs LLM. Ces acteurs utilisaient des passerelles API open source et une infrastructure de relais personnalisée pour mutualiser les identifiants volés, mesurer l'utilisation et masquer l'origine des requêtes.
Par exemple, le groupe UNC6993 utilisait des outils open source tels que new-api (un hub et une passerelle de modèles centralisés) et gcli2api (un outil proxy API convertissant les outils d'interface en ligne de commande (CLI) en points de terminaison standard du modèle Frontier), probablement pour agréger les clés volées et répartir la charge des requêtes entre les comptes. Nous pensons que l'acteur malveillant vend l'accès à ces outils via des plateformes clandestines.
Un autre acteur malveillant, ayant exécuté plus de 500 000 appels à l'API LLM en moins de huit heures, a exploité des clés API tierces volées pour alimenter son service de routage de jetons jet-night.com. Jet Night a ainsi refacturé près d'un million de dollars de frais de jetons à l'organisation victime. Étant donné que le coût par jeton proposé par Jet Night est nettement inférieur aux tarifs du marché, GTIG estime que le service repose sur des clés volées pour être rentable.
Par exemple, Jet Night propose un abonnement illimité à environ 60 $ US par mois, avec un accès supposé à des modèles de pointe, un niveau de service dont le prix se situe généralement entre 100 et 250 $ US par mois. De plus, le service a annoncé plusieurs pannes sur sa chaîne Telegram publique, probablement dues à la révocation des clés volées lorsque les victimes découvrent leurs compromissions.
Figure 3 : Capture d'écran des forfaits Jet Night et de la structure tarifaire
Un acteur malveillant a déployé une infrastructure de relais proxy personnalisée ai-relayhébergée sur des domaines similaires trompeurs. Par exemple, il a enregistré un domaine pour se faire passer pour le serveur interne légitime de la victime. Cette infrastructure de relais personnalisée a permis de détourner discrètement des accès LLM commerciaux de grande valeur vers l' newapi[.]proécosystème de revente illicite, en consommant directement les quotas du compte d'entreprise de la victime au profit de ses clients clandestins.
Perspectives
GTIG prévoit que les acteurs malveillants privilégieront de plus en plus le LLMJacking aux techniques de vol de ressources traditionnelles comme le cryptojacking, attirés par la monétisation immédiate et à forte marge permise par l'émergence de plateformes de mixage LLM clandestines.
À mesure que les entreprises intègrent des modèles plus complexes et des flux de travail automatisés dans leurs environnements de production, les cybercriminels affineront probablement leurs techniques de reconnaissance automatisée afin de cibler les jetons d'API exposés et d'exploiter les vulnérabilités des intergiciels de routage de modèles.
Cette spécialisation opérationnelle alimentera un marché illicite de revente en pleine expansion, permettant aux acteurs malveillants de détourner rapidement les quotas des entreprises tout en répercutant les coûts de facturation sur les victimes avant même que les compromissions ne soient détectées.
Détection et chasse
En cas de défaillance des mesures de sécurité, il est crucial que les équipes de défense soient rapidement informées des abus des plateformes LLM cloud. Elles doivent prioriser la détection des modifications apportées aux comptes et services LLM et considérer toute activation non autorisée comme un incident de sécurité critique. Dans plusieurs incidents analysés par Mandiant, les services LLM n'étaient pas activés au moment de la compromission. L'exploitation abusive des clés d'accès a permis à l'attaquant de modifier et d'activer les services API LLM (par exemple, Bedrock, l'API Gemini, etc.). Une fois activés, ces API permettent à l'attaquant de générer des factures exorbitantes pour l'organisation en quelques minutes ou quelques heures seulement.
Opérations de sécurité Google
Les clients de Google Security Operations ont accès à ces règles de catégorie générale et à bien d'autres encore grâce aux packs de règles Cloud Threats, Mandiant Frontline Threats et Mandiant Hunting Rules. L'activité décrite dans cet article de blog est détectée dans Google SecOps sous les noms de règles suivants :
Création de clés de compte AWS
AWS Créer une nouvelle clé d'accès
Créer un compte utilisateur AWS
Supprimer un compte utilisateur AWS
Exécution de commandes shell encodées en Base64
Créer et supprimer un pare-feu dans le réseau par défaut
Clés SSH du projet GCE
Création de clés de compte de service GCP
GCP Créer un nouveau compte de service
Règle de pare-feu GCP créée
Exfiltration d'archives Linux via Curl ou Wget
Persistance : Scripts ou URL de démarrage des métadonnées d’instance ou de projet de l’ensemble de calcul
Atténuation et remédiation
Pour empêcher les attaquants d'abuser des services Cloud LLM, les défenseurs doivent donner la priorité à la gestion des identités et des accès (IAM) et à la sécurité de la chaîne d'approvisionnement, deux des voies les plus courantes pour accéder aux services Cloud et en abuser.
Hygiène des identifiants : Utilisez une plateforme centralisée de gestion des secrets pour contrôler la gestion et le renouvellement des clés et secrets sensibles. L’automatisation des secrets et des clés permet de limiter la durée de vie des identifiants divulgués.
Principe du moindre privilège : assurez-vous que les utilisateurs et les comptes de service ne possèdent que les autorisations nécessaires à leur rôle et aux tâches qui leur sont confiées. Refusez toutes les autorisations non explicitement requises, y compris l’accès aux services Cloud LLM.
Surveillance du code : Automatisez l’analyse des secrets au sein des bases de code (GitHub, Gitlab, etc.) afin de garantir que les clés API et les secrets ajoutés au code source soient identifiés et supprimés rapidement.
Audits de configuration de routine : Effectuez des audits de configuration complets et périodiques des services Cloud afin d’identifier les vecteurs d’attaque potentiels et les expositions non intentionnelles des points de terminaison.
Limitation du débit : Mettez en œuvre un WAF comme Cloud Armor de Google pour imposer une limitation du débit aux connexions client individuelles.
Liste blanche du réseau : Limiter les connexions sortantes des services cloud via les règles de pare-feu VPC aux adresses IP connues lorsque cela est possible.
Alertes budgétaires : Mettez en place des quotas d’API précis sur les services LLM afin de limiter le volume de requêtes par modèle. Utilisez des plafonds de dépenses pour définir des budgets et éviter les dépassements.
Authentification multifacteurs (MFA) : Appliquez une authentification multifacteurs résistante au phishing sur tous les fournisseurs d’identité cloud, les consoles de gestion et les plateformes de développement afin de garantir que les informations d’identification ou les jetons de session volés ne puissent pas être facilement exploités.
Shadow LLM Discovery : Utilisez des outils de gestion de la posture de sécurité pour analyser automatiquement vos environnements de cloud hybride et identifier les outils, modèles et infrastructures non autorisés ou non surveillés, garantissant ainsi une visibilité complète de votre empreinte de modèles.
Portées granulaires des clés API : restreignez et segmentez les clés API par points de terminaison de modèle spécifiques, environnements (dev/prod) et limites d’utilisation afin de garantir qu’un jeton compromis pour un modèle utilitaire de base ne puisse pas être utilisé pour invoquer des modèles de pointe coûteux et de haut niveau.
Surveillance des balayages de validation : Surveillez les journaux d’accès à la passerelle du modèle et à l’API afin de détecter les requêtes anormales et peu fréquentes (telles que max_tokens=1les pings à température nulle). Les attaquants utilisent souvent ces microtransactions pour effectuer des balayages de validation d’identifiants discrets avant de lancer des attaques à grande échelle contre l’infrastructure.
Correction des vulnérabilités et de la chaîne d'approvisionnement ML : Intégrez l'analyse automatisée des vulnérabilités (SAST/DAST/SCA) dans le code de votre application personnalisée, vos charges de travail conteneurisées et vos dépendances d'apprentissage automatique (comme les bibliothèques PyTorch et Hugging Face) afin d'empêcher l'accès initial via des vulnérabilités serveur non corrigées.
Gestion des correctifs de passerelle : Étendre les programmes de gestion des vulnérabilités pour inclure les passerelles proxy et de routage de modèle centralisé (par exemple, LiteLLM), en assurant une correction rapide des failles d'élévation de privilèges et de contournement d'authentification (telles que CVE-2026-40217).
Exécution en bac à sable pour les charges de travail dynamiques : isolez l’environnement d’exécution dans des bacs à sable hautement virtualisés, isolés au niveau des processus et sans serveur si votre application LLM doit exécuter dynamiquement du code généré ou des requêtes de base de données.
Référentiels de modèles vérifiés : limitez et imposez les extractions de modèles et les dépendances de pipeline uniquement à partir de registres internes de confiance ou de catalogues d’entreprise approuvés afin d’empêcher les développeurs d’extraire des modèles compromis contenant des portes dérobées préconfigurées.
Modélisation de l'exposition basée sur les graphes : Mettre en œuvre une priorisation continue des risques basée sur les graphes qui cartographie les ressources cloud, le code applicatif et les flux de données afin d'identifier et de corriger automatiquement les chemins d'attaque complexes à sauts multiples.
Validation de l'exposition aux menaces : Déployer des agents offensifs automatisés pour tester en continu les surfaces d'attaque externes, découvrir les points de terminaison exposés et simuler des analyses de validation d'identifiants.
Surveillance des journaux d'audit du cloud natif
AWS : Surveillez les journaux CloudTrail pour détecter les événements d’API provenant de [source manquante bedrock.amazonaws.com]. D’après les incidents historiques de LLM Jacking, surveillez les opérations d’API suivantes tout au long du cycle de vie de l’attaque :
Exploitation des ressources : Surveiller l'exécution directe du LLM via les Converseopérations API InvokeModel,.InvokeModelWithResponseStream
Limitation du débit des API et pics d'erreurs : surveillez les pics de volume élevés d'API ThrottlingException, d'erreurs ValidationExceptionou ResourceNotFoundExceptiond'autres erreurs, qui pourraient indiquer une méthode de « pulvérisation » automatisée ciblant l'infrastructure cloud.
Ciblage des cibles : Surveillez les activités de reconnaissance potentielles utilisées pour découvrir les modèles disponibles via les opérations ListFoundationModels,ListInferenceProfileset GetFoundationModelAvailability. Surveillez également les tentatives de déverrouillage de nouveaux modèles dans l’environnement via les opérations PutUseCaseForModelAccesset CreateFoundationModelAgreementAPI.
Sécurité/Évasion : Examiner les tentatives de consultation, de modification ou de désactivation des configurations de journalisation afin de dissimuler le contenu des invites et d’éviter d’être détectées. Surveiller le GetModelInvocationLoggingConfigurationfonctionnement, ainsi que PutModelInvocationLoggingConfigurationles DeleteModelInvocationLoggingConfigurationappels de désactivation de la journalisation provenant de personnes autres que des acteurs IaC (Infrastructure as Code).
Outils automatisés : analyser les chaînes User-Agent pour identifier les outils automatisés et les SDK (par exemple, claude-cli, aws-sdk-rust et aws-sdk-go-v2) interagissant directement avec l’infrastructure cloud cible.
Azure : Surveillez les journaux d’activité (plan de contrôle) et les journaux de diagnostic (plan de données) d’Azure pour détecter les événements associés à l’ Microsoft.CognitiveServicesespace de noms. Pour rechercher ou détecter les incidents de détournement de LLM, surveillez les opérations suivantes :
Exploitation des ressources : Surveillez l’exécution directe du modèle LLM. Dans Azure, les invocations de modèles ont lieu au niveau du plan de données et nécessitent l’activation des journaux de diagnostic. Recherchez un volume élevé de requêtes POST vers les points de terminaison d’inférence, tels que les API Completions ou Chat Completions. Au niveau du plan de gestion (journaux d’activité), surveillez la création non autorisée de nouvelles instances via cette Microsoft.CognitiveServices/accounts/deployments/writeopération.
Définition du périmètre cible : Surveiller les activités de reconnaissance potentielles pour découvrir les ressources, les modèles et les déploiements Azure LLM disponibles via les Microsoft.CognitiveServices/accounts/readopérations Microsoft.CognitiveServices/accounts/deployments/read.
Sécurité/Évasion : Examiner les tentatives de consultation ou de modification des configurations de journalisation (pour vérifier si les invocations du modèle de plan de données sont enregistrées) via les opérations Microsoft.Insights/diagnosticSettings/read, Microsoft.Insights/diagnosticSettings/write, ou .Microsoft.Insights/diagnosticSettings/delete
GCP : Surveillez les journaux d'audit du cloud pour les appels aux points de terminaison de la plateforme Gemini Enterprise Agent (aiplatform.googleapis.com). Les opérations d'inférence de la plateforme Gemini Enterprise Agent sont consignées dans les journaux d'accès aux données, désactivés par défaut en raison de leur volume et des coûts d'ingestion. Vous devez configurer manuellement vos stratégies d'audit IAM pour les suivre.
Activation des services de la plateforme d'agents : Alerte concernant l'activation des services de la plateforme d'agents Gemini Enterprise via la google.api.serviceusage.v1.ServiceUsage.EnableServiceméthode.
Exploitation des ressources : Surveillez l’exécution directe du LLM via la plateforme Gemini Enterprise Agent, ce qui nécessite l’activation de la journalisation d’audit des accès aux données. Recherchez les opérations suivantes : google.cloud.aiplatform.v1.PredictionService.Predict[ insérer google.cloud.aiplatform.v1.PredictionService.GenerateContentles google.cloud.aiplatform.v1.PredictionService.StreamGenerateContentopérations ici].
Définition de la cible : Surveiller les activités de reconnaissance potentielles pour découvrir les modèles et les points de terminaison disponibles via les opérations API google.cloud.aiplatform.v1.ModelService.ListModels, google.cloud.aiplatform.v1.EndpointService.ListEndpoints, et .google.cloud.aiplatform.v1.PublisherModelService.ListPublisherModels
Sécurité/Évasion : Examiner les tentatives de consultation ou de modification des configurations de journalisation et d’audit. Surveiller les opérations telles que google.iam.v1.IAMPolicy.GetIamPolicy(pour vérifier si les journaux d’accès aux données sont activés sur le projet/la ressource) ou les tentatives de consultation des exportations de journaux via google.logging.v2.ConfigServiceV2.ListSinkset google.logging.v2.ConfigServiceV2.GetSink.
Source : cloud.google.com