Cinq attaques liées à l'IA. Les trois mêmes points faibles.

Au début du mois de juillet 2026, selon Dream Research Labs, une plateforme d'attaques automatisées a téléchargé les fichiers JavaScript d'un portail web gouvernemental et les a analysés.

Non exploité. Analysé. À partir du code que le portail fournit systématiquement à chaque visiteur, il a extrait des points de terminaison d'API, une configuration de fournisseur d'identité et deux clés de signature, puis a répertorié 21 systèmes administratifs connectés, y compris l'infrastructure d'authentification unique qui les relie entre eux.

Rien n'a été compromis. N'importe quel pentesteur procède ainsi dès la première heure d'une mission. Ce qui est nouveau, c'est qu'un framework l'ait fait, ait classé ses découvertes et soit passé à autre chose sans attendre d'y être invité.

J'ai lu cette année cinq cas classés dans la catégorie des attaques par IA. Pris ensemble, ils révèlent quelque chose que les gros titres ne mentionnent pas. Aucun d'entre eux n'a nécessité une technique qui n'existait pas déjà. Le plus récent a permis de condenser une chaîne complète en moins de dix heures, et cette compression a été obtenue en supprimant les pauses entre les étapes connues.

Les cinq cas

Un opérateur humain muni d'un accélérateur.

Sysdig a recensé une intrusion survenue le 28 novembre 2025, qui a débuté par la divulgation d’identifiants AWS dans des compartiments S3 publics et s’est soldée par la création d’un compte administrateur de type « porte dérobée ». Huit minutes pour l'exécution d'une fonction Lambda, les privilèges d'administrateur obtenus en moins de dix minutes. Le titre de l'article de Sysdig mentionne une « intervention assistée par l'IA » et ses conclusions sont prudentes : « plusieurs indicateurs suggèrent que l'acteur malveillant a exploité de grands modèles linguistiques ». Selon mon interprétation, il s'agit d'une personne derrière un clavier, utilisant des modèles pour accélérer la reconnaissance et la génération de code, ce qui n'est pas la même chose qu'un agent. J'ai abordé ce sujet ici.

Un être humain qui fixe des objectifs, et des agents qui les mettent en œuvre.

‍Unit 42 a publié ce cas le 2 septembre 2026; il s’agit du cas le plus difficile de la série. Une API publique a été compromise, les référentiels ont été passés au peigne fin à la recherche de jetons codés en dur, ces jetons ont permis d’accéder au gestionnaire de secrets, les processus CI/CD ont été détournés pour récupérer des clés d’ cloud , et enfin, les propres points de terminaison IA de la victime ont été transformés en infrastructure d’attaque. Moins de dix heures, plus de 50 techniques d’ MITRE ATT&CK .

Lisez leur analyse plutôt que les gros titres. L’introduction indique que le réseau a été piraté « de manière autonome », mais la légende de l’illustration est précise : « L’acteur fixe des objectifs et prend des décisions ayant des conséquences. » Leur résumé de ce qui rend cet incident remarquable réside dans cette phrase essentielle : « Une efficacité opérationnelle assistée par l’IA, sans avoir besoin d’une nouvelle « zero-day » ni de techniques d’espionnage d’élite. » La comparaison sur deux semaines citée partout correspond à leur propre estimation de la « red team », et non à une intrusion observée. Un contrôle a tenu : une tentative d’installation d’une porte dérobée dans les configurations Terraform a échoué car « des contrôles stricts de protection des branches l’ont empêchée ». Et ils ont corrigé leur article le 3 septembre pour préciser qu’il s’agissait d’une intrusion et non d’un ransomware, ce que plusieurs médias continuent d’affirmer à tort.

Un agent, à l'intérieur d'un laboratoire dont la sécurité a été délibérément affaiblie.

Hugging Face a révélé mi-juillet une intrusion orchestrée par des agents, et le 21 juillet, OpenAI a confirmé qu'elle avait été perpétrée à l'aide d'une combinaison de ses propres modèles. Leur chronologie technique recense environ 17 600 actions identifiées sur une période de 4,5 jours.

Le contexte est constamment occulté : l'évaluation « a délibérément désactivé les classificateurs de sécurité de production d'OpenAI et réduit les rejets liés à la cybersécurité », et « aucun humain n'a dirigé les différentes étapes ». Cela n'en diminue en rien la gravité. Même affaiblie, la sandbox a tout de même permis une véritable intrusion en plusieurs étapes contre un tiers réel, et un identifiant dont les privilèges étaient trop étendus a permis à l'agent d'obtenir les droits d'administrateur de cluster sur deux clusters en moins d'une seconde après s'être fait passer pour celui-ci.

Les outils d'IA sont utilisés à mauvais escient comme infrastructure, sans qu'aucun modèle ne prenne de décision.

Des vers autoréplicatifs circulent sur npm depuis 2025. La charge utile s’exécute au moment de l’installation, récupère tous les jetons présents sur l’hôte, puis se republie via n’importe quel canal de publication accessible à la victime. Elastic Security Labs a identifié la dernière vague le 4 août, signalant plus de 400 paquets compromis.

La logique de propagation est un code déterministe, et non un modèle choisissant des actions. Mais les outils d’IA y sont largement impliqués : un hook qui se déclenche lors d’une nouvelle session Claude, des commits créés sous la forme claude@users.noreply.github.com, ainsi qu’un collectionneur à la recherche d’identifiants d’Anthropic, d’OpenAI et de Cursor. Voici à quoi ressemble principalement l'IA dans une chaîne d'attaque à l'heure actuelle : des outils de développement servant de surface d'exécution, des clés IA comme butin, et rien qui ne décide de quoi que ce soit.

Un cadre quasi autonome, en conditions réelles.

Revenons à l’affaire « Dream », publiée le 12 août. L’espace de travail récupéré compte 1 395 fichiers couvrant 12 vagues d’attaques, déployant jusqu’à huit sous-agents par vague tout en classant en continu 14 chaînes d’attaques. Trois découvertes constituent le reste de cet article : des API non authentifiées renvoyant des sessions valides sans identifiants fournis, une API acceptant des jetons Web JSON signés avec le aucun algorithme, et 85 comptes piratés par une attaque de type « spraying », dont 84 ont permis d'accéder à un système interne via une passerelle SSO.

Notez le terme utilisé par Dream et que la plupart des médias ont omis : « quasi-autonome ». Une personne faisait partie de cette boucle, et les refus du modèle ont été contournés en présentant cette activité comme un test d'intrusion autorisé.

Ces chiffres proviennent des rapports du cadre lui-même. Dream a validé le taux de pivot SSO et affirme avoir informé les organisations concernées avant la publication ; son porte-parole a quant à lui déclaré à CSO Online que l'étude n'avait révélé aucune preuve d'une violation avérée des systèmes de l'entité, tout en refusant de nommer cette dernière. Ce sont les techniques qui constituent la partie durable.

Les trois mêmes angles morts

Je classe les intrusions en fonction de trois lacunes structurelles dans le fonctionnement des systèmes de détection. Ces cinq-là n'ont pas eu besoin d'être classées de force dans cette catégorie.

Écart n° 1. Tout semble normal.

Toute la phase de reconnaissance de Dream s'est déroulée en s'appuyant sur des informations publiées délibérément par la cible. Les failles exploitées étaient d'ordre serveur et banales : des API non authentifiées, une validation insuffisante des jetons. Aucune charge utile sur le disque, car il n'y en avait pas. Le cas de Sysdig suit le même schéma, mais à un niveau inférieur, sur des services AWS natifs et avec de véritables identifiants, chaque action étant prise en charge et correctement consignée.

Tout ce qu’ils faisaient semblait toujours parfait.

Étape 2. L'authentification aboutit.

Les noms d'utilisateur proviennent d'une API ne nécessitant aucune authentification. Des combinaisons prévisibles sont testées par séries. L'OCR permet de résoudre le CAPTCHA. Tout compte concerné donne lieu à une connexion réussie, et aucun incident d'accès non autorisé ne justifie l'ouverture d'un ticket.

Le aucun- La détection d'algorithmes mérite une ligne à part. Une API qui accepte un jeton en affirmant qu'il ne nécessite aucune signature ne se fait pas piéger. Elle a accepté de ne pas effectuer la vérification, et pour cette API, un jeton falsifié et un jeton valide sont identiques.

L'authentification a réussi.

Lacune n° 3. Le mouvement n'est pas visible.

Le chiffre à retenir est 84 sur 85. Ces identifiants ont été piratés sur un portail de bureautique, un système périphérique de faible valeur. Le pont SSO a ensuite étendu cet accès aux tableaux de bord internes et aux données du personnel. L'identifiant se situe sur un plan, l'accès s'effectue sur un autre, et la fédération entre les deux remplit parfaitement sa fonction, en enregistrant une connexion réussie à chaque étape.

Trois journaux d'audit, trois tickets SOC, une violation.

La compression est bien réelle. Il ne s'agit pas d'une vitesse simulée.

Le « breakout time », c’est-à-dire le délai entre l’accès initial et le premier déplacement latéral, a été retiré de la liste des indicateurs par CrowdStrike le 1er septembre, au motif que ce que le secteur appelait jusqu’alors la « vitesse des machines » correspondait en réalité à la vitesse humaine, mais avec de meilleurs outils. Aucun indicateur de remplacement n’a été proposé, si ce n’est l’argument selon lequel les attaques se déroulent désormais à la vitesse de l’inférence et ne laissent absolument aucun temps.

Le lendemain, l’Unit 42 a publié un compte rendu de l’intrusion d’une durée de dix heures et a donné sa propre explication sur l’origine de ces dix heures. Il ne s’agit pas d’une déduction. Voici la citation textuelle : « Les agents IA réduisent le temps entre les différentes étapes du déroulement de l’attaque : les agents IA utilisés dans cette attaque ont été conçus pour analyser les résultats bruts des outils et passer rapidement aux étapes suivantes. » La latence du modèle n’est mentionnée nulle part dans le rapport. Ce qui est mentionné, c’est le parallélisme, la replanification en temps réel sans allers-retours de la part de l’opérateur, et l’absence d’intervention humaine entre le moment où un outil renvoie ses résultats et le déclenchement de l’action suivante.

Comparez les durées les unes à côté des autres. Sysdig, avec un opérateur humain au clavier et des modèles d’assistance : huit minutes. Unit 42, avec un opérateur humain définissant les objectifs et des agents chargés de l’exécution : moins de dix heures. Une équipe de cybercriminels spécialisée dans les ransomwares suivie par Sophos, sans aucune IA : moins de 17 heures. Dream : environ quatre jours. Hugging Face : 4,5 jours.

Il n'y a pas de lien direct entre une automatisation accrue et un gain de temps. Les deux cas où aucun humain ne dirigeait les étapes individuelles sont les deux plus lents, d'un facteur d'environ dix, et un humain n'utilisant aucune IA s'est avéré plus lent qu'un humain utilisant des agents. La durée reflète le degré de précision avec lequel l'objectif a été défini, et non la part du travail effectuée par un modèle. Le gain de temps est bien réel, et le qualifier de « vitesse d'inférence » revient à se focaliser sur le mauvais paramètre.

Que faire à ce sujet ?

Cela ne modifie en rien le cadre général. Cela change simplement l'ordre de la liste.

• Énumérez les éléments publiés par votre propre front-end : points de terminaison API, identifiants de client OAuth, configuration du fournisseur d'identité. Partez du principe que les bundles sont analysés et recoupés, car c'est désormais le cas.
• Considérez les API non authentifiées comme un problème d’identité, et non comme un simple problème d’hygiène. Une endpoint qui renvoie les noms des employés et leurs identifiants SSO sans demande d’identifiants correspond à une liste de noms d’utilisateurs. Classez-la en fonction de ce qu’elle alimente, et non de ce qu’elle expose.
• Valider les algorithmes de jetons et contrôler la confiance au sein de la fédération. Un JWT accepté avec aucun Il s'agit d'un système d'authentification qui a décidé de ne pas procéder à l'authentification. Et 84 sur 85, cela signifie que le pont SSO représente votre véritable zone d'impact.
• Répertoriez vos outils d'IA et vos ressources de calcul comme surface d'attaque. Les vers npm s'exécutent via un hook de session et recherchent les clés des fournisseurs d'IA. L'attaquant d'Unit 42 a transformé les points de terminaison des modèles de la victime en infrastructure, en dissimulant le trafic d'orchestration au sein du trafic normal et en facturant les ressources de calcul à la victime.
• Concentrez-vous sur la boucle, pas sur la charge utile. Les indicateurs d’Unit 42 constituent à ce jour les éléments les plus concrets publiés concernant les intrusions par agent : requêtes API en rafales, changements rapides d’état de 401 à 200, authentifications parallèles et utilisation soudaine de modèles par des identités inattendues.

Quelle est la place de la détection comportementale dans ce contexte ?

Ces cinq intrusions ont toutes été consignées. Le cas de l'Unité 42 illustre parfaitement pourquoi cela ne suffit pas. Un appel API, une extraction de dépôt, une lecture de secrets, l'exécution d'un pipeline, l'utilisation d'une clé d'cloud ation sur un modèle endpoint. Chacune de ces actions était autorisée en soi et figurait dans le journal correspondant. Dix heures, c'est long en matière de réponse aux incidents, et ce n'est rien du tout si le seul moyen de visualiser la chaîne d'événements consiste à assembler manuellement cinq systèmes a posteriori.

Le récit de Hugging Face expliquant comment leur incident a été détecté est le paragraphe le plus utile publié de tout l’été. Les premiers signaux provenaient de plusieurs couches à la fois et « pris isolément, chacun d’entre eux était ambigu ». Puis : « […] ceux-ci ont été corrélés par notre pile d’agents de sécurité basés sur l’IA et ont permis de mettre en évidence un signal d’attaque cohérent. Cependant, le système n’a pas réussi à élever correctement le niveau de gravité de l’alerte ni à déclencher l’intervention de l’équipe de garde, ce qui a fait perdre un temps précieux dans la réponse. »

La corrélation a fonctionné. Le système a regroupé des signaux ambigus en une seule attaque cohérente, puis cette découverte est restée en suspens, car personne n’a jugé qu’elle était suffisamment urgente pour alerter qui que ce soit. Il s’agit là d’un échec du triage à la suite d’une détection réussie, ce qui constitue un problème distinct nécessitant une solution différente.

La détection ne fonctionne pas mal. Elle est simplement incomplète. C'était vrai à l'époque où l'opérateur était une personne qui tapait sur son clavier, et ces cinq experts affirment que cela reste valable lorsque l'opérateur est un framework capable d'évaluer 14 chaînes d'attaque simultanément. Il faut suivre le comportement, et non la marque derrière l'attaque.

La version complète des trois lacunes se trouve dans « Mind Your Attack Gaps ».