LLMjacking : quand des attaquants font tourner des LLM sur votre facture AWS

Un compte sandbox qui coûte normalement 120 $ par jour génère 85 000 $ de facturation en quatorze heures. Un compte membre dormant, inactif depuis onze mois, accumule 75 000 $ avant que quiconque n'ouvre la facture. Le compte d'un distributeur européen passe de quelques centaines de dollars par mois à 522 000 $ en moins de deux jours.

Aucun de ces attaquants n'a volé de données ni déployé de ransomware. Ils ont dérobé des identifiants cloud et les ont utilisés pour appeler les grands modèles de langage les plus coûteux d'Amazon Bedrock, puis ont laissé la facture à la victime. C'est le LLMjacking. En 2026, il est devenu l'un des incidents de sécurité les plus fréquents, et les plus coûteux, traités par l'équipe support de DoiT.

Cet article explique le fonctionnement de l'attaque et ce que nous avons observé dans les incidents de cette année. Il détaille ensuite les contrôles AWS qui permettent de la prévenir. Enfin, il montre comment configurer DoiT Cloud Intelligence™ (DCI) pour être prévenu par une alerte plutôt que par votre facture.

Partie 1 : les contrôles AWS qui préviennent le LLMjacking

Supprimez les identifiants qui valent la peine d'être volés

• Cessez d'émettre des clés utilisateur IAM de longue durée. Utilisez IAM Identity Center pour les personnes. Donnez aux workloads des rôles IAM avec identifiants temporaires : OIDC pour GitHub Actions, IRSA ou EKS Pod Identity, et des profils d'instance. Les bonnes pratiques IAM d'AWS sont explicites à ce sujet.
• Auditez les clés que vous avez déjà. Supprimez les clés inutilisées depuis 90 jours ; ne vous contentez pas de les désactiver. AWS exigera de toute façon leur suppression après un incident. Ne placez jamais de clés partagées dans des variables CI, des values Helm ou des fichiers d'identifiants d'agents/MCP.
• Traitez les clés API Bedrock comme des secrets. Privilégiez les clés de courte durée, valables jusqu'à 12 heures, et inventoriez et restreignez toutes les clés de longue durée (AWS).
• Activez le scan de secrets et la protection push dans votre gestion de code source (GitHub). Si AWS attache la politique AWSCompromisedKeyQuarantineV3 à l'un de vos utilisateurs, lancez la réponse à incident. La politique limite ce que la clé peut faire, mais elle n'élimine pas l'attaquant (AWS).

Protégez le compte root

Utilisez un MFA matériel, aucune clé d'accès root et une adresse e-mail root sur un domaine que vous contrôlez et surveillez activement. Configurez les contacts alternatifs SECURITY et OPERATIONS sur chaque compte, y compris les comptes dormants, pour que les avertissements d'AWS atteignent quelqu'un qui les lit.

Placez des garde-fous au niveau de l'Organization

Le principe du moindre privilège IAM doit limiter chaque workload aux modèles et régions spécifiques dont il a besoin (exemples de politiques AWS). Les service control policies ajoutent ensuite un filet de sécurité qu'un principal compromis ne peut pas retirer. Voici un point de départ, à tester d'abord dans une OU hors production :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyMarketplaceSubscribeExceptPlatformRole",
      "Effect": "Deny",
      "Action": "aws-marketplace:Subscribe",
      "Resource": "*",
      "Condition": {
        "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/ai-platform-admin" }
      }
    },
    {
      "Sid": "DenyBedrockOutsideApprovedRegions",
      "Effect": "Deny",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": { "aws:RequestedRegion": ["us-east-1", "us-west-2"] }
      }
    },
    {
      "Sid": "DenyFederationTokenConsoleBypass",
      "Effect": "Deny",
      "Action": "sts:GetFederationToken",
      "Resource": "*"
    }
  ]
}

Quelques précautions. Les profils d'inférence inter-régions routent les requêtes vers d'autres régions : validez donc la condition de région par rapport aux profils que vous utilisez réellement (AWS). Certains comptes ne devraient jamais utiliser d'IA générative : sandboxes, comptes dormants et la plupart des comptes de production hors de votre plateforme IA. Pour ceux-là, un deny pur et simple sur bedrock:* est plus facile à gérer et plus sûr.

Limitez la vitesse à laquelle l'argent peut sortir

• Abaissez les quotas de tokens par minute de Bedrock au besoin réel de chaque workload, et exigez une approbation pour toute augmentation (AWS). Un quota plafonne le débit, pas le total, mais il vous fait gagner du temps.
• Cantonnez l'expérimentation à des comptes cloisonnés dotés de leurs propres budgets.

Journalisez et détectez

• Un trail CloudTrail d'organisation multi-régions livré dans un compte d'archivage de logs verrouillé.
• La journalisation des invocations de modèles Bedrock pour les workloads approuvés (AWS).
• Amazon GuardDuty dans chaque compte et chaque région, avec les protections liées à l'IA activées. Après un incident, AWS a vérifié la présence de services de sécurité dans le compte membre affecté, pas seulement dans le compte de gestion.
• Des alertes sur les signaux apparus tôt dans des incidents réels :
  • nouveaux contrats Marketplace
  • appels GetFederationToken
  • CreateAccessKey appelé par un rôle assumé
  • connexions root ou changements de MFA
  • hausses soudaines du volume d'envoi SES

Partie 2 : configurer DoiT Cloud Intelligence comme système d'alerte précoce

DCI ne remplacera ni GuardDuty ni CloudTrail. Sa valeur ici tient au fait qu'il s'agit d'un plan de contrôle des coûts extérieur à vos comptes AWS. Un attaquant détenant vos clés AWS peut lire et modifier AWS Budgets, et nous en avons vu un le faire. Il ne peut pas toucher aux alertes et budgets que vous avez configurés dans DCI.

Les alertes, les budgets et la détection d'anomalies surveillent la dépense. Composer et Security Insights ferment les brèches qu'exploitent les attaquants. CloudFlow transforme chacun d'eux en notification, en ticket ou en action de confinement approuvée.

1. Des alertes à seuil qui n'ont pas besoin de référence

Les alertes se déclenchent sur une règle fixe : elles fonctionnent dès le premier jour, même sur un modèle que vous n'avez jamais utilisé. C'est le contrôle DCI le plus fiable contre le LLMjacking.

• Créez une allocation regroupant toutes les dépenses de modèles d'IA : Amazon Bedrock et les produits Marketplace "(Amazon Bedrock Edition)". Les nouveaux modèles y sont alors intégrés automatiquement, et vos alertes ne ratent pas silencieusement le lancement de modèle du mois prochain.
• Alerte de dépense quotidienne par compte : limitez-la à cette allocation, avec Metric sur Cost et Interval sur Daily. Définissez la condition sur is > $X, où X vaut deux à trois fois une journée normale. Activez Evaluate for each: Account pour qu'une seule règle couvre tous les comptes.
• Alerte "doit rester à zéro" : pour les sandboxes, les comptes dormants et tout ce qui n'exécute pas de workloads d'IA, alertez à > $10 par jour.
• Variation d'un jour à l'autre : percentage change is > 100%.
• Alerte de prévision : mensuelle, is forecasted to be > votre dépense IA prévue.

Acheminez les alertes par e-mail et vers un canal Slack que quelqu'un surveille vraiment (envoi des alertes vers Slack).

2. Des budgets sur chaque compte, surtout les plus discrets

Placez un budget mensuel récurrent sur chaque compte AWS, avec des seuils à 50 %, 85 % et 100 %. Les suggestions de budget peuvent les dimensionner pour vous. Ajoutez un budget quotidien sur l'allocation IA comme second signal d'alerte, facile à lire. Les comptes dormants et sandbox sont les cibles préférées des attaquants, précisément parce que personne ne leur affecte de budget. Un compte à 0 $ avec un budget de 50 $ est une excellente alarme.

Les budgets n'arrêteront pas la dépense, mais ils vous en informeront depuis l'extérieur du compte compromis.

3. Réglez la détection d'anomalies pour qu'elle vous parvienne vraiment

La détection d'anomalies de coûts garde toute sa place, surtout pour le volet EC2, GPU et SageMaker d'une attaque. Trois réglages comptent :

• Élargissez le filtre de sévérité. Les notifications par e-mail sont limitées par défaut au niveau Critical. Réglez-les sur "Warning and above" ou "All severity levels" (paramètres de notification).
• Activez la renotification, pour qu'une anomalie active qui continue de croître vous relance.
• Vérifiez qu'un destinataire est configuré. Dans plus d'un incident, DCI a détecté l'anomalie mais personne n'en a entendu parler. Aucune cible de notification n'était définie.

Sur les plans Enhanced et Enterprise, activez la détection d'anomalies en temps réel pour AWS. Elle s'appuie sur CloudTrail et remonte l'information en une heure environ. Elle couvre aujourd'hui EC2 et RDS plutôt que Bedrock. Cela détecte tout de même le volet GPU et instances de l'attaque, qui accompagne souvent l'abus de modèles. Vous pouvez aussi activer la détection d'anomalies sur l'allocation IA elle-même (supervision des allocations).

Si vous instrumentez vos workloads d'IA avec Attribute, DoiT propose aussi, en accès anticipé, des anomalies d'usage au niveau des tokens. Elles peuvent signaler un workload hors de contrôle plus vite que les données de facturation. Elles ne voient que le trafic de vos propres hôtes instrumentés : elles ne détecteront donc pas une clé volée utilisée depuis la machine d'un attaquant.

4. Automatisez la première réponse avec CloudFlow

CloudFlow peut se déclencher sur les alertes DCI, les seuils de budget et les anomalies de coûts, ce qui transforme une notification en action :

• Alerte → Slack → approbation → confinement. Quand l'alerte Bedrock se déclenche, publiez le compte et le montant dans votre canal d'incident. Puis, après approbation humaine, exécutez une action AWS : désactivez la clé d'accès suspectée, ou attachez un deny explicite sur bedrock:InvokeModel* et bedrock:Converse*. Les étapes d'approbation évitent qu'un faux positif ne mette la production hors service.
• Détection de première utilisation d'un service. Un modèle de flow planifié signale la première dépense sur tout service ou SKU AWS. Cela comble la lacune des nouveaux modèles décrite plus haut.
• Révocation des clés API des fournisseurs d'IA. Un modèle déclenché par webhook, avec approbation intégrée, supprime les identifiants Bedrock de longue durée (ainsi que les clés OpenAI, Anthropic ou Gemini). Vous pouvez l'appeler depuis EventBridge, votre SIEM ou un finding GuardDuty (tutoriel).

Toute action de confinement exige que le rôle CloudFlow du compte cible dispose des permissions IAM correspondantes. Décidez de ces permissions avant un incident.

5. Fermez les brèches avant qu'un attaquant ne les trouve

Security Insights intègre les findings d'AWS Security Hub et de Trusted Advisor : clés d'accès jamais renouvelées, comptes root sans MFA, comptes sans GuardDuty ni CloudTrail. Presque tous les incidents décrits ci-dessus ont commencé par l'un de ces problèmes.

Ces findings reposent sur les règles génériques d'AWS. Composer vous permet d'écrire les vôtres, sur les plans Enhanced et Enterprise. C'est le moteur de politiques de DCI. Il analyse les ressources de chaque compte connecté et les confronte à des recettes, c'est-à-dire des règles que vous construisez sans code. Vous pouvez dupliquer une recette DoiT et la modifier, ou décrire le contrôle à l'assistant IA. Les correspondances apparaissent comme des Security insights.

Voici comment les brèches à l'origine des incidents de cette année se traduisent en recettes que vous pouvez créer dès aujourd'hui :

La dernière ligne est ce qui rapproche le plus Composer de la détection d'abus. Une clé d'un compte sandbox dont la dernière utilisation concerne Bedrock mérite un examen, même si la dépense n'a pas encore bougé.

Pour agir sur les findings, planifiez un CloudFlow qui lit les Security findings ouverts via le nœud Composer Insights. Publiez-les sur Slack ou ouvrez un ticket chaque matin. Pour les clés obsolètes, ajoutez une étape d'approbation qui désactive la clé une fois que son propriétaire confirme qu'elle est inutilisée.

Composer effectue des analyses périodiques : c'est donc un contrôle d'hygiène plutôt qu'une alarme d'attaque. Il ne vérifie ni le statut de GuardDuty ou Security Hub, ni la journalisation des invocations Bedrock, ni les clés API Bedrock, ni le contenu des SCP. Security Insights et AWS Config couvrent ces aspects. Utilisez Composer pour fermer les portes par lesquelles les attaquants sont passés cette année, et conservez les alertes à seuil ci-dessus pour la dépense elle-même.

Si cela arrive malgré tout

Lancez le confinement dès que vous soupçonnez une compromission. N'attendez ni une alerte d'anomalie ni les chiffres de facturation définitifs.

1. Confinez d'abord. Désactivez, puis supprimez, les clés d'accès compromises. Révoquez les sessions de rôle actives avec une politique de deny conditionnée sur aws:TokenIssueTime, et désactivez toute clé API Bedrock suspecte. S'il vous faut un outil radical, une SCP d'urgence refusant bedrock:* sur le compte affecté stoppe l'hémorragie (elle bloque aussi l'usage légitime de Bedrock). Attendez-vous à ce que des appels continuent d'aboutir quelques minutes après la désactivation d'une clé.
2. Traquez la persistance. Cherchez de nouveaux utilisateurs IAM, clés d'accès, rôles et changements de politiques de confiance, contrats Marketplace, identités SES, Capacity Blocks et instances dans chaque région. Renouvelez chaque clé potentiellement exposée, pas seulement celle qu'AWS a signalée. Nous avons vu une deuxième vague arriver six jours après l'ouverture d'un incident, via une clé que personne n'avait renouvelée.
3. Préservez les preuves. Exportez CloudTrail (l'Event History ne conserve que 90 jours), les logs d'invocation, un inventaire des ressources et un export des coûts par service.
4. Répondez à AWS avant l'échéance. Les notifications de sécurité AWS laissent généralement cinq jours avant la suspension des services. Les restrictions peuvent tomber plusieurs jours après l'incident et affecter des services de production comme Lambda, ECS et EC2.
5. Demandez explicitement l'ajustement de facturation. Dans les cas que nous avons vus, AWS attend au moins deux contrôles de surveillance des coûts, comme AWS Budgets et Cost Anomaly Detection. La présence du MFA root, de GuardDuty ou de Security Hub est également attendue. Ces points sont vérifiés dans le compte affecté. Les contrats Marketplace créés par l'attaquant doivent être résiliés. Les issues ont varié : crédits complets, crédits partiels ou refus. Le processus a pris de deux à douze semaines. Une chronologie claire, un confinement rapide et des preuves complètes font la différence. AWS a aussi indiqué qu'il pourrait ne pas examiner les factures futures si les contrôles ne sont pas en place.

Si DoiT est le revendeur de votre compte AWS, ouvrez un ticket de support DoiT dès que vous soupçonnez une compromission. Notre équipe assure la coordination avec AWS sur le dossier de sécurité et la demande d'ajustement de facturation, et vous aide à rassembler les preuves demandées par AWS.

Votre checklist LLMjacking

Dans AWS

• Aucune clé utilisateur IAM de longue durée pour les personnes ou les workloads. Anciennes clés auditées et supprimées.
• Root : MFA matériel, aucune clé d'accès et une adresse e-mail surveillée sur un domaine que vous possédez.
• Contacts alternatifs SECURITY et OPERATIONS configurés sur chaque compte.
• Des SCP qui refusent Bedrock là où il n'est pas nécessaire, restreignent les abonnements Marketplace et bloquent GetFederationToken.
• Quotas de tokens par minute Bedrock dimensionnés au besoin réel.
• CloudTrail d'organisation, journalisation des invocations Bedrock et GuardDuty dans chaque compte et chaque région.

Dans DoiT Cloud Intelligence

• Une allocation couvrant Bedrock et les dépenses Marketplace "(Amazon Bedrock Edition)".
• Des alertes à seuil quotidiennes par compte sur cette allocation, y compris les comptes "doit rester à zéro".
• Un budget sur chaque compte AWS, comptes dormants compris.
• Notifications d'anomalies réglées sur Warning ou supérieur, avec renotification et un vrai destinataire.
• Détection d'anomalies en temps réel sur AWS (plans Enhanced et Enterprise).
• Recettes Composer pour les clés obsolètes et admin, la posture root, les contacts de sécurité, la couverture des trails et l'usage de clés Bedrock hors de vos comptes IA.
• CloudFlow : confinement avec approbation et détection de première utilisation d'un service.

Les attaquants gagnent de l'argent avec le LLMjacking : ils continueront donc de chercher les comptes que personne ne surveille. Une détection parfaite n'est pas réaliste. Vous pouvez néanmoins faire de votre compte une cible coûteuse, bruyante et éphémère. Et si quelque chose passe malgré tout, vous pouvez l'apprendre en quelques heures plutôt que sur la facture.

Besoin d'aide pour passer en revue vos garde-fous AWS ou configurer les alertes, budgets et CloudFlow de DCI pour vos workloads d'IA ? Parlez à DoiT.