Google GTIG stoppe le premier zero-day 2FA bâti par IA

Ce qui s'est passé

Google a publié cette semaine, via son Threat Intelligence Group (GTIG), un rapport qui marque un tournant dans l'usage offensif de l'intelligence artificielle. Pour la première fois, l'éditeur affirme avoir documenté avec un haut niveau de confiance un zero-day développé avec l'assistance d'un grand modèle de langage et préparé pour un déploiement en mass exploitation. La faille, un contournement d'authentification à deux facteurs visant un outil d'administration web open source largement utilisé, a été interceptée et corrigée avant que la campagne ne soit lancée. Le rapport coïncide avec la sortie d'une note publique du Google Cloud Threat Intelligence intitulée « Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access ».

Le scénario reconstitué par GTIG décrit un mode opératoire en plusieurs étapes. L'attaquant, classé comme acteur criminel motivé financièrement et non comme acteur étatique, aurait soumis le code source du logiciel cible à un LLM accessible publiquement — Google a explicitement écarté Gemini et Mythos, le bug catcher avancé d'Anthropic — afin d'identifier des chemins logiques susceptibles de contourner la double authentification. La sortie du modèle est ensuite passée par une phase de validation et de mise au point, jusqu'à produire un script Python opérationnel exploitant une exception de confiance hardcodée dans le flux d'authentification. Pour les analystes, le code livré présente toutes les empreintes typiques d'un code généré par LLM : commentaires verbeux, redondance de garde-fous, structure de boucles inhabituelle pour un outil malveillant artisanal.

Sur le plan technique, la vulnérabilité elle-même n'a rien d'exotique : il s'agit d'un trust gap dans la logique d'authentification, où une condition prévue par les développeurs pour faciliter un cas d'usage interne ouvrait, en réalité, un chemin permettant de présenter un jeton sans déclencher la vérification du second facteur. Ce qui rend l'affaire singulière, ce n'est pas la nature de la faille — Google estime même qu'elle aurait pu être trouvée par un chercheur humain expérimenté en quelques semaines — mais l'enchaînement complet automatisable : exploration du code par l'IA, identification de la faille, génération du PoC, packaging dans un script de mass exploitation. Pour la première fois, cette boucle aboutit dans un délai compatible avec une opération industrielle, sans chercheur humain seul aux commandes.

GTIG indique avoir détecté l'opération en amont par la corrélation entre des artefacts d'infrastructure de l'attaquant et la télémétrie de scanning visant l'outil concerné. Une fois la cible identifiée, l'équipe a contacté l'éditeur, partagé les détails du bug et co-développé un correctif déployé en quelques jours. La fenêtre exacte n'est pas révélée publiquement, mais Google parle d'une intervention « avant que la campagne de masse n'atteigne sa phase de lancement ». Le nom du logiciel concerné n'est pas divulgué pour éviter d'aiguiller d'autres acteurs vers les versions vulnérables non encore mises à jour, mais la description correspond à un outil d'administration web utilisé sur plusieurs centaines de milliers d'instances exposées sur Internet.

Le rapport GTIG s'inscrit dans une série récente qui dessine l'évolution accélérée des usages offensifs des LLM. Au cours des six derniers mois, Google a déjà documenté des malwares Android capables de générer dynamiquement leur logique pour échapper aux détections statiques, des phases de reconnaissance industrialisées par des agents IA, et plusieurs cas de génération automatisée de leurres de phishing personnalisés. Ce qui change avec ce nouveau cas, c'est le franchissement d'un seuil qualitatif : l'IA n'est plus un assistant à la recherche ou à la rédaction de leurres, elle entre directement dans la chaîne de découverte de vulnérabilités sérieuses, et le résultat est utilisable en production criminelle.

L'éditeur insiste sur deux limites importantes. D'abord, le LLM utilisé par l'attaquant n'est ni Gemini ni Claude/Mythos — Google a vérifié ses propres logs et coordonné avec Anthropic — ce qui suggère un modèle tiers, possiblement open source, débridé ou exécuté en local pour échapper aux filtres de sécurité des grands fournisseurs. Ensuite, le succès opérationnel reste partiel : l'opération a été stoppée avant exploitation effective. Google se félicite donc d'un proactive counter-discovery réussi, mais reconnaît implicitement que toutes les campagnes équivalentes ne seront pas interceptées à temps. D'autres acteurs sont déjà engagés dans des cycles similaires, en cours, qui n'apparaîtront que rétrospectivement.

Côté écosystème, l'annonce a déclenché une vague de réactions. Des chercheurs académiques rappellent que les LLM open source non alignés (Llama base, Mistral non instruct, Qwen, DeepSeek brut) peuvent être adaptés via fine-tuning pour servir de "co-pilote offensif" sans déclencher de filtre de sécurité. Plusieurs équipes red team commerciales signalent qu'elles utilisaient déjà ce type de pipeline pour leurs missions internes, mais que la transposition criminelle restait théorique jusqu'à ce cas Google. Enfin, l'ANSSI et le CERT-FR avaient publié en avril un avis prudent sur le risque émergent ; cet incident donne désormais un cas réel à citer en référence dans les comités de pilotage cyber.

Pour les responsables sécurité, le signal est clair. Le compteur du « time to exploit » se réduit, le coût de l'exploitation aussi, et les organisations doivent assumer que toute vulnérabilité divulguée publiquement peut être armée par IA en quelques heures plutôt qu'en quelques jours. Le précédent récent de PraisonAI CVE-2026-44338, exploité 3h44 après divulgation, en est une illustration parmi d'autres. Ce nouveau cas Google ajoute une variante encore plus inquiétante : l'arme peut désormais être prête avant même la divulgation publique, parce que l'IA aide l'attaquant à découvrir lui-même la faille à partir du code source.

Pourquoi c'est important

Le franchissement de seuil documenté par GTIG redéfinit la cinétique de la cybersécurité défensive. Jusqu'ici, la défense pouvait raisonnablement compter sur un asymétrique de coût : un zero-day demandait des semaines de chercheur expérimenté, ce qui réservait l'exploitation à un cercle restreint d'acteurs sophistiqués. L'arrivée des LLM dans la phase de découverte fait tomber ce coût d'un ordre de grandeur, et change la nature même du marché des exploits. Demain — c'est-à-dire d'ici un à deux ans — l'écosystème criminel disposera de pipelines semi-automatisés permettant à un opérateur modérément compétent de produire un zero-day exploitable sur un projet open source à partir d'un soir de prompts bien construits.

Les conséquences pour les équipes de défense sont structurelles. Première implication : la fenêtre de patch utile se réduit drastiquement. Les SOC qui acceptaient une cadence de patch mensuelle pour les composants exposés vont devoir basculer vers une cadence hebdomadaire, voire quotidienne pour les périmètres les plus critiques. Deuxième implication : la priorisation des vulnérabilités ne peut plus se faire seulement sur le score CVSS ou la présence d'exploit public. Il faut intégrer la "exploitability by AI" comme un nouveau critère, c'est-à-dire la probabilité qu'un LLM puisse générer rapidement un exploit fiable à partir du code source ou des patchs publiés. Cette métrique manque encore, mais plusieurs éditeurs (Tenable, Wiz, GitHub Advanced Security) travaillent sur des proxies utilisables.

Sur le plan réglementaire, le rapport relance le débat sur le contrôle des modèles de fondation. L'AI Act européen contient des dispositions sur les "systèmes à risque systémique" qui pourraient s'appliquer aux LLM utilisables à des fins offensives, et les autorités américaines comme la CISA évaluent depuis plusieurs mois des recommandations sur la mise à disposition des modèles open source non alignés. Le cas GTIG fournit le premier exemple concret d'un préjudice opérationnel évité, ce qui va peser dans les arbitrages politiques à venir. À court terme, on peut s'attendre à un renforcement des conditions d'usage des grands modèles commerciaux, et à des appels — plus difficiles à mettre en œuvre — pour encadrer les modèles open source rebrandés.

Enfin, pour les éditeurs de logiciels, l'épisode renforce l'urgence du Secure Software Development Framework et du shift-left de la sécurité. Quand un attaquant peut soumettre votre code source à un LLM pour en sortir des chemins d'exploitation, la qualité de la posture sécurité repose désormais sur la rigueur des revues de code, l'usage de SAST/DAST modernes, la limitation des trust gaps et des hardcodages, et la capacité à détecter les indicateurs d'attaque émergents. Les organisations qui n'investissent pas dans une chaîne CI/CD durcie offrent un terrain de jeu idéal aux pipelines offensifs IA en construction.

Ce qu'il faut retenir

• L'IA n'est plus un simple assistant à la rédaction de phishing : elle entre dans la chaîne complète de découverte et d'armement de zero-day, et le premier cas en conditions réelles vient d'être documenté par Google.
• Les cadences de patch et les critères de priorisation des vulnérabilités doivent être révisés à la hausse, en intégrant la "exploitability by AI" comme nouveau paramètre de risque.
• Les éditeurs et défenseurs doivent investir massivement dans le shift-left sécurité (revues de code, SAST/DAST, limitation des trust gaps) car le coût pour l'attaquant d'extraire un exploit d'un code source vient de s'effondrer.